Summary:
Currently only scroll events are send through `sendEvent`, and all of them are can be coalesced. In future (further in the stack) touch events will go through there as well, but they won't support coalescing.
In order to ensure js processes touch and scroll events in the same order as they were created, we will flush the coalesced events when we encounter one that cannot be coalesced.
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: nicklockwood
Differential Revision: D2884591
fb-gh-sync-id: a3d0e916843265ec57f16aad2f016a79764dcce8
Summary:
I want to use the `RCTEvent` protocol for touch events as well. That's why I'm removing not very well defined `body` property and replacing it with `arguments` method, which will return an array that will be passed directly to the js call.
I think this makes sense because there is no unified arguments format for all events and and the called js method (`moduleDotMethod`) is already event specific.
This way touch events and scroll events can result in calling a completely different js function with a completely different arguments (what they indeed currently do).
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: nicklockwood
Differential Revision: D2884590
fb-gh-sync-id: 2c1885c3414e255d8572c0fbbbfe62a23d94dd06
Summary:
This property was never used, so I'm removing it.
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: javache
Differential Revision: D2884587
fb-gh-sync-id: acd5e576cd13a02e77225f3b308232f8331d3b61
Summary:
`RCTBaseEvent` was never used. This diff removes it.
public
___
//This diff is part of a larger stack. For high level overview what's going on jump to D2884593.//
Reviewed By: javache
Differential Revision: D2884585
fb-gh-sync-id: 66a6afcda3b5baec7f768682da215570f6d33bb1
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:
Our events all follow a common pattern, so there's no good reason why the configuration should be so verbose. This diff eliminates that redundancy, and gives us the freedom to simplify the underlying mechanism in future without further churning the call sites.
Martin Kralik
Nick Lockwood
Tadeu Zagallo