New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

React Native Fabric (UI-Layer Re-architecture) #4

Open
kelset opened this Issue Jul 31, 2018 · 39 comments

Comments

Projects
None yet
@kelset
Collaborator

kelset commented Jul 31, 2018

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

  • Fabric: just the UI layer re-architecture, to take full advantage of concurrent React architecture.
  • JSI: JavaScript Interface that Fabric utilizes
  • TurboModule: re-architecture of NativeModules, also using JSI. Please visit to #40 instead

Available Materials

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

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

@axe-fb

This comment has been minimized.

Collaborator

axe-fb commented Aug 2, 2018

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

This comment has been minimized.

shergin commented Aug 16, 2018

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 comment has been minimized.

aleclarson commented Aug 22, 2018

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?

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

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

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

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

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

Thanks!

@shergin

This comment has been minimized.

shergin commented Aug 25, 2018

@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

This comment has been minimized.

kay-is commented Aug 27, 2018

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

This comment has been minimized.

shergin commented Aug 27, 2018

@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

This comment has been minimized.

kay-is commented Aug 27, 2018

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

This comment has been minimized.

Collaborator

axe-fb commented Aug 27, 2018

@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

This comment has been minimized.

AlicanC commented Aug 27, 2018

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

This comment has been minimized.

aljs commented Aug 28, 2018

  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

This comment has been minimized.

shergin commented Aug 28, 2018

@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

This comment has been minimized.

msand commented Sep 1, 2018

  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
    facebook/react-native#18187
    react-native-community/react-native-svg#757
  3. Will there be improved support for writing native modules in C++?
@axe-fb

This comment has been minimized.

Collaborator

axe-fb commented Sep 1, 2018

@msand For native modules (3) - note that you can already write native modules in C++.
We are also working on a parallel proposal for a new architecture for native modules - #11

@msand

This comment has been minimized.

msand commented Sep 1, 2018

@axe-fb Do you have any good examples? I've seen expo-gl and just now found
https://github.com/sulewicz/djinni-react-native
https://github.com/sulewicz/djinni-react-native/tree/master/example-react-native/ExampleProject
which seems to simplify things.

@msand

This comment has been minimized.

msand commented Sep 1, 2018

I'm thinking for react-native-svg the text layout algorithm from the SVG 2.0 spec might make sense to attempt implementing in c++ instead of both obj-c and java. Would be easier to maintain a single implementation.

@shergin

This comment has been minimized.

shergin commented Sep 5, 2018

@msand

How will the removal of ViewManagers affect Animated and useNativeDriver?

Native Animation Driver has to be rewritten, we plan to invest in it this year. Classic Animated implementation will work out of the box because it relies on setNativeProps which will fully support by Fabric soon. This is true for iOS and Android implementations.

I'm thinking for react-native-svg the text layout algorithm from the SVG 2.0 spec might make sense to attempt implementing in c++ instead of both obj-c and java. Would be easier to maintain a single implementation.

Yes, totally. I think the all non-drawing code should be unified and rewritten in C++. We plan to do this for ART soon.

@sibelius

This comment has been minimized.

Member

sibelius commented Sep 5, 2018

I've made an overview talk of how React Native bridge architecture works

I've made a talk that presents the current React Native Bridge architecture, explaining its characteristics, how it works and its drawbacks.
I've also talked about how the new future bridge architecture will look like

https://speakerdeck.com/sibelius/react-native-bridges-architectures

I think this could be a good intro for the bridge topic

@aljs

This comment has been minimized.

aljs commented Sep 7, 2018

Are some parts of it already in use without a flag? (on master branch)
Get a crash related to custom view manager on [self.subviews objectAtIndex:]. Only on iOS 9-10, which is weird.

@InventingWithMonster

This comment has been minimized.

InventingWithMonster commented Sep 16, 2018

@shergin I’m currently trying to implement the FLIP animation technique in React Native.

If you haven’t seen this in browsers, the short version: When the layout of a component changes, we can invert its positional delta via a transform, and then animate it into its new position by animating x and y back to 0

To do this seamlessly, without seeing the component in its new position for a frame, we need to guarantee onLayout is fired before the new position is drawn to the screen.

The docs say “the new layout may not yet be reflected on the screen at the time the event is received”, and indeed now and then there is a perceivable “snap”. Will Fabric allow us to guarantee execution of onLayout before the layout is reflected on the screen or am I barking up the wrong tree?

Thanks in advance for your input

@fkgozali

This comment has been minimized.

fkgozali commented Sep 16, 2018

Will Fabric allow us to guarantee execution of onLayout before the layout is reflected on the screen or am I barking up the wrong tree?

A few things:

  • onLayout() is an async event from native to JS, so unless native guarantees that the event is dispatched synchronously after native layout, there’s no guarantee that the content is final.
  • One of use cases that Fabric can enable is “synchronous initial rendering”, where UI layout happens synchronously until content is ready to be displayed - we’ll tackle this a bit later after the core of Fabric and its parity with existing impl are stable.
  • Now, it is in theory possible to update the behavior of onLayout() to be more synchronous in nature, or to avoid the need of initial onLayout() if native can provide layout info synchronously on mount. We are thinking about this, but it won’t be immediately changed via Fabric project. It’s more of improvements we can do on top of Fabric.

Hope that helps.

@contactyash

This comment has been minimized.

contactyash commented Oct 8, 2018

will this re architecture of react native yield performance as good as flutter or flutter's performance is just hyped about?I have learned react recently and I love it ,will it prove to be a good decision to learn react-native for native mobile apps or in core of your heart you feel flutter is better?

@shergin

This comment has been minimized.

shergin commented Oct 8, 2018

@contactyash

  1. Fabric is designed to be (incredibly) responsive and interopable.
  2. Real performance Flutter vs. Fabric is incomparable unless we have big production apps written in both of them.
  3. All apps that I have seen in Flutter don't demonstrate impressive performance unfortunately (totally bias opinion).
@joonhocho

This comment has been minimized.

joonhocho commented Oct 8, 2018

The two main reasons that I stopped using on React Native were Navigation and ListView.
For navigation, I think I've tried 5 different libraries including React Navigation and all felt sluggish. I think wix/react-native-navigation v2 can finally address the problem. I have my hopes up.
For ListView, I've tried every library and every optimization solution out there and it all failed miserably for large lists with pictures and few dynamic components. In the end, I had to bridge native tableview and native cells in order to make it useable.
App startup kept getting slower as app grew large as well. I really hope this re-architecture finally fixes these issues.
ListView and Navigation are the most commonly used components in any apps, and they are still the main problems after 5 years for React Native.
With sync communication between native and js, will it be possible to use native native tableview with cells being rendered in js?

@shergin

This comment has been minimized.

shergin commented Oct 9, 2018

@joonhocho Yes, Fabric is a foundation that meant to help improve things including navigation (sync external interop) and lists (better/sync measuring API, build-in view recycling and flattening). Fabric itself will not solve that, but it will enable actual solutions.

@joonhocho

This comment has been minimized.

joonhocho commented Oct 9, 2018

@shergin I am wondering, in new react native architecture, whether even the rendering can be synchronized. I believe IOS UITableView requires synchronized rendering of cells. That means React should render and return native cell view to the tableview in synchronized way. Will this kind of behavior supported by the new architecture or rendering will be always asynchronous?

@shergin

This comment has been minimized.

shergin commented Oct 9, 2018

Yes, Fabric will support synchronous rendering (state change). However, relying on UITableView it's not the only way to implement smooth and fluid lists, the actual approach and API might be different.

@tayfunyugruk

This comment has been minimized.

tayfunyugruk commented Oct 10, 2018

@shergin when Fabric reaches beta level will we be able to use both JSI and Bridge at the same time ? I am trying to learn if we will need to wait until every component is ported to new architecture or they will be able to live together until Fabric takes over ? Thanks.

Also i think/hope Fabric will help resolving many core problems, thanks for starting this re-architecture team. My best wishes for React Native.

@gengjiawen

This comment has been minimized.

gengjiawen commented Oct 14, 2018

I have some questions:

  • Will fabric comes with big list optimization by default. If not, is this on some schedule.
  • Will fabric bring new api like SyncStorage
@fkgozali

This comment has been minimized.

fkgozali commented Oct 14, 2018

when Fabric reaches beta level will we be able to use both JSI and Bridge at the same time ? I am trying to learn if we will need to wait until every component is ported to new architecture or they will be able to live together until Fabric takes over ?

See @shergin's comment regarding timeline: #4 (comment)

At the moment, the system allows both Fabric compatible components and the existing view manager-based components. At some point in the future though, all components need to be Fabric-compatible. We'll share more details around the plan in later time until the core of Fabric is more complete and stable.

Will fabric comes with big list optimization by default. If not, is this on some schedule.

@shergin touched this in his previous comments:

Will fabric bring new api like SyncStorage

Fabric is just about the UI layer of ReactNative. SyncStorage seems like something that could benefit from synchronous calls to native (whether or not JSI will be used). If you want to call native synchronously, it is already possible today: #11 (comment). We're working on an effort to improve calls to native from JS as a whole though, separate from Fabric: #40

@kelset

This comment has been minimized.

Collaborator

kelset commented Oct 29, 2018

(updated the first comment with a link to Ram's talk at ReactConf)

@rstims

This comment has been minimized.

rstims commented Oct 29, 2018

Is the JSI project going to be open-sourced? If so, where can we view it?

@fkgozali

This comment has been minimized.

fkgozali commented Oct 29, 2018

JSI already landed on master. See the series of commits ending with facebook/react-native@8427f64

@Raat-Jaaga-Taara

This comment has been minimized.

Raat-Jaaga-Taara commented Nov 2, 2018

The biggest concerns I have seen in RN today are:

  • large list
  • Navigation
  • Android overflow in hybrid apps
  • lazy bundle loading to improve boot time
  • Debugging code in app runtime

I see other speakers including @axe-fb Ram talking about the Fabric to help enable navigation and large lists. How will the other three work in Fabric?

@fkgozali fkgozali changed the title from React Native Fabric to React Native Fabric (UI-Layer Rearchitecture) Nov 2, 2018

@fkgozali fkgozali changed the title from React Native Fabric (UI-Layer Rearchitecture) to React Native Fabric (UI-Layer Re-architecture) Nov 2, 2018

@kelset

This comment has been minimized.

Collaborator

kelset commented Nov 2, 2018

(updated first comment with Shergin's tweet about View Flattening)

@fkgozali

This comment has been minimized.

fkgozali commented Nov 2, 2018

large list & Navigation

Please see @shergin's comment here #4 (comment) - Fabric enables solutions for these problems, but the Fabric project doesn't include the solutions.

Android overflow in hybrid apps, lazy bundle loading to improve boot time, Debugging code in app runtime

These are not related to Fabric project.

@Raat-Jaaga-Taara

This comment has been minimized.

Raat-Jaaga-Taara commented Nov 3, 2018

Android overflow: see facebook/react-native@b81c8b5
I had seen this commit but will this enable me to render something outside the bounds of the reactroot view?

@terrysahaidak

This comment has been minimized.

terrysahaidak commented Nov 4, 2018

I'm really excited about Fabric. Thanks for the core team making that happened.

But still, does the Fabric fixes the most annoying part of React Native – layout animation, i.e. width/height animations which cannot be started using useNativeDriver option. I didn't find any information about that.

@mobilehackersio

This comment has been minimized.

mobilehackersio commented Nov 8, 2018

can't wait for Fabric 🚀

@shergin

This comment has been minimized.

shergin commented Nov 12, 2018

@terrysahaidak The role and concrete implementation of the native driver in Fabric is still not clear. We hope that Fabric’s sync nature can enable new approaches to solve those problems more efficiently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment