How does the React fiber reconciler work?
In this article, I am going to deep dive into the React world and what is the core value proposition of React, what is React reconciler, how it worked before version 16, and how it works today!
1- What the heck is reconciliation?
First of all let’s see what reconciliation means, according to the translation it means :
“The action of making one view or belief compatible with another”
It represents the main purpose of React itself in single-page applications. Remember previously before SPAs we had trouble because of slow routing and the way browsers handled page transitions, to improve the speed of page transition in the browsers, React has introduced a new way of handling routing in web applications and it was the Virtual DOM.
Instead of using the native browser routing and navigation, we keep all of that in the JavaScript memory and use JavaScript to handle pages and routing for us, and as a result, it will become a lot faster.
To achieve that goal, the React team introduced the Virtual DOM and the stack reconciler to handle the virtual DOM tree in the memory and then apply the changes to the real DOM in a declarative way.
2- Stack Reconciler and the History lesson!
Alright, let’s go back to the previous years before we had React Hooks introduced and see how React was building DOM trees at that time.
Below is a picture of a simplified workflow of React 15 and previous versions of React, in those versions, we had a reconciler called stack reconciler which was a LIFO data structure responsible for picking a work and returning the results just like how the JavaScript call stack works.
This approach was a breakthrough already but it had a lot of problems with itself. The main problem was that the stack reconciler was synchronous and sequential meaning there was no chance for it to handle multiple units of work at the same time in parallel or concurrently.
For example, assume the below interaction with the UI by a user:
The problem of non-responsive UI in stack reconciler
As you can see, with the synchronous and sequential order of the stack reconciler, if a user wants to type something in a text input, the response to the user will be laggy and non-responsive because it is a high priority in the rendering order but there is no way we can tell the stack to handle this with higher priority. Another problem is that if any error happens in the middle of this process there is no way for us to find out where it happened and what is the stack trace which can be painful.
Now assume a large application with too many states and works to handle, it could become chaos and the user experience could be destroyed.
3- Fiber Reconciler, that’s what we were looking for!
In React version 16 and above, the React team has introduced a new way of handling the units of work and virtual DOM tree using the new meta called Fiber Reconciler to tackle two main challenges:
1- Synchronous way of processing the units of work
2- Prioritizing and concurrency of the units of work
The current React Fiber Reconciler consists of many fiber nodes which are plain JavaScript objects with a lot of properties to handle their work.
Fiber = { a JavaScript object with many properties OR unit of work }.
Fiber Reconciler = The current React reconciler based on Fiber objects or units of work.
What is a unit of work?
A unit of work in React can be a change in props or state or DOM updates, anything that can change the output for the screen.
The fiber has a relation of 1 to 1 with something whether a component instance, DOM node, etc. The type of something is stored in a tag in the fiber object. The possibilities of the types are:
In the source code of the React-DOM library, you can find functions that are named like:
createFiberFromtText();
createFiberFromElement();
createFiberFromPortal();
It shows that Fibers can be created from almost a lot of options in the DOM and the React ecosystem. Now let’s find out how the new React Fiber Reconciler works!
React is a declarative way of handling DOM manipulation, it means that we tell it what we want to be shown on the screen and it will do the heavy-duty work for us under the hood so that we can focus on the business logic and more importantly stuff that we need for our business.
The below is a simple example of a page:
Now let’s see how it is handled by the React fiber reconcile:
As you can see in the above picture, React Fiber Reconciler constructs a tree of DOM elements in the memory (Virtual DOM) and holds a blueprint of the real DOM as well to work on the real DOM and render the updates on the Virtual DOM and then apply those changes to the real DOM.
This process has two steps:
1- Render phase ( Asynchronous )
2- Commit phase (Syncronous )
When an update happens in your application, the Fiber reconciler starts the work with a function called beginWork which takes three parameters, the current tree which is on the real DOM, the work in progress tree, and the rendering lanes.
The process is a lot more complex but the overview of what is happening under the hood in the React reconciler is as the blow in a simple click on a button and change in the state example:
1- When the user clicks on the button the process will start by calling beginWork(currentTree, workInProgressTree, lanes) which will recursively start checking the tree from top to bottom going down on siblings and children nodes.
2- While there is work to be done meaning changes happened in the props or the states, it marks the nodes using an updated flag that the node needs to be updated.
3- When it is finished working on a fiber unit of work it marks the updates and finishes the work by calling the completeWork(currentTree, workInProgressTree, lanes) function which is responsible for going up in the working tree.
4- Complete work also constructs HTML elements tree to be shown in the real DOM based on updates off-screen in the memory.
5- When everything is done the fiber has finished work and there is no more work to be done, it will commit all the newly constructed DOM trees to the real DOM and reflect the changes to be shown on the screen.
The rendering phase and working on the DOM tree in the memory is completely off-screen and asynchronous so if any update or interrupt comes up in the middle of a process, the process can wait or even a bail-out can happen to drop the process and start working on another process again, it can be prioritized, it can be delayed, it can be canceled, it can be parallelized to do multiple works concurrently at the same time. This is exactly the solution we were looking for to solve the problems of the stack reconciler previously.
By using the Fiber reconciler we can now have concurrent rendering, suspense features, and error boundaries to catch rendering phase errors and show a fallback to the user without letting the whole app crash at once!
How do effects work and apply in this process?
A very good question, the result of a fiber tree is not dependent only on itself, we also have a list of effects that may happen for example a network request, a mutation in the real DOM, calling lifecycle methods, or anything happening outside of the React ecosystem that needs to be synced with React state.
In the commit phase, React will go through all the effects and apply them to component instances, the results are visible to the user and React does all that in a single pass.
We are all over it now! wasn’t that cool? knowing what is happening under the hood when you are using React empowers you to know the React ecosystem and how it handles the process and DOM behind the scenes.
I hope you have enjoyed it, if so please follow me for more articles in the future, peace, and happy coding.
Resources:
https://www.youtube.com/watch?v=0ympFIwQFJw
