Summary:
public
The logic inside RCTBatchedBridge contained some race conditions that would occasionally cause an error if modules were loaded in the wrong order. This improves that logic and makes it safer by adding a lock to prevent concurrency.
Reviewed By: jspahrsummers
Differential Revision: D2802930
fb-gh-sync-id: d1ad25fa578649363dcaac029cb24dc3a453ae67
Summary:
public
The implementation of the `methodQueue` lazy initializer in `RCTModuleData` could result in the queue being set twice, because calling `methodQueue` for a module that hasn't been instantiated would call `RCTModuleData.instance` to create the module, which itself calls `methodQueue`.
It's not clear if this was causing a bug, but it may be related to an occasional bug where the `RCTViewManager.methodQueue` returns nil.
Reviewed By: majak
Differential Revision: D2783320
fb-gh-sync-id: 9194da0fd7392f63825da1f5c450363dd300b635
Summary:
public
Thanks to the new lazy initialization system for modules, `RCTDidCreateNativeModules` no longer does what the name implies.
Previously, `RCTDidCreateNativeModules` was fired after all native modules had been initialized. Now, it simply fires each time the bridge is reloaded. Modules are created on demand when they are needed, so most of the assumptions about when `RCTDidCreateNativeModules` will fire are now incorrect.
This diff deprecates `RCTDidCreateNativeModules`, and adds a new notification, `RCTDidInitializeModuleNotification`, which fires each time a module a new module is instantiated.
If you need to access a module at any time you can just call `-[bridge moduleForClass:]` and the module will be instantiated on demand. If you want to access a module *only* after it has already been instantiated, you can use the `RCTDidInitializeModuleNotification` notification.
Reviewed By: tadeuzagallo
Differential Revision: D2755036
fb-gh-sync-id: 25bab6d5eb6fcd35d43125ac45908035eea01487
Summary:
public
A lot of the core modules have to use private methods in the bridge, specially
since the `RCTBatchedBridge` interface is never exposed. That was leading to a
lot of different private bridge categories spread across different modules,
which makes harder to identify which modules are affected by private API changes.
Replace all the categories with a single private header.
Reviewed By: nicklockwood
Differential Revision: D2757564
fb-gh-sync-id: 793158b9082d542b74a6094ed0db4d5dc3a88f78
Summary:
public
This diff replaces the RegEx module method parser with a handwritten recursive descent parser that's faster and easier to maintain.
The new parser is ~8 times faster when tested on the UIManager.managerChildren() method, and uses ~1/10 as much RAM.
The new parser also supports lightweight generics, and is more tolerant of white space.
(This means that you now can – and should – use types like `NSArray<NSString *> *` for your exported properties and method arguments, instead of `NSStringArray`).
Reviewed By: jspahrsummers
Differential Revision: D2736636
fb-gh-sync-id: f6a11431935fa8acc8ac36f3471032ec9a1c8490
Summary:
public
Looping through every `RCTModuleData` to check whether the module responds to `-batchDidComplete` or `-partialBatchDidFlush` is unnecessarily expensive. We can cache the answer at the time that the module instance is actually initialized.
Reviewed By: tadeuzagallo
Differential Revision: D2717594
fb-gh-sync-id: 274a59ec2d6014ce18c93404ce6b9940c1dc9c32
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
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
UIExplorer tests were broken due to a refactor that didn't update the RCTShadowViewTests + an off-by-one error in the logic for exporting async methods.
Reviewed By: javache
Differential Revision: D2595810
fb-gh-sync-id: c25a8b8956bff1ef2754bba4a8f10d72a16e2954
Summary: public
Use arrays instead of dictionaries for encoding module method information.
This further reduces UIExplorer startup JSON from 16104 bytes to 14119 (12% reduction)
Reviewed By: javache
Differential Revision: D2570057
fb-gh-sync-id: 4a53a9ead4365a136e7caeb650375733e1c24c0e
Summary: public
We're sending a lot of module config data when the app first starts, and much of this is redundant.
UIExplorer current sends 19061 bytes of module config JSON. This diff reduces that to 16104 (15% saving) by stripping modules that have no methods or constants, and removing method types unless method is async.
Reviewed By: tadeuzagallo, javache
Differential Revision: D2570010
fb-gh-sync-id: 8c0abbd1cdee3264b37a4f52e852008caaffb9c5
Summary:
Occasionally people create RCTBridgeModule subclasses or base classes that are not intended to be accessed from JS, and so they don't export them. This was previously flagged as an error by the system. I've now downgraded this error to a warning at startup, and deferred the redbox error until the module is directly accessed by native or JS code.
Summary:
@public
The info about bridge modules (such as id, name, queue, methods...) was spread
across arrays & dictionaries on the bridge, move it into a specific class.
It also removes a lot of information that was statically cached, and now have
the same lifecycle of the bridge.
Also moved RCTModuleMethod, RCTFrameUpdate and RCTBatchedBridge into it's own
files, for organization sake.
NOTE: This diff seems huge, but most of it was just moving code :)
Test Plan:
Tested UIExplorer & UIExplorer tests, Catalyst, MAdMan and Groups. Everything
looks fine.
Nick Lockwood
Tadeu Zagallo
Justin Spahr-Summers
David Aurelio
Marc Horowitz