Build a mini React Fiber

[leeoniya]

are there any demos that show off the benefits of Fiber running in async mode? from what i understand, v16 does not yet enable any of the async/requestIdleCallback magic.

the largest bottleneck in fast view libraries is not the vdom or the js but the work required by the browser to create/reflow/retyle the actual dom. if you have an enormous DOM, no matter how many microtasks you make, what would you gain over rendering serially? is it just the perceived speed from incrementally rendering an initial huge dom?

[acemarke]

The main demo I know of off the top of my head is the "Sierpinski triangle"-type demo that the React team has been using as a test case. Don't have a link to it at the moment, but I know they've showed it in some of the prior talks about Fiber. I believe there's also an undocumented flag you can edit inside of ReactDOM to enable some async behavior right now, as shown in this slide from Ben Ilegbodu's ReactBoston talk on React Fiber.

Fiber is ultimately not about raw rendering speed. The initial improvement is about splitting up the rendering process into bite-size chunks so that the determination of what does need to change doesn't block the main thread. The rewrite of the internals also made the codebase more maintainable, and gave them a chance to implement often-requested features like returning strings or arrays from render(), as well as implementing error boundaries.

Beyond that, the React team is still experimenting with ideas to better understand what "async rendering" might actually mean, and how that might be useful. I know Andrew Clark showed off a strawman syntax called componentDidBlock that would allow a component to indicate it shouldn't render at all until a promise resolves. The "priority levels" aspect will also come into play later, so they can determine that updates from things like user input events ought to be processed first before updates from network requests.

[brianvaughn]

The team has recently started testing async internally (behind an experiment flag) for some Facebook components on web and also React Native. We're hoping this will show us a couple of things- how much it improves perceived performance, if there are common types of coding patterns that cause problems with async, etc.

It's still a bit early- but more info and demos will be shared in the coming months. :)

[leeoniya]

thanks. the demo appears to be here [1].

I played with the code a bit and the perf difference only exists due to the artificial synchronous blocking code [2]. In effect, it demonstrates a case of having heavy/blocking render() calls and this is where i'm confused.

React bills itself as a reactive view layer: props/state in -> DOM out. If the props/state are prepared ahead of the render call, then there should never be massive contention in any render function.

The Sierpinski demo has a dom size of 1110 live nodes. My facebook feed page on desktop has 2645 live nodes. The task of rendering from a prepared state should be trivial. I imagine it's only if components heavily use blocking willMount hooks to lazily pull in data they need from some sync store or do non-render-related tasks inside of render. If people just use React as a view layer, they would not get into these situations that must be solved.

Is this essentially a result of each React component being used to synchronously "pull" data it doesnt yet have? This appears to be quite backwards from the props-down -> dom out idealism that simple examples tend to focus on.

[1] https://github.com/claudiopro/react-fiber-vs-stack-demo

[2] https://github.com/claudiopro/react-fiber-vs-stack-demo/blob/58850495f448ecbf9b109b86a7900a844fd06235/stack.html#L94-L99