Summary: @public
Take a step back and de-batch the bridge calls so we can have better profiling data and a better starting point to work on future optimisations. Also gave a 10~15% win on first render.
Reviewed By: @javache
Differential Revision: D2493674
fb-gh-sync-id: 05165fdd00645bdf43e844bb0c4300a2f63e7038
Summary:
This will throw an error message with the problematic callback module/method. Previously we would get an invariant in this case when we try to access `callback.apply` later in the method.
Summary:
@public
After refactoring the MessageQueue a guard was missing on around `batchedUpdates`
call.
Test Plan: Introduce an error on `getInitialState` of `AdsManagerTabsModalView.ios.js`
Summary:
@public
The current implementation of `MessageQueue` is huge, over-complicated and spread
across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory`
Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge`
is only an instance of it.
Test Plan:
I had to make some updates to the tests, but no real update to the native side.
There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer.
Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable.
Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls.
Test the failure callback on the `Geolocation` example.
All the calls go through this entry point, so it's hard to miss if it's broken.
Summary:
@public
This removes the last piece of data that was still stored on the DATA section,
`RCT_IMPORT_METHOD`. JS calls now dynamically populate a lookup table simultaneously
on JS and Native, instead of creating a mapping at load time.
Test Plan: Everything still runs, tests are green.
Summary:
@public
`[Bridge] Add support for JS async functions to RCT_EXPORT_METHOD` was imported but broke some internal code, reverting the `MessageQueue` that caused the issues and add a test, since the method is not used yet.
Test Plan: Run the test o/
Summary:
Adds support for JS async methods and helps guide people writing native modules w.r.t. the callbacks. With this diff, on the native side you write:
```objc
RCT_EXPORT_METHOD(getValueAsync:(NSString *)key
resolver:(RCTPromiseResolver)resolve
rejecter:(RCTPromiseRejecter)reject)
{
NSError *error = nil;
id value = [_nativeDataStore valueForKey:key error:&error];
// "resolve" and "reject" are automatically defined blocks that take
// any object (nil is OK) and an NSError, respectively
if (!error) {
resolve(value);
} else {
reject(error);
}
}
```
On the JS side, you can write:
```js
var {DemoDataStore} = require('react-native').NativeModules;
DemoDataStore.getValueAsync('sample-key').then((value) => {
console.log('Got:', value);
}, (error) => {
console.error(error);
// "error" is an Error object whose message is the NSError's description.
// The NSError's code and domain are also set, and the native trace i
Closes https://github.com/facebook/react-native/pull/1232
Github Author: James Ide <ide@jameside.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
@public
Right now the profiler shows how long the executor took on JS but doesn't show
how long each of the batched calls took, this adds a *very* high level view of JS
execution (still doesn't show properly calls dispatched with setImmediate)
Also added a global property on JS to avoid trips to Native when profiling is
disabled.
Test Plan:
Run the Profiler on any app
{F22491690}
Summary:
Wraps the setImmediate handlers in a `batchUpdates` call before they are synchronously executed at the end of the JS execution loop.
Closes https://github.com/facebook/react-native/pull/1242
Github Author: James Ide <ide@jameside.com>
Test Plan:
Added two `setImmediate` calls to `componentDidMount` in UIExplorerApp. Each handler calls `setState`, and `componentWillUpdate` logs its state. With this diff, we can see the state updates are successfully batched.
```javascript
componentDidMount() {
setImmediate(() => {
console.log('immediate 1');
this.setState({a: 1});
});
setImmediate(() => {
console.log('immediate 2');
this.setState({a: 2});
});
},
componentWillUpdate(nextProps, nextState) {
console.log('componentWillUpdate with next state.a =', nextState.a);
},
```
**Before:**
"immediate 1"
"componentWillUpdate with next state.a =", 1
"immediate 2"
"componentWillUpdate with next state.a =", 2
**After:**
"immediate 1"
"immediate 2"
"componentWillUpdate with next state.a =", 2
Addresses the batching issue in #1232. cc @vjeux @spicyj
Summary:
Adds support for JS async methods and helps guide people writing native modules w.r.t. the callbacks. With this diff, on the native side you write:
```objc
RCT_EXPORT_METHOD(getValueAsync:(NSString *)key
resolver:(RCTPromiseResolver)resolve
rejecter:(RCTPromiseRejecter)reject)
{
NSError *error = nil;
id value = [_nativeDataStore valueForKey:key error:&error];
// "resolve" and "reject" are automatically defined blocks that take
// any object (nil is OK) and an NSError, respectively
if (!error) {
resolve(value);
} else {
reject(error);
}
}
```
On the JS side, you can write:
```js
var {DemoDataStore} = require('react-native').NativeModules;
DemoDataStore.getValueAsync('sample-key').then((value) => {
console.log('Got:', value);
}, (error) => {
console.error(error);
// "error" is an Error object whose message is the NSError's description.
// The NSError's code and domain are also set, and the native trace i
Closes https://github.com/facebook/react-native/pull/1232
Github Author: James Ide <ide@jameside.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.