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
The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed.
This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead.
The rules are now as follows:
* Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created
* Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but `constantsToExport:` will still be called on the main thread.
* All other modules will be initialized lazily when a method is first called on them.
These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily.
I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results:
Out of the 65 modules included in UIExplorer:
* 16 are initialized on the main thread when the bridge is created
* A further 8 are initialized when the config is exported to JS
* The remaining 41 will be initialized lazily on-demand
Reviewed By: jspahrsummers
Differential Revision: D2677695
fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
Summary: This fixes a leak in regards to web sockets, detailed in #3846 . The connection state constants referenced the class rather than the instance and were coming back undefined.
cc brentvatne stephenelliot
Closes https://github.com/facebook/react-native/pull/3896
Reviewed By: svcscm
Differential Revision: D2626399
Pulled By: vjeux
fb-gh-sync-id: f42670003b68ed5b86f078d7ed74c2695f30fc69
Summary: public
Added lightweight genarics annotations to make the code more readable and help the compiler catch bugs.
Fixed some type bugs and improved bridge validation in a few places.
Reviewed By: javache
Differential Revision: D2600189
fb-gh-sync-id: f81e22f2cdc107bf8d0b15deec6d5b83aacc5b56
Summary: public
Benchmarking our startup path has shown we spend a lot of time decoding strings (iPhone 4S / iPhone 5):
* reading a 2MB JS bundle: 35ms / 15ms
* decoding is to an `NSString`: 186ms / 78ms
* transforming that to a `JSString`: 29ms / 10ms
Instead of going through an `NSString` transformation, we generate a null-terminated bundle (0.1ms / 0.05ms to copy the data) and use `JSStringCreateWithUTF8CString` (121ms / 53ms) to generate the string. That makes decoding 70% faster.
Reviewed By: javache
Differential Revision: D2541140
fb-gh-sync-id: 09a016b8edfd46a9b62682c76705564d2024e75e
Summary: Check that the WS state is set to OPEN before trying to close it when the ```websocketFailed``` event fires. Otherwise the app throws an error at the Android level.
Fixes#3346
Closes https://github.com/facebook/react-native/pull/3347
Reviewed By: @svcscm
Differential Revision: D2535807
Pulled By: @mkonicek
fb-gh-sync-id: bb70c551ea2e582cfaa80139a265dbbca6d990d2
Summary: The JavaScript code for Android is same as the iOS counterpart, I just added few new lines and used arrow functions instead of binding `this`.
Closes https://github.com/facebook/react-native/pull/2839
Reviewed By: @svcscm, @vjeux
Differential Revision: D2498703
Pulled By: @mkonicek
fb-gh-sync-id: 3fe958dd5af0efba00df07515f8e33b5d87eb05b
Summary: @public
Jest has an issue where if you export `Symbol` it crashes badly. Since event-target-shim does that, it breaks everything. Mocking that module fixes the issue until @cpojer comes back from vacation and fixes the bug in Jest itself.
Reviewed By: @jingc
Differential Revision: D2503562
Summary:
The bridge implementation on React Android does not currently support boxed numeric/boolean types (the equivalent of NSNumber arguments on iOS), nor does Java support Objective-C's nil messaging system that transparently casts nil to zero, false, etc for primitive types.
To avoid platform incompatibilities, we now treat all primitive arguments as non-nullable rather than silently converting NSNull -> nil -> 0/false.
We also now enforce that NSNumber * objects must be explicitly marked as `nonnull` (this restriction may be lifted in future if/when Android supports boxed numbers).
Other object types are still assumed to be nullable unless specifically annotated with `nonnull`.
Summary:
Add a new bridge delegate protocol to allow a more flexible bridge configuration.
For now it just support the pre-existent configurations + providing the JavaScript
source to the bridge, that should allow pre-loading sources.
Summary:
This diff implements highlighting of tapped text subranges for the iOS `<Text>` component, styled to match how iOS webkit views highlight links (translucent grey overlay with rounded corners).
Highlighting is enabled by default for any `<Text>` component which has an onPress handler. To disable the highlight, add `suppressHighlighting={true}` to the component props.
Summary:
Remove `RCTGetExecutorID` and `RCTSetExecutorID`, it wasn't used anymore since
the bridge was refactored into `RCTBridge` and `RCTBatchedBridge`.
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
@public
`-[RCTJavaScriptExecutor executeBlockOnJavaScriptQueue:]` would always `dispatch_async`
for the WebView and WebSocket executors, what caused for any frame aligned dispatch.
Test Plan:
Test the `Timers, TimerMixin` example on UIExplorer, `requestAnimationFrame` was
taking ~33.3ms when debugging, now takes ~16.6ms as expected.
Summary:
I am not 100% sure what causes reason to be null but it does happen.
Closes https://github.com/facebook/react-native/pull/1483
Github Author: Stanislav Vishnevskiy <vishnevskiy@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
@public
This is the first of a few diffs that change the way the executors are handled
by the bridge.
For they are just promoted to modules, so they are automatically loaded by the bridge.
Test Plan:
Tested on UIExplorer, Catalyst and MAdMan.
Tested all the 3 executors, everything looks fine.
Sebastian Markbage
Nick Lockwood
Natthu Bharambe
Ken Wheeler
Satyajit Sahoo
Joe Noon
Frédéric Sagnes
Yuri Zarubin
Christopher Chedeau
leeyeh
Alex Kotliarskyi
Harrison Harnisch
Tadeu Zagallo
Alex Akers
Stanislav Vishnevskiy
