Time Slicing
The fiber architecture comes out with React 16, which is a rewrite of the previous reconciliation algorithm generally known as “Stack Reconciliation”. If you are familiar with the stack reconciliation algorithm, you may know that essentially it depends on recursion to update the child components and re-render at each call if necessary.
That being said, once a setState triggers the update, the recursion starts and it cannot be stopped in the middle of the process (Side effects like manipulation of DOM are happening along). Which means, anything that comes after the start of the update, should be waiting until it ends. The result is that user experience suffers, because everything is waiting for the update to finish. And if the CPU is inefficient, things like DOM events, animations would be laggy.
What is fiber?
Here I want to borrow Dan’s metaphor at his talk “Beyond React 16”, as we can think of the previous React as a Git without the branch feature, where you cannot interpolate tasks. But in fiber, a generic feature was built that enables the render process to be asynchronous and atomic, and it doesn’t get blocked by update. So that high priority tasks like animation, user input can come before the low ones like data fetching from backend.
Above is the illustrative comparison between how stack is different from the fiber algorithm. As I mentioned above, when we do recursion in the stack reconciliation, we are also doing side effects like DOM manipulation, which prevents us from stopping in the middle. But in fiber there are two phases: flush and commit. And we are only “committing” (side effects) the changes to the DOM in the commit phase, which means, you can stop at any point in the flush phase because we haven’t done anything yet and it’s safe to pause, come back later, do some other things or simply commit an abortion. Thus, it gives React the ability to commit the changes asynchronously and handle higher priority tasks first.
Suspense
What’s the good thing about fiber is that it not only allows render to be async, and interrupt-able, but can do some fun things when we want to do something in the middle of the render phase, like Suspense.
Think about how you would normally do if you want to show a spinner before the data is loaded from the backend. You are possibly gonna initiate a state called isLoading to true, and fetch the data in the componentDidMount lifecycle and when it’s loaded, you setState to set isLoading to false. And the render method uses that state to decide to show whether the spinner or the real content.
But it can be tedious and hard to maintain if you have lots of different un-fetched data in one giant component, where you have to assign a new loading state to each of the data blocks. You’ll probably end up like this:
state = {
isALoading: false,
isBLoading: false,
isCLoading: false,
idDLoading: false,
};But with Suspense, to put it simple, you can pause at any time, or render a placeholder before the data is fetched, without hoisting the logic in the component local state and lifecycle methods.
Good Materials to Follow
Me myself is also a starter on the Fiber architecture. Below I will provide some useful materials to make the learning process approachable, and in a beginner friendly order.
First, Tom gives a high level overview of why we need a new way to do the React reconciliation and why priority matters in the render and update phase. This talk is helpful for you to understand why they are moving to the new fiber architecture.
Second, you can watch Dan’s talk on JSConf 2018. He introduces the two main features that the fiber brings to us, which are time-slicing and suspense.
Third, a cartoon intro to fiber by Lin Clark. Yayyy!!
Finally, it’s time to move on a little bit further to see how the fiber architecture would be. Note that you might also want to read through the link provided in this repo first. Take your time!
To get your hands dirty, try build a suspense demo like this:
Some Tips Before the Real Codebase
There ain’t any.
LOL sorry I was joking. The only tip I’ve found by far is that it’s always good to start reading some unit test cases like those in ReactSuspense.internal.test to build a mental model of how it SHOULD behave and work before reading the implementation.
And don’t forget to follow up on the blogs in reactjs.org and twitter. They can be really helpful.
