Summary: Get rid of the old behaviour of JSON encoding in `nativeRequireModuleConfig` and consistently use the same names for function types "async/promise/sync"
Reviewed By: lexs
Differential Revision: D3819348
fbshipit-source-id: fc798a5abcaf6a3ef9d95bd8654afa7825c83967
Summary: Add some additional perf markers, and remove the usage of RCTProfileBlock as it completely breaks debugging / stepping in those blocks.
Reviewed By: majak
Differential Revision: D3579900
fbshipit-source-id: 8846dfc39b2448daa3669d5e1e8efb9096f183c5
Summary: No need to specify duplicative information.
Reviewed By: javache
Differential Revision: D3550805
fbshipit-source-id: b5abc3f1c74e26b4d4641c29fedba189cc46406e
Summary: This prevents the `isUnbundle` check to read beyond the end of an `NSData` instance by using `getBytes:length:` instead of accessing the underlying buffer directly.
Reviewed By: javache
Differential Revision: D3548874
fbshipit-source-id: 7c93c66cc6abb4a2a321888ab394212f4d14a03e
Summary:
The `initWithJSContextProvider:` API created a `RCTJSCExecutor` with a thread/context that already exists, but it did not solve the problem of loading an actual application script; the `executeApplicationScript:` API is also asynchronous.
Create a new merged API that allows you to pass in a pre-created thread/context pair and immediately receive an `RCTJSCExector` that has already executed a specified application script.
This also removes the `underlyingJSContext` API entirely, in favor of passing it back in a byref variable in the new API. This minimizes the surface area for API abuse.
Reviewed By: bnham
Differential Revision: D3545349
fbshipit-source-id: 1c564f44d2a5379b5e6f75640079a28fd7169f67
Summary:
Instead of two separate dispatches to the JavaScript thread, only do one. Avoid the strongSelf dance entirely.
This refactor does mean that the cost of registering the nativeRequire hook on the context is not measured by the `RCTPLRAMBundleLoad` tag. However it should be almost zero-cost to construct and set a single block, so I'm OK with that change.
Reviewed By: bnham
Differential Revision: D3542940
fbshipit-source-id: d6bd26e478d0d33b56f8116d7efe6aac80c91711
Summary: This makes the state it uses more explicit. It also makes a bug with performance measurement obvious: if we early return to error, we never mark stop for `RCTPLRAMStartupCodeSize`.
Reviewed By: javache
Differential Revision: D3542751
fbshipit-source-id: e6c1e3f3a76098ca37b8078f6e9abc805ad2d9da
Summary: This can be used to create a JavaScript thread and `JSContext` in advance, then supply them to the `RCTJSCExecutor` at creation time later.
Reviewed By: javache
Differential Revision: D3534553
fbshipit-source-id: 99ccf711928cd12e84c9fbe142c6d19a7af55d07
Summary: This was left over from a previous change.
Reviewed By: javache
Differential Revision: D3534376
fbshipit-source-id: 6932364d1c32d8fbdf56c642893f9ea5e6dc1fee
Summary:
In practice, it *MUST* be the call to `self.context` within `setUp` that triggers the creation of the context:
- It can't come before that point because `_jscWrapper` has not been set up yet
- It can't come after that point since `self.context` would create the context there.
Just move the creation to be inline, enforced by assert. This makes it easier to reason about where the context is created, and easier to change how it is created later.
Reviewed By: javache
Differential Revision: D3529843
fbshipit-source-id: 8ed5a9861ebefd4b9e0f7155db8587dcf0442b7a
Summary: There's no reason for this; setUp is once-and-done. Probably just trying to ignore the incorrect clang warning.
Reviewed By: javache
Differential Revision: D3528494
fbshipit-source-id: e4f986df8d097e4720dfd4a51e7fb6c9c9b5108f
Summary: I think this obscures more than it helps. Remove it.
Reviewed By: javache
Differential Revision: D3528677
fbshipit-source-id: d90a636a6e34b66563d9a02e255c6ebc4cee1294
Summary:
Ideally, native hooks should not require any sort of reference to self. Pull all those that fulfill this criteria into a class method (to make it impossible to accidentally capture self).
Future diffs will pull more and more hooks into this category.
Reviewed By: javache
Differential Revision: D3528558
fbshipit-source-id: 270c5bec53674a91ec2129d55e5cad59440a51da
Summary: It's just a simple helper. It's actually more readable and performant when inlined.
Reviewed By: javache
Differential Revision: D3528540
fbshipit-source-id: 8086770f7fd88b40623dc943c715deb4f9fd9262
Summary: It's not widely used, and you can do something equivalent anyway by using existing public API.
Reviewed By: javache
Differential Revision: D3518896
fbshipit-source-id: 6995a5d840aecfff4ffd78ac43f3f592a4f47f91
Summary:
We already do this on Android, and it allows uw to avoid doing this global object lookup for every call. Since there's only a couple of global functions we ever call, we should consider caching all of them in the new bridge.
I didn't ValueProtect/ValueUnprotect since these are already globals, and those methods are not exposed on the JSC wrapper.
Reviewed By: mhorowitz
Differential Revision: D3411487
fbshipit-source-id: 7feaf8803665b77d649e84edad875d31c5acee4b
Summary: Expose the ability to provide extra information to Systrace events from JS. This is specifically useful for instrumenting generic recursive method that are defined completely through their params.
Reviewed By: tadeuzagallo
Differential Revision: D3423595
fbshipit-source-id: 7f2dedf02bf901401a6b391b85b1a0bb6782349c
Summary: The notification was previously sent from a block that only existed if RCT_DEV. This makes us always send this notification.
Reviewed By: majak
Differential Revision: D3235070
fb-gh-sync-id: bf3488d439bc2253fd12cbb10f670f54bb37eb6e
fbshipit-source-id: bf3488d439bc2253fd12cbb10f670f54bb37eb6e
Summary:When JSC throws an error on startup (e.g. a SyntaxError) or when invoking a method that is not caught by RCTExceptionsManager, we previously just reported is a native error, with a (useless) native stack trace in the redbox. This changes that behaviour to report a JS stacktrace.
The same issue was previously reported here: https://github.com/facebook/react-native/pull/5677
Reviewed By: majak
Differential Revision: D3037387
fb-gh-sync-id: 06f8333e0eb50dcef0b26284754262301b8a5f08
fbshipit-source-id: 06f8333e0eb50dcef0b26284754262301b8a5f08
Summary:The 200ms timeout was causing resource issues and causing a lot of overhead when you're not running the devtools, since it will basically create a new socket every 200ms.
Also clean up the way we do logging so it's completely compiled out in prod, and standardize all the names we use for threading to lowercase react.
Reviewed By: frantic
Differential Revision: D3115975
fb-gh-sync-id: e6e51c0621d8e9fc4eadb864acd678b8b5d322a1
fbshipit-source-id: e6e51c0621d8e9fc4eadb864acd678b8b5d322a1
Summary:We were calling `CFRunLoopStop` from `-dealloc` in the `JSCExecutor`, but dealloc
is not guaranteed to run in the same thread. Move it to `-invalidate` instead.
Reviewed By: javache
Differential Revision: D3092645
fb-gh-sync-id: 94b51fec4a9fe0784feeb83d1b0c41de1cd7c052
fbshipit-source-id: 94b51fec4a9fe0784feeb83d1b0c41de1cd7c052
Summary:`flowIDMap` lives on the bridge to map from the IDs used for the flow events in
JS and the ones generated by `RCTProfile` in the native side.
It was being accessed from multiple threads (the various modules' queues in the
bridge and the JS thread), so we lock before touching it.
Reviewed By: javache
Differential Revision: D3102745
fb-gh-sync-id: 93d012d124e8b5d1a390c10a98ef5e3a068ccf63
fbshipit-source-id: 93d012d124e8b5d1a390c10a98ef5e3a068ccf63
Summary:We found that moving the preloaded modules to the startup section of the RAM Bundle improves TTI quite a bit by saving lots of through the bridge calls and injecting multiple modules at once on JSC. However, doing this on a non hacky way required a lot of work. The main changes this diff does are:
- Add to `BundleBase` additional bundling options. This options are fetched based on the entry file we're building by invoking a module that exports a function (`getBundleOptionsModulePath`).
- Implement `BundleOptions` module to include the `numPreloadedModules` attribute as a bundle additional option. This value is computed by getting the dependencies the entry file has and looking for the first module that exports a module we don't want to preload. The `numPreloadedModules` attribute is then used to decide where to splice the array of modules.
- Additional kung fu to make sure sourcemaps work for both preloaded and non preloaded modules.
Reviewed By: davidaurelio
Differential Revision: D3046534
fb-gh-sync-id: 80b676222ca3bb8b9eecc912a7963be94d3dee1a
shipit-source-id: 80b676222ca3bb8b9eecc912a7963be94d3dee1a
Summary:It was hard to understand which parts of the shadowview API are designed to be called only on the root view, and which were applicable to any view.
This diff extracts rootview-specific logic out into a new RCTRootShadowView class.
Reviewed By: majak
Differential Revision: D3063905
fb-gh-sync-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
shipit-source-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
Summary: For RAM bundling we don't want to hold the entire bundle in memory as that approach doesn't scale. Instead we want to seek and read individual sections as they're required. This rev does that by detecting the type of bundle we're dealing with by reading the first 4 bytes of it. If we're dealing with a RAM Bundle we bail loading.
Reviewed By: javache
Differential Revision: D3026205
fb-gh-sync-id: dc4c745d6f00aa7241203899e5ba136915efa6fe
shipit-source-id: dc4c745d6f00aa7241203899e5ba136915efa6fe
Summary:The AlertViewIOS component takes in a 'defaultValue' for the text input but never actually sets it, this PR actually sets the value.
Closes https://github.com/facebook/react-native/pull/6257
Differential Revision: D3052412
Pulled By: nicklockwood
fb-gh-sync-id: 32285330f17ccf47189dbc8fcab48f3712fee59b
shipit-source-id: 32285330f17ccf47189dbc8fcab48f3712fee59b
Summary:This rev adds support for production sourcemaps on RAM.
When we inject a module into JSC we use the original `sourceURL` and specify the `startingLineNumber` of the module relative to a "regular" bundle. By doing so, when an error is thrown, JSC will include the provided `sourceURL` as the filename and will use the indicated `startingLineNumber` to figure out on which line the error actually occurred.
To make things a bit simpler and avoid having to deal with columns, we tweak the generated bundle so that each module starts on a new line. Since we cannot assure that each module's code will be on a single line as the minifier might break it on multiple (UglifyJS does so due to a bug on old versions of Chrome), we include on the index the line number that should be used when invoking `JSEvaluateScript`. Since the module length was not being used we replaced the placeholder we have there for the line number.
Reviewed By: javache
Differential Revision: D2997520
fb-gh-sync-id: 3243a489cbb5b48a963f4ccdd98ba63b30f53f3f
shipit-source-id: 3243a489cbb5b48a963f4ccdd98ba63b30f53f3f
Summary:At the moment, to initialize a React Native app, the entire JS bundle needs to be loaded. Parsing JS code takes a while which makes paying for every feature the app has very expensive on start up. Even worse, as the bundle gets bigger and bigger because the app has more and more features, start up time becomes slower.
This rev introduces the few remaining pieces of infrastructure to load JS modules incrementally. This way, on start up we only inject into JSC the modules we actually need. More importantly, by using this piece of infrastructure, the app start up time won't be affected as the JS bundle increases it's size.
Props to davidaurelio and tadeuzagallo for the original work. I'm just wrapping their work.
Differential Revision: D2995425
fb-gh-sync-id: caaaa880b5370c3bb36a11ae694dc303cd53d0e2
shipit-source-id: caaaa880b5370c3bb36a11ae694dc303cd53d0e2
Summary:Fixes #6281
The JS executor is invalidated from `[RCTBatchedBridger stopLoadingWithError:]`
which prevented another blocks that depended on the executor to run in the bridge
invalidation.
Reviewed By: javache
Differential Revision: D3018299
fb-gh-sync-id: 4f482b9b697bfabd24b405398d25c72b9e1a3c84
shipit-source-id: 4f482b9b697bfabd24b405398d25c72b9e1a3c84
Summary:
public
Expose JS hooks to create flow events in systrace (the nice arrows to show async work flow) +
add support to the showing all the work enqueued from the JS thread as added in D2743733
Depends on D2743733
Reviewed By: jspahrsummers
Differential Revision: D2815293
fb-gh-sync-id: 4278f61a67a6e78cf2704bacce34b1389328c6df
Summary:
public
To make sourcemaps work on Hot Loading work, we'll need to be able to serve them for each module that is dynamically replaced. To do so we introduced a new parameter to the bundler, namely `entryModuleOnly` to decide whether or not to process the full dependency tree or just the module associated to the entry file. Also we need to add `//sourceMappingURL` to the HMR updates so that in case of an error the runtime retrieves the sourcemaps for the file on which an error occurred from the server.
Finally, we need to refactor a bit how we load the HMR updates into JSC. Unfortunately, if the code is eval'ed when an error is thrown, the line and column number are missing. This is a bug/missing feature in JSC. To walkaround the issue we need to eval the code on native. This adds a bit of complexity to HMR as for both platforms we'll have to have a thin module to inject code but I don't see any other alternative. when debugging this is not needed as Chrome supports sourceMappingURLs on eval'ed code
Reviewed By: javache
Differential Revision: D2841788
fb-gh-sync-id: ad9370d26894527a151cea722463e694c670227e
Summary:
public
This exposes a proper API for adding synchronous callbacks to JS, as an optional feature of the executor.
This is based on nicklockwood's work in D2764492, but avoids refactoring bridge/executor interactions for the time being, since we agree on this API and can move the actual callsites around later.
Reviewed By: nicklockwood
Differential Revision: D2799506
fb-gh-sync-id: af209d9a0be927f3404205feb16e59745cc37aec
Summary:
public
Expose JS hooks to create flow events in systrace (the nice arrows to show async work flow) +
add support to the showing all the work enqueued from the JS thread as added in D2743733
Depends on D2743733
Reviewed By: jspahrsummers
Differential Revision: D2773664
fb-gh-sync-id: 4a8854b17b4741b882f5f2cc425e4237a5e4b3eb
Summary:
public
Until we support this fature on OSS, don't show the menu option.
Reviewed By: vjeux
Differential Revision: D2791198
fb-gh-sync-id: 11b66d467c1ab784bbf549b893d0a3abd69e2741
Summary:
public
Implement all the necessary glue code for several diffs submitted before to get Hot Loading work end to end:
- Simplify `HMRClient`: we don't need to make it stateful allowing to enable and disable it because both when we enable and disable the interface we need to reload the bundle.
- On the native side we introduced a singleton to process the bundle URL. This new class might alter the url to include the `hot` attribute. I'm not 100% sure this is the best way to implement this but we cannot use `CTLSettings` for this as it's are not available on oss and I didn't want to contaminate `RCTBridge` with something specific to hot loading. Also, we could potentially use this processor for other things in the future. Please let me know if you don't like this approach or you have a better idea :).
- Use this processor to alter the default bundle URL and request a `hot` bundle when hot loading is enabled. Also make sure to enable the HMR interface when the client activates it on the dev menu.
- Add packager `hot` option.
- Include gaeron's `react-transform` on Facebook's JS transformer.
The current implementation couples a bit React Native to this feature because `react-transform-hmr` is required on `InitializeJavaScriptAppEngine`. Ideally, the packager should accept an additional list of requires and include them on the bundle among all their dependencies. Note this is not the same as the option `runBeforeMainModule` as that one only adds a require to the provided module but doesn't include all the dependencies that module amy have that the entry point doesn't. I'll address this in a follow up task to enable asap hot loading (9536142)
I had to remove 2 `.babelrc` files from `react-proxy` and `react-deep-force-update`. There's an internal task for fixing the underlaying issue to avoid doing this horrible hack (t9515889).
Reviewed By: vjeux
Differential Revision: D2790806
fb-gh-sync-id: d4b78a2acfa071d6b3accc2e6716ef5611ad4fda
Summary:
public
This diff adds infra to both the Packager and the running app to have a WebSocket based connection between them. This connection is toggled by a new dev menu item, namely `Enable/Disable Hot Loading`.
Reviewed By: vjeux
Differential Revision: D2787621
fb-gh-sync-id: d1dee769348e4830c28782e7b650d025f2b3a786
Summary:
public
Rename the executor to so it actually says something about the implementation.
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2759688
fb-gh-sync-id: 5b1ac447e75109fbbc2ee71c804710d9926785aa
Summary:
public
Rename `RCTPerformanceNow` to `nativePerformanceNow` to be consistent with Android
and the pattern we've been following where the native functions exposed to JSC
are prefixed with `native`.
Also change it to return fractional milliseconds, as the web (`performance.now`)
does: https://developer.mozilla.org/en-US/docs/Web/API/Performance/now
Reviewed By: mikearmstrong001
Differential Revision: D2755287
fb-gh-sync-id: 2acada5673633858ae0bbcdcfae554183e36cb24
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
Clean up the `RCTContextExecutor` a little bit by converting the exposed hooks to use the ObjC API.
Reviewed By: nicklockwood
Differential Revision: D2757363
fb-gh-sync-id: c6f5f53c5c1adb78af1cdb449268b6b3cc9740e8
Summary:
Extract JSC profiler API which can now be used even if profiler is unavailable.
public
Reviewed By: tadeuzagallo
Differential Revision: D2749217
fb-gh-sync-id: 1ffa6f37323ea0ddbda3fdacfdf8a9b360185b2e
Summary:
BridgeProfiling.setEnabled used a one off eval. Let's use the bridge to do this like everything else. This is already what the Android equivalent is doing.
public
Reviewed By: tadeuzagallo
Differential Revision: D2745059
fb-gh-sync-id: 5b633365b8cfc8abc6b80255e82ef3053ead9b50
Summary:
public
Rename the `BridgeProfiling` JS module to `Systrace`, since it's actually just
an API to Systrace markers.
This should make it clearer as we add more perf tooling.
Reviewed By: jspahrsummers
Differential Revision: D2734001
fb-gh-sync-id: 642848fa7340c545067f2a7cf5cef8af1c8a69a2
Summary:
public
More people wanted to understand the motivation behind the intentional retain
cycle in `RCTJavaScriptContext`, add a small comment with some context.
Reviewed By: jspahrsummers
Differential Revision: D2738930
fb-gh-sync-id: d8c950778eb6bf3eaca627aabb6c98335d25d1fc
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: This thread is effectively the "main thread" for JavaScript code in React Native applications, so it should have as high a quality-of-service as possible.
public
Reviewed By: javache, nicklockwood
Differential Revision: D2641878
fb-gh-sync-id: 3c60c1abeeab9e7405d6fc9602e0d4ccfab1ea1b
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
Pieter De Baets
Alexey Lang
Indragie Karunaratne
Ben Nham
Adam Ernst
David Aurelio
Skotch Vail
Marc Horowitz
Mart?n Bigio
Tadeu Zagallo
Nick Lockwood
Morgan Pretty
Scott Kyle
Adam Miskiewicz
Justin Spahr-Summers
Fada Chen
Milen Dzhumerov
Sebastian Markbage
Grant Paul