React Native Fabric (UI-Layer Re-architecture)

[kelset]

Intro

With this issue I'd like to try and create a "one stop" for all the information available around the future re-architecture of the UI-Layer of React Native, codenamed "Fabric".

Terminology

• JSI: JavaScript Interface, it's a unified lightweight general purpose API for (theoretically) any JavaScript virtual machine. It enables every other piece of the rearchitecture. (dedicated issue)
• TurboModules: re-architecture of NativeModules, also using JSI. (dedicated issue)
• CodeGen: a tool to "automate" the compatibility between JS and native side. (dedicated issue)

TL;DR

From @axe-fb's blogpost, here's a temporary description of Fabric (please consider that this is not yet finalized, it may change in the future)

In the current architecture, all UI operations (like creating native views, managing children, etc). are handled by a native module called UIManagerModule. The React Reconciller sends UI commands over the bridge, which are eventually handled by this module and delegated to UIImplementation. This in turn creates shadow nodes that represent the layout tree and are passed to Yoga to determine the relative co-ordinates based on the Flex box styles that are passed in from JS.
In the new system, the UI operations are directly exposed to JavaScript as functions using the JSI interface described above. The new UI manager can then create ComponentDescriptors and the Shadow Nodes for specific view types (like Text, View or Images), and then communicate with Java/ObjC to draw platform specific UI.

Available Materials

It was first announced in the "State of React Native 2018" blogpost by @sophiebits.

In July, @hramos linked a broadcast of a tech talk that happened in FB, which covered the ongoing work on the new React Native architecture codenamed "Fabric": facebook.com/hramos/videos/10101317533036249 (go to 8:18 for the presentation start - audio is a bit bad)

Further down the line, it was presented at ChainReact Conf 2018 by @axe-fb in the talk "The State of React Native".

At ReactConf 2018 @axe-fb did a talk about React Native's New Architecture, which also explains the 3 concepts above: JSI, Fabric, TurboModule.

On twitter, @shergin shared a presentation about View Flattening -> https://twitter.com/shergin/status/1058393187079704576?s=09

On twitter, @kmagiera shown a early stage implementation of Fabric working on the RNTester app -> https://twitter.com/kzzzf/status/1064891715457294337

IN Q1 2019, @kelset published a high-level/beginner friendly blogpost about it: https://formidable.com/blog/2019/fabric-turbomodules-part-3/ and did a talk about the whole rearchitecture in April 2019 at React Edinburgh.

@kelset also did a more in-depth talk at React Advanced London in Oct 2019: youtube recording & slides.

As of early Jan 2022, a first version of the docs about Fabric are on the main reactnative.dev website.

SWM published a blogpost on how they added Fabric to one of their libraries: https://blog.swmansion.com/introducing-fabric-to-react-native-screens-fd17bf18858e

Q&A

This is also a place for questions related to this effort and its direction.

[axe-fb]

Kevin's talk about Fabric internals

React Wednesday (July 25 2018)

Recording - https://www.facebook.com/hramos/videos/10101317533036249/

Video - https://www.slideshare.net/axemclion/react-native-fabric-review20180725

[shergin]

We can start a Q&A here where anyone involved can share knowledge and ideas. 😄

I see Fabric as an effort aimed to modernize the rendering layer of React Native. Fabric relies on some new strategies, such as:

• Using C++ for cross-platform "shadow" layer;
• Immutable data structures (Shadow Trees, Props, Events);
• Shared memory ownership (between JS and native);
• JSI as an interop layer between JavaScript and native;
• Type-safe data structures;
• Opt-in synchronous execution where it benefits performance, the UI responsiveness and simplifying inherently-synchronous interop APIs.

Fabric is all about modern, easy-to-interop and performant UI.

[aleclarson]

This sounds really cool. :)

1. What's the timeline for Fabric's first stable release? Is there an issue tracking the progress of development? Will there be an in-depth blog post on the internals?

   edit: I see the overview stream covers the timeline and internal concepts, but a text version would be great, too! Also, could you improve the audio quality of streams like this one by using an external microphone in the future?

2. What does Fabric mean for developers of native modules?

3. What problems are solved by shared memory ownership between JS and native?

4. How does the "JSI" differ from the React Native bridge?

5. Can you provide more details on the removal of ViewManager modules?

6. Will the reconciler eventually be in C++?

Thanks!

[shergin]

@aleclarson Thank you for your question!

What's the timeline for Fabric's first stable release?

We don't have any public deadline or timeline. It's also hard to define what stable actually means for Facebook and for external users. We have quite ambitious (but realistic) plan to enable Fabric for some of the most popular RN screens in the main app.
To me, the most important mark will be when we enable Fabric for all screens in all Facebook apps. It's unclear when we will hit this point, but I am pretty optimistic about that.

What does Fabric mean for developers of native modules?

Fabric doesn't affect native modules API directly (this is a separate effort), except special kind of NativeModules called ViewManagers. Fabric does not use this approach anymore, any component-specific View Managers have to be rewritten. See also below.

What problems are solved by shared memory ownership between JS and native?

Technically, this problem does not exist in the current architecture, because the shadow tree is not shared between JS and native, each side maintains own copy of the same tree.
In Fabric, we have to be able to support multiple versions of (partially) immutable shadow trees, which can be created by both sides. To make this performant we have to "share ownership" of every node in those trees. So, if some particular node is not needed by both sides, it can be automatically deallocated; there is no need to maintain hash tables and send the information between worlds. JSI makes it possible exposing API that allows to call finalizes when GC collects objects.

How does the "JSI" differ from the React Native bridge?

They are similar but... totally different. They both connect JS machine with the native world.

Bridge is part of React Native.
Bridge includes:

• Serializing/Deserializing pipeline;
• Queueing;
• Native Module API;
• Asynchronous calling API;
• (kinda special) Synchronous calling API;
• Something else; Bridge is huge.

JSI is not a part of React Native, it's a unified lightweight general purpose API for (theoretically) any JavaScript virtual machine. Now there is only one implementation of that - for JavaScriptCore VM.
JSI has/allows:

• Expose some native objects as JS objects and vice-versa;
• Expose API for synchronous calling on this object in both directions.
  Everything else should be built on top of that.

Can you provide more details on the removal of ViewManager modules?

In the current architecture, ViewModules almost always contain only props mapping; in Fabric this information is described as *Prop classes in C++. So, there is no need for ViewManager.

Will the reconciler eventually be in C++?

Probably. Probably not. We are thinking that something like this might be valuable and feasible in a couple of years. But, personally, I think if we are thinking about this now, we can figure out something even smarter than that. :)

[kay-is]

Thanks for the Q&A 😃

Will the JNI work like NativeScript does it?

I read they don't need bridges written in ObjC/Java.

[shergin]

@kay-is

Will the JNI work like NativeScript does it?

Do you mean JSI? I don't know how NativeScript works, so I cannot say.

[kay-is]

Yes, JSI, sorry.

AFAIK NativeScript exposes all native APIs in JS, so you don't need to write native code to interact with them.

[axe-fb]

@kay-is It is similar, but there are differences. Unlike NativeScript, we would not have a binary file that registers ALL methods on the outset. It is more like HostObjects, which can have getters/setters.

[AlicanC]

What side effects can we expect? Decreased build times? Decreased binary sizes?

How much of Java/ObjC code will become C++ in the end?

[aljs]

1. Can you share any benchmark results? I know, it's still a WIP - but it's interesting how Fabric compares to an old realisation in terms of performance.

2. Does this affect native Obj-C modules that aren't running on the main thread?

[shergin]

@AlicanC

What side effects can we expect? Decreased build times? Decreased binary sizes?

Probably, but that's not our goal. The main goal is to make the code more modern, flexible and maintainable.

How much of Java/ObjC code will become C++ in the end?

The goal is to have as small amount of platform-specific code as possible. It's hard to estimate exact amount though.

@aljs

Can you share any benchmark results? I know, it's still a WIP - but it's interesting how Fabric compares to an old realisation in terms of performance.

At this point, we don't have numbers in which we are confident enough to share. I expect to have them relatively soon though.

Does this affect native Obj-C modules that aren't running on the main thread?

(At least on iOS) All native modules which are view managers should be rewritten/adopted to Fabric, eventing else is covered by separated effort called TurboModules.

[msand]

1. How will the removal of ViewManagers affect Animated and useNativeDriver?
2. What differences are there between iOS and Android? (previous message suggests only iOS needs rewriting of view managers)
   Seems the removal might simplify native animation of e.g. react-native-svg. I've had to introduce property setters in the ViewManagers and Views/ViewGroups (just to contain a reference to the shadow node, in order to be able to set the properties) in addition to the shadow nodes, for all Svg elements on Android, to allow animation using the native driver.
   https://github.com/react-native-community/react-native-svg/pull/757/files#diff-4514e2800c86c3d034626a608dce25b2
   Support Interpolation of strings when using native driver in Animated, fix Expected node to be marked as "native", optimize AnimatedNode creation and connections facebook/react-native#18187
   Native animation, ClipPath spec conformance, Pattern element, Mask element, cache invalidation software-mansion/react-native-svg#757
3. Will there be improved support for writing native modules in C++?