Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New Reconciler Infra #6690
This is an outline for the new reconciler infrastructure.
I created a noop renderer to have something to get started from.
I split the reconciler folder into old and new, as well as shared. I put shouldUpdateReactComponent in shared as an example of a utility that can easily be shared between both. I plan on breaking out more utilities like these.
Builds on top of #6682
#6170 doesn't really explain these architecture changes. e.g. high vs. low priority renders, incremental and the how and why. Anywhere I can see the discussions on this or have they thus far been informal and undecided and this PR is just to flesh them out?
Yes, I think this is just @sebmarkbage trying to create a useful proof of concept in a way that makes sense to him. The goals are simple: change React from deep recursive rendering on every change to some kind of scheduling.
The way I understand this PR is the following. For scheduling to work, we need some kind of priority system, or otherwise there is no way for React to know which updates should be processed first. “Low” and “high” is the simplest possible way to describe priorities. We don’t know if more kinds of priorities would be helpful, so starting with two makes sense to me. How they are used is an open question, but it’s easy to imagine some options. For example, we might want to schedule high priority updates for something is interacting with (e.g. pressing a Like button) because UI should be responsive to feedback. On the other hand, rendering loading data might be a lower priority (i.e. it’s better to render a new story in the feed with a small delay than cause an animation happening at the same time to drop frames).
If there is any specific algorithm in mind, it’s in @sebmarkbage’s head, but I think he’s just fleshing out a system capable of rendering existing React components with priorities. There’s really not much to it aside from what I wrote above. The existing reconciler code is deeply OO and relies on recursive dynamic dispatches (e.g.
Also, for the record, I don’t understand what
This sounds a lot like what React components want to do. Today, we can say
Another example is context: we want context updates to be fast, as it is useful for layout and animations, but the current system involves walking the whole tree to update the context which causes issues like #2517. If context was also an effect, and we built support for effects handled by parent components (or React itself) in React, this would probably get solved as well.
I might be totally wrong though!
You might also find this helpful: https://github.com/reactjs/react-basic. Especially https://github.com/reactjs/react-basic#algebraic-effects. This is pretty much a braindump of what @sebmarkbage has been thinking about for the past few months. I think the new reconciler will move closer to this conceptual model of React than the existing one, although of course implementation details will still differ from the conceptual model because we live in a real world.
Fibers as a concept is essentially https://en.m.wikipedia.org/wiki/Fiber_(computer_science) reimplemented in user space.
But yea, I don't really know what I'm doing yet. I have a rough idea.
May 11, 2016
1 check passed
referenced this pull request
May 16, 2016
This (and to a lesser extent the followups) are going to make it tricky to continue cherry-picking into the 15 release due to file moves. Is there any risk in cherry-picking this (and the other fiber changes) as well? It doesn't look like anything in current code has really changed. They aren't part of public modules so seems like it should be pretty safe. We could even exclude the whole