How does Fabric improves lists?
ororsatti opened this issue · 3 comments
Introduction
In the past year I got more and more into react native, and one problem that drove me crazy is lists.
On the project I work on I have a list that I can not seem to get it to be as smooth.
I tested all sorts of libs, recycler-views and what not, none gave me good results.
Few month ago I stumbled upon the new arch, with the JSI and Fabric I thought it would be the end of my searchings,
or atleast it will make lists run a little bit better, after all thats the first example you see at every talk about Fabric.
But, when I actually tested it, I didn't see much difference.
Don't get me wrong, I love react native, every thing it represents, and the way it allows us to efficiently work on a app without big team of native engineers. But I still don't understand, where is the improvement? should we expect any improvement?
Details
Example of lists, one is with the old bridge, the other is with fabric.
Screen_Recording_20230715-155107_newarch.mp4
Screen_Recording_20230715-155150_newarch.mp4
As you can see, although there is an improvement, its not big.
Discussion points
- Will lists be improved when the new arch will be released ?
- What should we expect realistically from the new arch?
Hello,
thank you for taking the time to try out the New Architecture and opening this issue. I will try to answer this issue more broadly but I'm afraid it won't be very satisfactory.
We have not focused on making lists better in Fabric. The focus of Fabric was to move React Native towards better architecture that is built around JSI, concurrent rendering, and shared core. We explicitly didn't try to improve lists with this new technology, even though there is potential for it. With the New Architecture, not just Fabric, we do have a lot more control over which thread executes computation and can better schedule work since the New Architecture has its own scheduler that is deeply embedded in the framework. All of this gives us a solid building blocks for future improvements but as I mentioned, we haven't explicitly focused on lists.
We have written a deep dive about the new renderer. Some of the benefits are:
- Improved type safety.
- More code is shared among iOS and Android. This is good for bringing improvements from one platform to the other. Also we have better consistency.
- Better host platform interoperability. This is important one for future of lists.
Hello,
thank you for taking the time to try out the New Architecture and opening this issue. I will try to answer this issue more broadly but I'm afraid it won't be very satisfactory.
We have not focused on making lists better in Fabric. The focus of Fabric was to move React Native towards better architecture that is built around JSI, concurrent rendering, and shared core. We explicitly didn't try to improve lists with this new technology, even though there is potential for it. With the New Architecture, not just Fabric, we do have a lot more control over which thread executes computation and can better schedule work since the New Architecture has its own scheduler that is deeply embedded in the framework. All of this gives us a solid building blocks for future improvements but as I mentioned, we haven't explicitly focused on lists.
We have written a deep dive about the new renderer. Some of the benefits are:
- Improved type safety.
- More code is shared among iOS and Android. This is good for bringing improvements from one platform to the other. Also we have better consistency.
- Better host platform interoperability. This is important one for future of lists.
Hello,
thank you for your reply.
Couple follow up questions if thats ok:
Better host platform interoperability. This is important one for future of lists.what do you mean here, and why its important feature for lists?bringing improvements from one platform to the other.in relation to lists, does it means you can bring android to ios level?
What do I mean by better host platform interoperability
We haven't done the ground work for this but I can imagine a list implementation without the empty patches. The empty patches are caused in RN by one thread managing the scrolling (UI thread) and another thread populating the content (JS thread). If UI thread is too fast in scrolling, what you see in your videos, JS thread is not able to catch up with content and you start seeing the empty patches. When I say "better host platform interoperability", I mean we could block the UI thread until we get content from JS thread. This is something that was not feasible before. The more flexible threading model gives us more options but I'm not sure how we will leverage them yet. This is an area of future investment.
Bringing improvements from one platform to the other
This is a broad area. One example is how The New Architecture brings view flattening from Android to iOS: reactwg/react-native-new-architecture#110
Previously, this was Android only optimisation and we never built it for iOS. Thanks to the shared core, it is on both paltforms now. The important thing here is that as we work on improving RN, it is easier and more natural to bring new features (be it perf only features) to all supported platforms.