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 |
||
---|---|---|
.circleci | ||
.github | ||
IntegrationTests | ||
Libraries | ||
RNTester | ||
React | ||
ReactAndroid | ||
ReactCommon | ||
bots | ||
docs | ||
flow | ||
flow-typed/npm | ||
gradle/wrapper | ||
jest | ||
keystores | ||
local-cli | ||
packages | ||
scripts | ||
template | ||
third-party-podspecs | ||
tools/build_defs | ||
.buckconfig | ||
.buckjavaargs | ||
.clang-format | ||
.editorconfig | ||
.eslintignore | ||
.eslintrc | ||
.flowconfig | ||
.flowconfig.android | ||
.gitattributes | ||
.gitignore | ||
.nvmrc | ||
.prettierrc | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
ECOSYSTEM.md | ||
LICENSE | ||
LICENSE-docs | ||
README.md | ||
React-Core.podspec | ||
React.podspec | ||
Releases.md | ||
build.gradle.kts | ||
cli.js | ||
gradlew | ||
gradlew.bat | ||
index.js | ||
interface.js | ||
jest-preset.js | ||
jest.config.js | ||
metro.config.js | ||
package.json | ||
react-native.config.js | ||
react.gradle | ||
rn-get-polyfills.js | ||
runXcodeTests.sh | ||
settings.gradle.kts | ||
template.config.js | ||
yarn.lock |
README.md
React Native
Learn once, write anywhere:
Build mobile apps with React.
Getting Started · Learn the Basics · Showcase · Contribute · Community · Support
React Native brings React's declarative UI framework to iOS and Android. With React Native, you use native UI controls and have full access to the native platform.
- Declarative. React makes it painless to create interactive UIs. Declarative views make your code more predictable and easier to debug.
- Component-Based. Build encapsulated components that manage their state, then compose them to make complex UIs.
- Developer Velocity. See local changes in seconds. Changes to JavaScript code can be live reloaded without rebuilding the native app.
- Portability. Reuse code across iOS, Android, and other platforms.
React Native is developed and supported by many companies and individual core contributors. Find out more in our ecosystem overview.
Contents
- Requirements
- Building your first React Native app
- Documentation
- Upgrading
- How to Contribute
- Code of Conduct
- License
📋 Requirements
React Native apps may target iOS 10.0 and Android 4.1 (API 16) or newer. You may use Windows, macOS, or Linux as your development operating system, though building and running iOS apps is limited to macOS. Tools like Expo can be used to work around this.
🎉 Building your first React Native app
Follow the Getting Started guide. The recommended way to install React Native depends on your project. Here you can find short guides for the most common scenarios:
📖 Documentation
The full documentation for React Native can be found on our website.
The React Native documentation discusses components, APIs, and topics that are specific to React Native. For further documentation on the React API that is shared between React Native and React DOM, refer to the React documentation.
The source for the React Native documentation and website is hosted on a separate repo, @facebook/react-native-website.
🚀 Upgrading
Upgrading to new versions of React Native may give you access to more APIs, views, developer tools, and other goodies. See the Upgrading Guide for instructions.
React Native releases are discussed in the React Native Community, @react-native-community/react-native-releases.
👏 How to Contribute
The main purpose of this repository is to continue evolving React Native core. We want to make contributing to this project as easy and transparent as possible, and we are grateful to the community for contributing bug fixes and improvements. Read below to learn how you can take part in improving React Native.
Code of Conduct
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.
Contributing Guide
Read our Contributing Guide to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes to React Native.
Open Source Roadmap
You can learn more about our vision for React Native in the Roadmap.
Good First Issues
We have a list of good first issues that contain bugs which have a relatively limited scope. This is a great place to get started, gain experience, and get familiar with our contribution process.
Discussions
Larger discussions and proposals are discussed in @react-native-community/discussions-and-proposals.
📄 License
React Native is MIT licensed, as found in the LICENSE file.
React Native documentation is Creative Commons licensed, as found in the LICENSE-docs file.