Summary:
== What ==
Changing the `JSBundleLoader` API, to remove `String getSourceUrl()`, instead `JSBundleLoader.loadScript` now returns the source URL it loaded.
This change has a knock-on effect: We can no longer populate `SourceCodeModule` when we construct it, because at that time, we do not know the source URL.
In order to solve this I have made the following changes:
- Added `CatalystInstance.getSourceURL()`, to return the source URL from the instance after the JS Bundle has been loaded, or `null` otherwise.
- Removed `ReactInstanceManager.getSourceUrl()`, because its only purpose was to populate `SourceCodeModule`.
- Also removed `ReactInstanceManager.getJSBundleFile()` because it was only being used in a test confirming that the `ReactInstanceManager` knew its bundle file as soon as it was constructed, which is no longer necessarily true.
- Initialise `SourceCodeModule` with the `ReactContext` instance it belongs to.
- Override `NativeModule.initialize()` in `SourceCodeModule` to fetch the source URL. When the `SourceCodeModule` is constructed, the context does not have a properly initialised `CatalystInstance`, but by the time we call initialise on it, the `ReactContext` has a `CatalystInstance` and that in turn has a source URL.
== Why ==
The reason for this change is that it allows us to add implementations of `JSBundleLoader`, that cannot determine their source URL until after having performed a load successfully. In particular I plan to introduce `FallbackJSBundleLoader` which will try to load from multiple sources in sequence stopping after the first successful load. As load failures could happen for a variety of reasons, we can't know what the true source URL is without performing the load.
Reviewed By: javache
Differential Revision: D4398956
fbshipit-source-id: 51ff4e289c8723e9d242f23267181c775a6abe6f
Summary: This mimics (some of) the behavior we have on iOS where if you call a JS module method before the JS bundle has started loading, we just queue up those calls and execute them after the bundle has started loading.
Reviewed By: javache
Differential Revision: D4117581
fbshipit-source-id: 58c5a6f87aeeb86083385334d92f2716a0574ba1
Summary:
There was previously a race condition where hasActiveCatalystInstance would return true, but calling a JS module call on it would result in a crash. Now, hasActivtyCatalystInstance will only return true once the instance is actually accepting calls.
I'll follow this up with a more risky diff that gets rid of hasActiveCatalystInstance and just queues JS calls until runJSBundle is called.
Reviewed By: javache
Differential Revision: D4117374
fbshipit-source-id: 60941f68b0906a8213571305c564bfe3d053f51b
Summary:
**Motivation**
I'm working on a project that uses React Native and needs to add direct synchronous bindings to native stuff through the JavaScriptCore C API. This is because it's performance-sensitive and would benefit from the quickest JS->C path. It does this using cross-platform C++ code that works on both iOS and Android. Most of the infrastructure for getting access to the JSC context is already in React Native actually, just had to add a few more things.
(lexs you mentioned to tag you in this pull request)
**Test plan**
Modify the JavaScriptCore context through the `JSContextRef` returned (eg. add an object at global scope) and verify that it exists in JavaScript.
Closes https://github.com/facebook/react-native/pull/10399
Differential Revision: D4080945
Pulled By: lexs
fbshipit-source-id: 6659b7a01e09fd84475adde183c1d3aca2d4cf09
Summary: Add a new interface to JSC that allows loading a file lazily from disk, i.e. using mmap, instead of loading the whole file upfront and copying into the VM.
Reviewed By: michalgr
Differential Revision: D3534042
fbshipit-source-id: 98b193cc7b7e33248073e2556ea94ce3391507c7
Pieter De Baets
Ashok Menon
king6cong
Andy Street
Nikhilesh Sigatapu
Marc Horowitz
Michał Gregorczyk
David Aurelio
Tadeu Zagallo
Clement Genzmer
Alexander Blom
Chris Hopman
Charles Dick