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: public
Ability to efficiently remove all keys with a particular prefix
Reviewed By: tadeuzagallo
Differential Revision: D2658741
fb-gh-sync-id: 3770f061c83288efe645162ae84a9fd9194d2fd6
Summary: If a redbox error is too long it's not shown at all:
{F24443416}
This diff truncates it to its first 10000 chars, which should be good enough:
{F24443417}
The reason is a limitation of UILabel which backs text property on the used UITableViewCell.
Ideally we would use a custom cell with UITextView, but I don't feel there is any value in displaying super long error messages in a redbox.
public
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2690638
fb-gh-sync-id: d9b3fcecd2602e8c2618afe1bb97221c2e506605
Summary: public
We were calling constantsToExport twice for every ViewManager, and including two copies of the values in __fbBatchedBridgeConfig. This diff removes the copy from UIManager and then puts it back on the JS side.
Reviewed By: tadeuzagallo
Differential Revision: D2665625
fb-gh-sync-id: 147ec4bfb404835e3875964476ba233d619c28aa
Summary: public
RCTPasteboard is a very basic API for writing strings to the pasteboard. Useful for implementing "copy to clipboard" functionality.
Reviewed By: astreet
Differential Revision: D2663875
fb-gh-sync-id: 8d0ecd824c3e9fe135b02201d21d0dab1907c329
Summary: public
In iOS < 9, inserting a nil object into NSMutableDictionary crashes. It is valid for come components to return a nil shadowView (e.g. ART nodes), and this was crashing on iOS 8.
Reviewed By: jspahrsummers
Differential Revision: D2658309
fb-gh-sync-id: 7abf9273708cc03c3b6307b69ba11c016b471fbe
Summary: public
RCTImagePicker (aka ImagePickerIOS) was previously displaying UI from a random thread, which is unsafe. This diff forces it to execute on the main thread instead.
Reviewed By: jspahrsummers
Differential Revision: D2657465
fb-gh-sync-id: 3c0fa6935061ccaa3e6ce649b4e3e8ad8c701384
Summary: This queue processes layout and user interface updates, so it should have as high a quality-of-service/priority as possible.
public
Reviewed By: javache
Differential Revision: D2641837
fb-gh-sync-id: 934686f7969b43101af183148d67ff7be4bdf660
Summary: public
The WebView executor has no benefits compared to the JSC executor (slower, no extra debugging tools...),
and it's pretty hacky (since it injects the code in a script tag we have to check for tags in the comments and etc...).
Reviewed By: nicklockwood, javache
Differential Revision: D2636465
fb-gh-sync-id: 0d0f8a59e2c12fe7905b02060b3938c894d2802b
Summary: public
Rename it to `RCT_PROFILE_(BEGIN|END)_EVENT` to make it clearer that it's a macro,
since it has special behaviours.
Reviewed By: jspahrsummers
Differential Revision: D2631542
fb-gh-sync-id: 629c139462c4aa3582f719b14482017d13676e33
Summary: public
There were some old markers that are now automatically inject and now are no longer necessary (+ one that was missing an end call :( ))
Reviewed By: javache
Differential Revision: D2625901
fb-gh-sync-id: 4c4c9d6b4e8e2b4bdb9c64fde01000b0ca2e9f47
Summary: public
Add RCTFatal for reporting fatal runtime conditions. This centralizes failure handling to one function and allows you to customize how they should be handled. RCTFatal will be logged to the console and as a redbox and will also be triggered by fatal exceptions coming from RCTExceptionsManager.
Note that there is no RCTLogFatal, since just logging the fatal condition does not allow us to handle it consistently.
Reviewed By: nicklockwood
Differential Revision: D2615490
fb-gh-sync-id: 7d8e134419e10a8fb549297054ad955db3f6bee0
Summary: I was getting the following error when running `testAsyncStorageTest`
```
uncaught exception 'NSInvalidArgumentException', reason: 'Invalid type in JSON write (NSError)'
```
nicklockwood pointed out that it might be because we're attempting to send a `NSError *` over the bridge at some point. So I went looking for cases where that might happen and found this instance.
public
Reviewed By: jingc
Differential Revision: D2619240
fb-gh-sync-id: dc26ec268f976fec44f2804831398d3b01ab6115
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
The UIManager had a lock around the enqueued ui blocks, but now all the operations
should happen on the shadow thread, so I added assertions to it and removed the
locks.
Reviewed By: nicklockwood
Differential Revision: D2605760
fb-gh-sync-id: e1bc649f759502e7e9fd059932e0cba38dba05bf
Summary: There is no point in dispatching to main thread if there is nothing to do there.
This place gets called basically any time a repeating js timer fires, which doesn't imply UI changes (although usually that's why people setup timers).
Combined with previous diffs that makes us not generate empty blocks (nil instead), this could be minor perf win in some rare cases.
This also changes semantic of `reactBridgeDidFinishTransaction` call a bit. Previously it was done no matter if UI has changed or not.
I think it should be safe, since seems like callees really care only about views being laid out.
Depends on D2571166. (not strictly speaking)
public
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2571188
fb-gh-sync-id: 02d52e4615475072c3c27226e67c431a667ec990
Summary: Same as in previous diffs. Gets us into a better place to know if we really have UI updates and it's marginally more efficient.
Depends on D2571143. (not really)
public
Reviewed By: nicklockwood
Differential Revision: D2571166
fb-gh-sync-id: e8f34521ec2e12156a49f1cd655e92df1db34fca
Summary: Previously `_bridgeTransactionListeners` were informed about `reactBridgeDidFinishTransaction` inside of one of the UI blocks.
That seems pretty arbitrary, doesn't really mean a "transaction" is really over (assuming transaction means all UI updates) and even when that block does nothing we still need to call these listeners, since there could be other UI blocks generated somewhere else!
So I've moved this call to a place that seemed better (=after all UI blocks are done), since all listeners are interested in knowing when layout has happened.
public
Reviewed By: nicklockwood
Differential Revision: D2571122
fb-gh-sync-id: 62be03ebc4353d6f6318c9765079b87b07483be2
Summary: public
Kill `RCTPerfStats` and introduce the new `RCTPerfMonitor`, including memory
usage, JSC heap size, number of RN views in screen, FPS (both on UI and JS threads)
and more to come.
It removes all the previous traces that were previous spread across the bridge
and the dev menu and moves everything to be more contained, so the whole thing
can be safely striped in production.
Reviewed By: nicklockwood
Differential Revision: D2575158
fb-gh-sync-id: 6a6d0c4422adbddeeefddd32ec3409a7095ff2a9
Summary: While we shouldn't invoke `bridge.devMenu` in production, doing it will result into a crash.
1. `devMenu` internally calls `RCTBridgeModuleNameForClass([RCTDevMenu class])`
2. `RCTBridgeModuleNameForClass()` calls `moduleName`
3. In the release code `RCTDevMenu` doesn't export the `moduleName` class method.
Closes https://github.com/facebook/react-native/pull/2910
Reviewed By: svcscm
Differential Revision: D2550797
Pulled By: tadeuzagallo
fb-gh-sync-id: 5dfbf905e5a02d9fd3b52f8b3d6eefc4e3ff30b2
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: @public
This diff implements inline image support for <Text> nodes. Images are specified using <Image> tags, however all properties of the image are currently ignored apart from the source (including width/height styles).
Images are loaded asyncronously, and will trigger a text re-layout when they have loaded.
Reviewed By: @javache
Differential Revision: D2507725
fb-gh-sync-id: 59d0696d00a1bc531915cc35242a16b2dec96e85
Summary: When you reload and create a new bridge, one of the things that happens during setup is that the RCTAccessibilityManager fires a notification. The old bridge would receive this notification from the new bridge's RCTAccessibilityManager, which we don't want, especially because the two are running on different shadow queues.
I believe this led to a gnarly crash in NSConcreteTextStorage because RCTMeasure in RCTShadowText.m was getting called for the old RCTText (getting destroyed) from a notification fired from the new shadow queue. The fix is for the UIManager to handle notifications only from its bridge's RCTAccessibilityManager. See #2001 for the kinds of crashes we were seeing.
Closes https://github.com/facebook/react-native/pull/3279
Reviewed By: @svcscm
Differential Revision: D2521652
Pulled By: @nicklockwood
fb-gh-sync-id: a4ffe3ef8304667727e573e2a2e8b716e1d2f3e1
Milen Dzhumerov
Nick Lockwood
Pieter De Baets
Martin Kralik
Justin Spahr-Summers
Ryan Olson
Tadeu Zagallo
Natthu Bharambe
Bhuwan Khattar
Pawel Sienkowski
Patrik Tomas Chamelo
Frédéric Sagnes
James Ide
Chace Liang
Alexey Lang