React Fiber - React Reinvented
Facebook has announced the release of long awaited react-fiber, which is basically a redefinition of React’s core. As a React aficionado from London, I am really excited to share some of the features of Fiber, as I eagerly wait for the React v16.0 release, with which it is about to be shipped.
Being the React London Conference has finished, I believe that the web and mobile development in London has found the silver bullet that everyone has been searching for. We all knew, it was just a matter of time for React to set its feet on VR, now that React VR too being released, we have to wait and see the next one, the bullet is to penetrate after web, mobile and hardware.
Let me slide into the Fiber, when react was released for the first time as a UI building library, the buzzword around it was ‘Virtual DOM’, and it made user interaction faster than any other libraries that time. Updating the real DOM on every interaction is very expensive, and this is what gave shape to the concept of Virtual DOM, it means keeping a backup copy of the original DOM and whenever a change occurs instead of updating the whole DOM, identify which segment of the DOM tree has changed using the virtual DOM and that change alone can be made into the DOM. Even though React was originally started as a library aiming the web, it works well with the native apps and VR.
To understand what makes React capable of rendering on multiple environment, one must understand the difference between two phases within React – reconciliation and rendering. Reconciler is responsible for identifying which part of the tree has changed, this information is used by the renderer to update the DOM. React has different implementations for renderer to target web and mobile(React-Native), whereas reconciler remains the same.
Fiber is primarily the re-implementation of reconciler; it is designed to do scheduling more elegantly. As Andrew clarke has pointed in this link, it is specifically meant to,
- pause work and come back to it later.
- assign priority to different types of work.
- reuse previously completed work.
- abort work if it’s no longer needed.
Will take a usual event scenario, and compare how the stack and fiber reconciler differs in their approaches. So during the initial render both the implementations will create a copy of latest DOM tree in the memory, apart from that during any ‘setState’ action both will create another tree, which can be termed as work in progress tree and push the first root node to it, from there starts the action of traversing and identifying the changes. Stack as well as fiber will traverse through the nodes, based on some relationships say like child, return and siblings and on finding a change, that node will be tagged in the work in progress tree. Till there both follows same method, whereas after identifying the change, stack reconciler modifies the DOM without going further and checking for other changes down the tree. This is most of the time found to be inefficient as some updates are less important compared to others to be reflected on the user interface, they can be put on hold in case of any other more important work. This being one of many reasons, the react team was compelled to rewrite the library right from the scratch.
So this is how the fiber reconciler works on an updation, after identifying and tagging the first change in the current working tree, the main thread moves up in the work loop and check the time left for it to make DOM updation. If it has enough time left on the clock, the main thread will traverse through the tree again from where it has left and check for other changes, on finding any other it will tag that one and follow the same procedure until there is no more time left. This phase is termed as reconciliation/render phase, on reaching the time limit the main thread enters the next phase which is the commit phase, during this uninterruptable phase all the identified changes are updated on the real DOM.
Another change that fiber brings into the reconciliation phase is scheduling and prioritising, in case of any low priority update during the first phase react will hold the new update till it finishes the current work, and in case of a higher priority update, the current work will be discarded and new one will be initiated.
Witnessing the recent development within react, with a mix of scepticism and exuberance I would like to breeze the news to web & mobile developer London, and all those who are lingering to get their hands on VR, voila, react is a promising ground to dig.