Summary:
When you did a typo in declaring a prop type (like using `boolean` insteal of `bool`) you'd got a bit misleading error message:
{F27113768}
The truth is that the prop type is defined, but not correctly. So I've changed the message in this case to be more accurate:
{F27113627}
public
Reviewed By: sahrens
Differential Revision: D2729340
fb-gh-sync-id: dd12c10a4f3a1c9825293f86481a082908127a76
Summary:
The JavaScript ecosystem doesn't have the notion of a built-in native module loader. Even Node is decoupled from its module loader. The module loader system is just JS that runs on top of the global `process` object which has all the built-in goodies.
Additionally there is no such thing as a global require. That is something unique to our providesModule system. In other module systems such as node, every require is contextual. Even registered npm names are localized by version.
The only global namespace that is accessible to the host environment is the global object. Normally module systems attaches itself onto the hooks provided by the host environment on the global object.
Currently, we have two forms of dispatch that reaches directly into the module system. executeJSCall which reaches directly into require. Everything now calls through the BatchedBridge module (except one RCTLog edge case that I will fix). I propose that the executors calls directly onto `BatchedBridge` through an instance on the global so that everything is guaranteed to go through it. It becomes the main communication hub.
I also propose that we drop the dynamic requires inside of MessageQueue/BatchBridge and instead have the modules register themselves with the bridge.
executeJSCall was originally modeled after the XHP equivalent. The XHP equivalent was designed that way because the act of doing the call was the thing that defined a dependency on the module from the page. However, that is not how React Native works.
The JS side is driving the dependencies by virtue of requiring new modules and frameworks and the existence of dependencies is driven by the JS side, so this design doesn't make as much sense.
The main driver for this is to be able to introduce a new module system like Prepack's module system. However, it also unlocks the possibility to do dead module elimination even in our current module system. It is currently not possible because we don't know which module might be called from native.
Since the module system now becomes decoupled we could publish all our providesModule modules as npm/CommonJS modules using a rewrite script. That's what React Core does.
That way people could use any CommonJS bundler such as Webpack, Closure Compiler, Rollup or some new innovation to create a JS bundle.
This diff expands the executeJSCalls to the BatchedBridge's three individual pieces to make them first class instead of being dynamic. This removes one layer of abstraction. Hopefully we can also remove more of the things that register themselves with the BatchedBridge (various EventEmitters) and instead have everything go through the public protocol. ReactMethod/RCT_EXPORT_METHOD.
public
Reviewed By: vjeux
Differential Revision: D2717535
fb-gh-sync-id: 70114f05483124f5ac5c4570422bb91a60a727f6
Summary:
public
Introduce a new Polyfill module to load bundles. This polyfill contains the function to which System.import gets transformed into. It works similarly to require in the way it's registered. It keeps track of the bundles that have ever been requested using promises, either fulfilled or not. The use of promises makes the implementation quite easy as we don't need to differenciate whether the request has been started or not.
There're a couple of follow up steps that still need to get done:
- Included this polyfill on the ones we automatically include on the bundle.
- Modify the transform to include the modules the user is actually requesting and pipe that through loadBundles so that the promise, once resolved, has the ordered list of modules the user requested.
- Implement the actual native code that loads a bundle. This shouldn't be that taught as native will be able to assume it will never receive the same request twice.
Reviewed By: davidaurelio
Differential Revision: D2727241
fb-gh-sync-id: 317d80754783caf43f10c71a34a4558a4d298d45
Summary:
In order to be able to reliable identify unbundles when loading files, prepend a magic number (0xFB0BD1E5)
public
Reviewed By: martinbigio
Differential Revision: D2734359
fb-gh-sync-id: b469e26459234e7f6270fffa0b872a93d137381d
Summary:
Fixes#4602
Fixes a bug where the app crashes when you try to inspect a stateless
component.
Fixed by replacing all occurrences of the getPublicInstance method in
Libraries/Inspector/Inspector.js with the _instance property instead.
Defaults to an empty object if _instance is falsy.
Closes https://github.com/facebook/react-native/pull/4642
Reviewed By: svcscm
Differential Revision: D2734491
Pulled By: androidtrunkagent
fb-gh-sync-id: 4ea753b7e0ef3fd05af2d80abadc365c5c787f98
Summary:
- PickerIOS accepts now a new prop: style
- this prop modifies the native style of the RCTPicker allowing to modify the font size of the items (fontSize), color of the items (color, only 6 char HEX values for now) and alignment of the items (textAlign)
Closes https://github.com/facebook/react-native/pull/4490
Reviewed By: svcscm
Differential Revision: D2723190
Pulled By: nicklockwood
fb-gh-sync-id: ab9188192f1d0d087787dfed8c128073bfaa3235
Summary:
public
The +[RCTConvert UIImage:] function, while convenient, is inherently limited by being synchronous, which means that it cannot be used to load remote images, and may not be efficient for local images either. It's also unable to access the bridge, which means that it cannot take advantage of the modular image-loading pipeline.
This diff introduces a new RCTImageSource class which can be used to pass image source objects over the bridge and defer loading until later.
I've also added automatic application of the `resolveAssetSource()` function based on prop type, and fixed up the image logic in NavigatorIOS and TabBarIOS.
Reviewed By: javache
Differential Revision: D2631541
fb-gh-sync-id: 6604635e8bb5394425102487f1ee7cd729321877
Summary:
public
Most apps create tons of text components but they are actually quite heavy because of the the Touchable mixin which requires binding tons of functions for every instance created.
This diff makes the binding lazy, so that the main handlers are only bound if there is a valid touch action configured (e.g. onPress), and the Touchable mixin functions are only bound the first time the node is actually touched and becomes the responder.
ScanLab testing shows 5-10% win on render time and memory for various products.
Reviewed By: sebmarkbage
Differential Revision: D2716823
fb-gh-sync-id: 30adb2ed2231c5635c9336369616cf31c776b930
Summary:
public
In the open source React Native implementation, the recommended approach for importing modules is by importing a the `ReactNative` object, which includes all available modules.
This is rather inefficient because it ends up initializing all the JS modules, even if you don't use them.
This diff switches the properties of the `ReactNative ` object to lazy getter functions, which defers the `require` until the module is actually requested.
This doesn't prevent unused modules from being included in the JS bundle, but it will prevent them from being initialized unless/until they are used.
Reviewed By: vjeux
Differential Revision: D2722993
fb-gh-sync-id: 0e9a2beb3aa6cd087a0592bd59a8f9242040be0c
Summary:
The naming "Layout" is an Android-specific thing and not useful in JS. Let's stay consistent with naming like "ScrollView", "MapView" etc.
public
Reviewed By: bestander
Differential Revision: D2723163
fb-gh-sync-id: 6b86e5a649254c41e9d6b0ef6f1fe2ff4b9f3e9a
Summary:
public
Only the first quad-word and floating point return registers were being preserved,
make sure to preserve the 2nd ones as well (`%rdx` and `%xmm1`)
Reviewed By: jspahrsummers
Differential Revision: D2727523
fb-gh-sync-id: d8176512d2dfb5f664f634ecaaf34510515506ea
Summary:
Adds a note that the `Modal` component is only available in iOS.
I hit a bit of a pickle this weekend after realizing a handful of components I built will have to be rewritten. Unfortunately there's no notes in the documentation that the support is limited. Hopefully this can contribute towards avoiding those situations
Closes https://github.com/facebook/react-native/pull/4592
Reviewed By: svcscm
Differential Revision: D2727634
Pulled By: androidtrunkagent
fb-gh-sync-id: 2d0efcca8e17d16cf63d592e235261cea63e59ea
Summary:
This is just an workaround for making UIExplorer work in Android.
Closes https://github.com/facebook/react-native/pull/4405
Reviewed By: svcscm
Differential Revision: D2727452
Pulled By: tadeuzagallo
fb-gh-sync-id: af48fb8c462ab04874cfdb96c0fd4409bf6d92c3
Summary:
public
D2670028 updated the x/y positions of touch events to be relative to the window, but measure still uses the location on the screen. Therefore, in Touchable.js, we were seeing taps get inproperly invalidated because they were erroneously considered outside of the touch rect. This diff moves back to the old version of pageX/Y on touch events that's compatible with the current version of measure.
Reviewed By: nicklockwood
Differential Revision: D2724917
fb-gh-sync-id: 978ae26fcaa23c47a4f619e2b7ff2d078388ae95
Summary:
A few caveats before accepting:
- Do I need to squash commits?
- Need to set up new Circle CI account connected to FB react-native repo
- After that replace tokens and links to the new ones
Setting up Integration tests should be straight forward next week https://circleci.com/docs/android
Closes https://github.com/facebook/react-native/pull/4566
Reviewed By: svcscm
Differential Revision: D2723119
Pulled By: androidtrunkagent
fb-gh-sync-id: 2c4a46b206f15f36d94d1b10ff9e339f5182782b