Host/Instance Management in RN

[stmoy]

Introduction

Note: This issue describes a more stable host/instance infrastructure that is generally applicable to the React Native platform. However, during the conversation/prototyping phase is happening relative to the Windows platform first.

The existing React Native implementation (on Windows) for host and instance management infrastructure suffers from a variety of issues, including:

• Difficulty managing multiple threads
• Inability to support multiple root views
• Memory leaks

The goal/purpose of this proposal is to provide a framework-grade implementation for React Native for Windows. Longer term, this model can be adapted for the React Native core platform across iOS/Android as well.

The Core of It

High-level design:

There are two main object types that are going to be in the ReactNativeHost:

• IReactHost – to host a ReactInstance
• IReactViewHost – to host a ReactRootView

The IReactHost holds one ReactInstance.

• The IReactHost has methods and events concerning the RN instance lifetime managment such as ReloadInstance, DestroyInstance, etc.
• IReactHost handles loading of JavaScript user and platform bundles.
• It is initialized from ReactOptions.
• Each IReactHost may have zero or more IReactViewHost instances.
• In the future: IReactHost may configure and provide a JavaScript engine as input

The IReactViewHost is associated with a corresponding platform specific ReactRootView component.

• The IReactViewHost has methods and events concerning lifetime of an individual React view defined by a registered in JavaScript React App component.
• The association is done with help of IReactViewInstance interface.
• The IReactViewHost is created from IReactHost with ReactViewOptions and passed to a platform specific ReactRootView component.

ReactInstance

• Developers will not interface directly with ReactInstance, but will instead use ReactContext which is a PropertyBag for user data
• ReactInstance is an immutable object that can be observed from any thread

ReactApplication

• Initializes a ReactHost from the parameters passed to it (eg. web debugging settings)

Discussion points

• Our plan is to validate this work on RN4W first, in the hope that it will be broadly applicable to the RN platform at large.
• The introduction section outlines a few specific issues to the existing host/instance infrastructure. Are these issues specific to Windows, or are they general problems?
• How do other out-of-tree platforms fit into this model?

[stmoy]

cc @vmoroz @acoates-ms @harinikmsft @jonthysell

[acoates-ms]

Much of this is also an opportunity for unification of a bunch of code. Many of these problems are currently solved by platform specific implementations. Android has a bunch of java classes that perform much the same need as these. And iOS has a bunch of objective C classes that do the same.

To solve these problems in react-native-windows we had to write a new implementation in C++ as the Java and ObjC code is platform specific. We are working on making the react-native-windows implementation completely platform agnostic C++. With the idea that it can be shared cross platform. And eventually become part of the shared cxxcommon code in react-native. Hopefully this becomes the basis of the next version of react-native instance management infra. This will allow more code sharing between the platforms -- which should mean all the platforms get better tested, and more consistent in behavior with each other, and reduce total cost of new features.

[ejanzer]

@stmoy Thanks for writing this up! Like @acoates-ms said I think some of the issues you described are solved by platform-specific implementations, but some of them aren't really solved at all - we have issues with instance management and destruction on Android, for example, that we don't have a great solution for right now. So I'm definitely interested in seeing how we can incorporate some of what Microsoft has learned working on RNW into RN core (in particular, into the new "bridgeless" core that we're currently working on).

Here are a few of the areas for discussion I'd like to explore:

• Threading model: What is the threading model for RNW? How does it interact with the message queue threads in RN core? What changes should we consider making to core? Should we consider using C++ threads?
• Runtime creation and management: One of the changes we're thinking of making for bridgeless mode is passing in the jsi::Runtime from above, and providing access to it using a pattern we call RuntimeExecutor (it's already in Fabric: https://github.com/facebook/react-native/blob/aee88b6843cea63d6aa0b5879ad6ef9da4701846/ReactCommon/utils/RuntimeExecutor.h). We'd probably have to discuss how that would fit into this instance management architecture (at the very least for when we need to support bridgeless mode in RNW). (I should probably write up a separate proposal on this).
• The relative order in which ReactHost, ReactInstance, ReactViewHost, etc. are all created and bound to each other: There are some slight differences in how we currently do this, and we have some features that we want to make sure we can support in the future (in particular, pre-rendering a ReactViewHost/ReactRootView in JS, and attaching it to the native view later).
• JS bundle loading: This is one area where there are a lot of opinions about how to do this, and FB's requirements definitely don't reflect what the OSS community wants. I'm curious about the platform vs. user bundles in this implementation - is that something that we would incorporate into RNW/RN core? Or is that a particular requirement for Office? We don't really prioritize the "headless"/UI-less use case for RN right now.
• Multi-instance support: This is another area that we're not particularly concerned with at FB, although I know this is important for some users and other platforms.

I also have some more in-the-weeds questions about the code, but these are the major discussion topics I thought of.

[vmoroz]

@ejanzer, just a few thoughts about your bullet points above:

• Threading model. Our approach is quite similar with the current RN code. We have dispatch queues that have C++ interface, but they are implemented on top of platform-specific scheduling mechanisms. E.g. on Android we use managed threads from the Android thread pool. Using C++ threads directly is inefficient and I guess it would not work well with Java managed threads. I think ideally we should decouple the message queue creation from the rest of the RN code. From the point of view of RN it should just use three or more different queues: JS queue, UI queue, and one or more queues based on thread pool. The queue implementation should rely on platform-specific schedulers. Currently in our code ReactHost and ReactInstance use thread pool based queue for their state management. Native modules could choose any queue that works best for them. For the bridge-less implementation, I guess, most work will happen in JS queue. But we still need mechanism to interact between JS and UI queues. Also, some native modules may decide to be 'good citizens' and use thread-based queues to manage their state. In that case we still have a task to manage interaction between threads. I think the best approach here is to rely on industry 'standard' promises/futures. Then we can switch to co-routines (await/co_await) which is a significant improvement of the promises/futures concepts and work well together.
• Runtime creation and management. I am looking forward to learn more about it.
• ReactHost, ReactInstance, ReactViewHost creation order. The current ReactHost implementation is done to support pre-loading scenarios. We first initialize ReactHost and ReactInstance. They start to load JS bundle. It all happens in JS and thread-pool based queues. Meantime in UI queue we can create ReactRootView and attach it. By the time the ReactRootView is attached, the ReactInstance could do a lot of work to prepare the JS-based code. Currently UI tree starts to build only when we attach the ReactRootView, but I think it must be possible to start to build it as soon as the ReactViewHost is initialized in the background.
• JS bundle loading, we still argue about it. There are pluses and minuses for both approaches: single bundle vs multiple bundles. We should update this thread when we have more thoughts about it. Though, I believe we must support multiple bundles and let developers to choose whether to use a single or multiple bundles.
• Multi-instance support. The current ReactHost design mostly targets scenario where we have multiples ReactRootViews per instance, but in Office we currently have multiple ReactInstances by having multiple ReactHosts. Though, in future we consider to consolidate them into a single ReactHost/ReactInstance with multiple views to save resources. In any case, the current support for multiple instances will be kept.

[ejanzer]

@vmoroz

Thanks for the response!

Threading model: I like the promises/futures model, and this is actually pretty similar to what I'm doing right now for bridgeless RN on Android (although I'm doing it in Java using Bolts-Tasks right now). We're not planning on making any significant changes to the RN threading model right now - I just wanted to clarify that you weren't doing anything different in your code that we'd have to reconcile.
Runtime creation and management: I think I'll create a separate proposal where we can discuss, I'll update here when I do.
ReactHost, ReactInstance, ReactViewHost creation order: This sounds good, and similar to the use cases we want to support.
JS bundle loading: Yeah, I agree we need to support multiple bundles. I think I'd like to let the community weigh in on exactly what that should look like. We probably don't have to address this immediately. I think there's already some work being done to support this in RN today: facebook/react-native#27844

[ejanzer]

@vmoroz @stmoy I created a proposal for the runtime creation & management discussion, if you want to take a look: #196

[shergin]

Thank you, Steven, for putting this together!

That looks great indeed, I love the idea of unifying the concepts among platforms... and moving everything that possible to C++ (even if something can be done in C++ on more than one platforms, that might sense to do it for that platforms on C++). One of the explicit goals that we have with Fabric (and in general with Venice) is to end up with as little platform-specific code as possible.

Surely it will be practically impossible to make this shift in one step even if we unconditionally agree on everything beforehand, so I think we need to figure out some gradual path forward. I think we should agree on concepts, then on naming, and then start to implement pieces and connect them together.
But even before that, I think we should start to form a list of constraints and features that we need, so we can design API approaches against that list. (E.g. my favorites are "we should be able to use platform threads (foreign to C++) in C++ code" or "we have to have a Surface/RootView instance not only as a native platform View".)
Then we should start design and implement some pieces of that as separate efforts and slowly connect them together. My hope is that focusing on essentials on which we agree, we can end up with simple and clear architecture.

React Native is a quite huge framework, so huge that I don't think we have a single person who has a strong opinion about every single aspect of the framework, so we have to design it as a set of relatively independent units. E.g. I have a lot to say about the proper UI layer (esp. on iOS) but I have limited knowledge about non-UI modules or constrains. Even "simple" things like RuntimeExecutor appears to be quite interesting and somewhat controversial when we discuss details.

The good thing is that we are already doing that with Venice and Fabric, and from what I see mostly aligned with our design ideas.

From the UI/iOS perspective, I think Fabric is quite aligned with the proposed UI (green) part of the schema:
IReactViewHost is RCTSurfacePresenter;
IReactViewInstance is RCTSurface;
ReactRootView is RCTSurfaceHostingView (or RCTSurfaceView if the magic interoperability with UIKit is not required). I probably should create another proposal dedicated to discussing the UI part of the framework architecture where we can decide which part which and why what are the responsibility and so on.

In short, I am saying, let's:

• Be explicit about our values (e.g. perf vs. flexibility), constrains (what's possible on which platform) and desired features (what we want to have and whatnot);
• Agree on terminology (e.g. Surface vs View; what's the difference between Host and Instance);
• Define scopes, sub-efforts, and stakeholders;
• Discuss concrete tech details as part of those efforts;
• Be bold, iterate, and share results.

[vmoroz]

Hi Valentin, these are good points!
I like the iterative approach and that we should discuss the terminology and design.

The terms above is something that we used in Office when we worked on implementing ReactNative.
It would be perfectly fine to change them to something else.
In the diagram above all interfaces are cross-platform, but IReactViewInstance is expected to have platform-specific implementation. Its goal is to 'connect' platform-independent code that runs in a background thread with the platform-specific UI implementation. The following PR is an attempt to merge our Office code that implements this architecture to ReactNative for Windows (RNW): microsoft/react-native-windows#4009 In that implementation the IReactViewInstance is implemented in ReactRootControl.h and ReactRootControl.cpp. The ReactRootView is a XAML control.

The code in that PR is just an initial merge. We must do several iterations to clean it up, rename namespaces and types, and remove a lot of unnecessary layers.
The key points about the new code are:

• Instance management is in C++ code.
• We use Promises/Futures to coordinate work between threads.
• React Instance can be loaded before UI initialization.
• One ReactInstance may have zero or more views.
• Load/Reload/Unload of React Instances is initiated from non-UI code.

The key difference between Host and Instance in this implementation is that Host is a very small object that can exists as long as needed. It can load and unload Instance that is quite expensive because of JavaScript engine. There may be no difference for apps that are completely RN-based, but for apps like Microsoft Word where RN is only used for some UI parts, it can be important because the Host objects allow us to free memory when no RN-UI is shown.

Each Host may have several ViewHosts. It means that the same ReactInstance can use several windows or panels. For example, in Outlook, we can show several popups for personal info about different people using the same ReactInstance.