Get some Fiber with… React?

Sometimes codes need fiber too?
This kind of Fiber.

React Fiber, which will soon be known as React 16, is a complete rewrite of React’s current reconciliation algorithm. It aims to improve UI responsiveness and perceived performance for end-users by rethinking how and when the UI should be updated. Think of areas like animation, layout, and gestures. This is important for isomorphic apps built with React. As a recap, isomorphic or universal apps are apps that render entire pages in its initial state on the server and any state changes will be rendered on the client browser.

React vs React Fiber

Reconciliation and Diffing

React uses different renderers to display UI elements — the DOM renderer for browsers and the Native renderer for mobile apps.

Reconciliation is the algorithm behind what we know as the “virtual DOM.”

Diffing” is the logic in the renderers that computes which parts of a UI tree need to be changed.

React uses the following flow of rendering components: 
1. Update the Virtual-DOM
2. Run the diffing algorithm
3. Update the actual DOM

Source: https://medium.com/@gethylgeorge/how-virtual-dom-and-diffing-works-in-react-6fc805f9f84e

Under the Hood

We’ve see how how components can be composed and reused inside other components by simply using the markup for the custom component.

For example, CocktailsList and Cocktail are re-used inside CocktailsContainer by simply writing the custom element tags.

class CocktailsContainer extends Component {
render() {
return(
<div className="drinks">
<h1>Pick a drink!</h1>
<CocktailsList />
<Cocktail />
</div>
)
}
}

Traversing of a DOM is the most time-intensive process of rendering a UI. In a client-side framework like React, the rendering of subtrees is a recursive process. Component lifecycle methods are called to traverse through the DOM tree one-by-one. Each element’s rendering process adds an execution context to the call-stack, bulking it up, which often blocks the browser’s main thread and results in laggy UI performance.

Think of the browser’s main thread as a full-stack developer building a website. It does DOM, JavaScript updates, layout, etc, — and everything takes time. React itself is designed to work with the main thread, think of it as the Technical Lead who knows how the main thread works. React Fiber will essentially have “project management skills” such as the ability to minimize and batch the DOM changes as well as the ability to keep track of time passed, enabling higher efficiency by the main thread.

Currently, the React reconciler works by your components handing off its elements during render to tell React what to build. React will create instances of those components to figure out how to manage them — which components should be updated, what the current state is, what changes need to be made. The DOM nodes is what React eventually uses to tell the browser what it needs to do. With the existing reconciler, this is constructed layer by layer.

React doesn’t currently utilize work scheduling in a significant way. What this means is that an update results in the entire subtree being re-rendered immediately.

The stacks build up and the main thread gets caught underneath all the tasks it needs to perform.

React Fiber will reimplement the reconciler using data structures called fibers to keep track of where it is in the tree. A fiber is simply a plain JavaScript object that keeps track of node relationships, and in React’s context, a virtual stack allowing for management of work.

It will give the main thread some flexibility and mobility with any changes that need to be done.

By keeping track of relationships between child and grandchild nodes, fibers allow smooth data flow and can avoid expensive tree traversals by being able to instead bounce back between the parent node and its branches. Basically instead of building up the call stack, we see a consistent return to the main thread. React can move up and down the tree and tell the main thread to make whatever changes are marked as more urgent than others. React Fiber can schedule deferred changes to be done at a later timeframe.

This is how you can imagine React Fiber working with the main thread every step of the way.

As of now, the workload will be prioritized based on a few parameters, and you can see the offscreen changes right at the bottom of the stack as a low priority change.

The Nutshell of React Fiber’s New Features

  1. Pause work and come back to it later.
  2. Assign priority to different types of work.
  3. Reuse previously completed work.
  4. Abort work if it’s no longer needed.
Much more efficiency.

React Fiber will be backwards-compatible with existing React apps. Despite the fact it is a complete rewrite, public APIs will stay the same. Check out React Fiber’s status here. It is already being used by Facebook on their main page and will soon see a public release.

Resources

  1. https://www.netguru.co/blog/react-fiber-announcement
  2. https://www.monterail.com/blog/2017/react-fiber-release
  3. http://blog.rangle.io/react-fiber-reconciling-the-rumours-with-the-facts/
  4. https://github.com/acdlite/react-fiber-architecture
  5. https://medium.com/@mark.cruz/react-fiber-how-reacts-update-is-going-to-change-ui-b643cd972106
  6. https://facebook.github.io/react/docs/reconciliation.html

All cartoons and corresponding explanations were referenced from Lin Clark’s awesome video on A Cartoon Intro to Fiber. Watch it here!

Like what you read? Give Amanda Lee a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.