Summary: This is caused by receiving \u2028/2029 in callbacks/function calls. The correct solution is to not evaluate these strings as scripts but instead parse them as json and pass them through the JSC API.
Reviewed By: lexs
Differential Revision: D3543098
fbshipit-source-id: 4d8acce1d510bb17361d32103d4738fc0208b0a8
Summary:
Developing with react-native on Linux, I found myself facing this message:
The problem is actually quite simple: I hadn't used `react-native start` before starting `react-native run-android`, which caused this error, both on an emulator and a real Android device. As the message is currently unhelpful, but can be shown because of a simple mistake, I updated it.
~~Additionally, I clarified the fact that `react-native start` is still necessary on Linux, updating a title on the Linux and Windows Support documentation page.~~
Closes https://github.com/facebook/react-native/pull/7396
Differential Revision: D3305078
fbshipit-source-id: 2d87e02ff2ad15d8239fbcc0ada4a4e67b982e94
Summary: Maybe a slight perf improvement. Also helps get rid of the 'ReferenceError: __fbBatchedBridge' error in favor of a more explicit "you're calling JS functions before the bundle is loaded"
Differential Revision: D3142966
fb-gh-sync-id: 6a50efe7d1634248107c8c95a3e014cb263a9ca5
fbshipit-source-id: 6a50efe7d1634248107c8c95a3e014cb263a9ca5
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:Making buck rebundle the worker script on every JS change is insanely slow. This allows the script to be downloaded for debug builds.
The plan is to couple this with an implementation of `require.resolve` which will automatically insert the correct packager network path in DEV builds and the correct local path in release builds.
e.g.
var worker = new Worker(require.resolve('WebWorkerSample_getPrimesBetween.js'));
Reviewed By: lexs
Differential Revision: D2939279
fb-gh-sync-id: fbf64bbf1df1649b44e4b98ac504d095c10104a6
shipit-source-id: fbf64bbf1df1649b44e4b98ac504d095c10104a6
Summary: Updates the sample to use native modules.
Differential Revision: D2932319
fb-gh-sync-id: 9dc12789839ec2d65e98205508d958d0c8c5b46e
shipit-source-id: 9dc12789839ec2d65e98205508d958d0c8c5b46e
Summary:To support native modules in web workers, native modules need to have an notion of the JS executor/thread that called into them in order to respond via Callback or JS module call to the right executor on the right thread.
ExecutorToken is an object that only serves as a token that can be used to identify an executor/message queue thread in the bridge. It doesn't expose any methods. Native modules Callback objects automatically have this ExecutionContext attached -- JSModule calls for modules that support workers will need to supply an appropriate ExecutorToken when retrieving the JSModule implementation from the ReactContext.
Reviewed By: mhorowitz
Differential Revision: D2965458
fb-gh-sync-id: 6e354d4df8536d40b12d02bd055f6d06b4ca595d
shipit-source-id: 6e354d4df8536d40b12d02bd055f6d06b4ca595d
Summary:In testing, I've found that there's no good way to return stack traces to the server for exceptions that happen in dtor's. If the dtor is not marked nothrow(false), the exceptions are uncatchable (and bubble up as a std::abort without exception info) and if annotated properly, the program instead crashes trying to resume the stack, again a std::abort without exception info.
Instead, I created a separate destroy method that can be called (and protected via fbjni) to make the dtor's no longer execute code that may throw. Note that we don't really expect the code that was previously in ~JSCExecutor() to throw, but it was in production and we had absolutely no info to help debug it.
Reviewed By: mhorowitz
Differential Revision: D2989999
fb-gh-sync-id: 4cf9de5e0592fe6830a9903375363a78e1339a94
shipit-source-id: 4cf9de5e0592fe6830a9903375363a78e1339a94
Summary: Now that web workers are just JSCExecutors, we can move forward with adding native module support. The means we need to supply the worker with a correct __fbBatchedBridgeConfig global so it can appropriately set up its JS MessageQueue. Unfortunately, native modules can't support multiple JS execution contexts out-of-the-box, so we need to whitelist those modules that actually can be referenced from a webworker. In order to do that, we add the supportsWebWorkers call in NativeModule and the SupportsWebWorkers annotation for JS modules. These add metadata to __fbBatchedBridgeConfig which allows us to create a new config with only those modules that support web workers.
Reviewed By: lexs
Differential Revision: D2927091
fb-gh-sync-id: 9b47331253b277940b552e7d899198b5f0a3ed8c
shipit-source-id: 9b47331253b277940b552e7d899198b5f0a3ed8c
Summary: Part of the plan to make web workers able to call native modules. We will reuse the infrastructure already present in JSCExecutor to allow web workers to call native modules via the Bridge.
Reviewed By: mhorowitz
Differential Revision: D2926896
fb-gh-sync-id: 259b766c46f79bbb5df9d1c648237b81fc1cc1f9
shipit-source-id: 259b766c46f79bbb5df9d1c648237b81fc1cc1f9
Summary:
Everything below the bridge interacts with just a MessageQueueThread. The implementation (JMessageQueueThread) is injected from react/jni.
public
Reviewed By: astreet
Differential Revision: D2905178
fb-gh-sync-id: 8b138e746d5a96dd70837bb2149cd4e188fcdacc
Summary:
This just moves the jni code that actual figures out the cache dir into OnLoad.cpp and then passes it down to the JSCEXecutorFactory.
public
Reviewed By: astreet
Differential Revision: D2905176
fb-gh-sync-id: bedf52fbeaab6beabac25c87aad00a98ddf182f7
Summary:
So, this makes it so a set of behaviors that require accessing java can be injected from the jni/ folder. The behaviors are logging, perf logging, log markers and loading script from assets.
I'd argue that these should all actually be encapsulated by interfaces that are passed to the JSCExecutor/others (and I'd say that's regardless of whether they are injected from jni/ or not), but I wanted to stick to the least disruptive pattern for these changes.
public
Reviewed By: astreet
Differential Revision: D2905168
fb-gh-sync-id: 7c8c16cb77b8fc3d42750dacc6574259ad512ac2
Summary:
Instead of using `UINT32_MAX` in C++ code, use `std::numeric_limits<uint32_t>::max()`. The `UINT32_MAX` macro is not available in all compilation setups
Closes https://github.com/facebook/react-native/pull/5481
Reviewed By: svcscm
Differential Revision: D2854545
Pulled By: androidtrunkagent
fb-gh-sync-id: 00a70b429c78bcf120866bb59fae2ffe6330a910
Summary:
public
This adds the ability to load “unbundles” in RN android apps. Unbundles are created by invoking the packager with the `unbundle` command rather than `bundle`.
The code detects usage of an “unbundle” by checking for the existence of a specific asset.
Reviewed By: astreet
Differential Revision: D2739596
fb-gh-sync-id: d0813c003fe0fa7b47798b970f56707079bfa5d7
Summary:
public
Previously we did no cleanup when the executor was torn down and didn't expose a way to tear down the worker from JS. Now we do.
Termination happens synchronously and waits the the worker's MessageQueueThread to finish and join.
Reviewed By: mhorowitz
Differential Revision: D2815240
fb-gh-sync-id: 786beb30d4d64556586b91727f32e379c667a965
Summary:
public
I wasn't obeying the web workers API correctly: I had missed that the message isn't sent directly but is attached to a message object in a data field.
Reviewed By: lexs
Differential Revision: D2811247
fb-gh-sync-id: 8e51414766e0cfe382ee9bdde8f0d66e269cb83a
Summary:
public
Implements a basic WebWorkers API that allows posting messages between the main JS thread and a worker background thread. It follows the existing webworkers API from JS. Currently passed memory needs to be JSON serializable and is copied (unfortunately, this is what webkit does as well, but with a more advanced serialization/deserialization process).
There are a lot of TODO's: I'll add tasks for them once this is accepted.
Reviewed By: lexs
Differential Revision: D2779349
fb-gh-sync-id: 8ed04c115d36acf0264ef1f6a12a65dd0c14ff18
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
Andy Street
Charles Dick
Hugo Agbonon
Michał Gregorczyk
Pavlo Kushnir
Tadeu Zagallo
Andrei Coman
Nick
Marc Horowitz
Dan Caspi
Chris Hopman
Scott Kyle
Adam Miskiewicz
David Aurelio
David Aurelio
Mike Armstrong
Sebastian Markbage
