9b94a541d8
Summary: ## Context For now, assume TurboModules doesn't exist. **What happens when we call an async NativeModule method?** Everytime JS calls an async NativeModule method, we don't immediately execute it. The legacy infra pushes the call into some queue managed by `MessageQueue.js`. This queue is "flushed" or "emptied" by the following events: - **Flushed:** A C++ -> JS call. NativeModule async methods can called with an `onSuccess` and/or `onFail` callback(s). Calling `NativeToJsBridge::invokeCallback` to invoke one of these callbacks is one way for ObjC++/C++/Java to call into JS. Another way is via JSModule method calls, which are initiated by `NativeToJsBridge::callFunction`. - **Flushed:** When `JSIExecutor::flush` is called. Since TurboModules don't exist, this only happens when we call `JSIExecutor::loadApplicationScript`. - **Emptied:** When more than 5 ms have passed, and the queue hasn't been flushed/emptied, on the next async NativeModule method call, we add to the queue. Afterwards, we empty it, and invoke all the NativeModule method calls. **So, what's the difference between flushed and emptied?** > Note: These are two terms I just made up, but the distinction is important. If the queue was "flushed", and it contained at least one NativeModule method call, `JsToNativeBridge` dispatches the `onBatchComplete` event. On Android, the UIManager module is the only module that listens to this event. This `onBatchComplete` event doesn't fire if the queue was "emptied". **Why does any of this matter?** 1. TurboModules exist. 2. We need the TurboModules infra to have `JsToNativeBridge` dispatch `onBatchComplete`, which depends on: - **Problem 1:** The queue being flushed on calls into JS from Java/C++/ObjC++. - **Problem 2:** There being queued up NativeModule async method calls when the queue is flushed. In D14656466, fkgozali fixed Problem 1 by making every C++/Java/Obj -> JS call from TurboModules also execute `JSIExecutor::flush()`. This means that, with TurboModules, we flush the NativeModule async method call queue as often as we do without TurboModules. So far, so good. However, we still have one big problem: As we convert more NativeModules to TurboModules, the average size of the queue of NativeModule method calls will become smaller and smaller, because more NativeModule method calls will be TurboModule method calls. This queue will more often be empty than not. Therefore, we'll end up dispatching the `onBatchComplete` event less often with TurboModules enabled. So, somehow, when we're about to flush the NativeModule method call queue, we need `JsToNativeBridge` to understand that we've executed TurboModule method calls in the batch. These calls would have normally been queued, which would have led the queue size to be non-zero. So if, during a batch, some TurboModule async method calls were executed, `JsToNativeBridge` should dispatch `onBatchComplete`. **So, what does this diff do?** 1. Make `Instance` responsible for creating the JS `CallInvoker`. 2. Make `NativeToJsBridge` responsible for creating the native `CallInvoker`. `Instance` calls into `NativeToJsBridge` to get the native `CallInvoker`. 3. Hook up `CatalystInstanceImpl`, the Android bridge, with the new JS `CallInvoker`, and the new native `CallInvoker`. This fixes `onBatchComplete` on Android. iOS work is pending. Changelog: [Android][Fixed] - Ensure `onBatchComplete` is dispatched correctly with TurboModules Reviewed By: mdvacca Differential Revision: D20717931 fbshipit-source-id: bc3ccbd6c135b7f084edbc6ddb4d1e3c0c7e0875 |
||
|---|---|---|
| .. | ||
| NativeModuleExample | ||
| RCTTest | ||
| RNTester | ||
| RNTester-tvOS | ||
| RNTesterIntegrationTests | ||
| RNTesterPods.xcodeproj | ||
| RNTesterPods.xcworkspace | ||
| RNTesterUnitTests | ||
| android/app | ||
| e2e | ||
| js | ||
| .eslintrc | ||
| Gemfile | ||
| Podfile | ||
| Podfile.lock | ||
| README.md | ||
README.md
RNTester
The RNTester showcases React Native views and modules.
Running this app
Before running the app, make sure you ran:
git clone https://github.com/facebook/react-native.git
cd react-native
yarn install
Running on iOS
Both macOS and Xcode are required.
- Install CocoaPods. We installing CocoaPods using Homebrew:
brew install cocoapods - Run
cd RNTester; pod install - Open the generated
RNTesterPods.xcworkspace. This is not checked in, as it is generated by CocoaPods. Do not openRNTesterPods.xcodeprojdirectly.
Running on Android
You'll need to have all the prerequisites (SDK, NDK) for Building React Native installed.
Start an Android emulator.
cd react-native
./gradlew :RNTester:android:app:installJscDebug
./scripts/packager.sh
Note: Building for the first time can take a while.
Open the RNTester app in your emulator.
If you want to use a physical device, run adb devices, then adb -s <device name> reverse tcp:8081 tcp:8081.
See Running on Device for additional instructions on using a physical device.
Running with Buck
Follow the same setup as running with gradle.
Install Buck from here.
Run the following commands from the react-native folder:
./gradlew :ReactAndroid:packageReactNdkLibsForBuck
buck fetch rntester
buck install -r rntester
./scripts/packager.sh
Note: The native libs are still built using gradle. Full build with buck is coming soon(tm).
Running Detox Tests on iOS
Install Detox from here.
To run the e2e tests locally, run the following commands from the react-native folder:
yarn build-ios-e2e
yarn test-ios-e2e
These are the equivalent of running:
detox build -c ios.sim.release
detox test -c ios.sim.release --cleanup
These build the app in Release mode, so the production code is bundled and included in the built app.
When developing E2E tests, you may want to run in development mode, so that changes to the production code show up immediately. To do this, run:
detox build -c ios.sim.debug
detox test -c ios.sim.debug
You will also need to have Metro running in another terminal. Note that if you've previously run the E2E tests in release mode, you may need to delete the RNTester/build folder before rerunning detox build.
Building from source
Building the app on both iOS and Android means building the React Native framework from source. This way you're running the latest native and JS code the way you see it in your clone of the github repo.
This is different from apps created using react-native init which have a dependency on a specific version of React Native JS and native code, declared in a package.json file (and build.gradle for Android apps).