As we all know by now, a big change is coming inside of React.
with version 16. It's a significant one, because it will affect the performance of more complex React applications.
(EDIT: As Dan Abramov pointed out in his comment, even though 16 will be running on Fiber, it will run in synchronous mode, mimicking the "traditional" approach to rendering. This will not confer any changes in application behavior or performance. The async Fiber APIs will be exposed in some ways but will not be the default mode of operation. Read on nevertheless!)
The crux of the change is transitioning from processing updates in a synchronous, recursive way to relying on asynchronous scheduling and prioritization of interface changes. The desired result is 60 FPS and a pristine user experience. It's been a while since the announcement already, and many good things have been said and written. However, I like to see things for myself and understand how they work from the ground up. There were also a few topics that lacked "press coverage".
Thus, down the rabbit hole I went!
Fiber is not the most straightforward piece of software, both conceptually and code-wise, so it should be approached in a structured way. This post will go outside-in - starting from calling the
render function in client JS and changing state of a component, down to describing the steps taken by Fiber to do all the work. At a few points along the way you will be given a choice to go further down or return to the tip and track your way back to the same point from a different origin.
If you feel like it, you can grab the Fiber codebase from Github and track your way through the post in the code, starting here.
React source code is sprinkled with a lot of error handling, dev logging and performance measurement calls. I'm going to skip those and focus on the main logic for the sake of clarity.
Another point to note is that currently Fiber code is coupled to the DOM renderer in a few places, because things are still developing, as I understand it. I'll try to avoid referring to it, but you can assume that "the renderer" means "the DOM renderer" in this post.