Trying to make sense of deferredUpdates in React Fiber
NOTE: A lot of what I mention in this post may not be a 100% accurate. I’m only playing around with Fiber trying to understand how stuff works and write about my experiences. To follow this post, you’d have to be familiar with the ES6 build of the fiber example. It is pretty straight forward to setup and the code is fairly easy to understand.
Like most of the react community, I’m pretty excited about Fiber. Although, it’s kinda difficult to get my head around all the improvements that this architecture is gonna bring about. I tried reading through the source code but it was too overwhelming for me. So I figured the best way to get started would be to play around with the ‘official’ fiber example. I ended up using Geoffrey Dhuyvetters’ ES6 rebuild of the fiber example.
My initial understanding, as I explore fiber, is that its previous version — stack — did not take advantage of scheduling and that the upcoming fiber version does take advantage of scheduling. For me, maybe naively, this translates to having multiple render queues, i.e., this.setState would push state changes to multiple queues based on the priority of requested update — as opposed to a single queue (which probably is the case in the stack implementation — I am not sure). As to how react decides on the priority and wether an application developer is allowed to control the priority of a state update is something that I need to look into more.
So I cloned Geoffrey Dhuyvetters’ fiber example and got started with playing around. I toggled on the ‘slowDown’ switch in the Triangle.jsx file and here is what I got.
I first modified the code so that the example uses the regular stack renderer and measured the FPS. As can be visible from the below video, a LOT of frames were dropped.
I then switched to the fiber renderer but did not perform state updates inside the ‘deferredUpdates’ method. A huge improvement. The FPS jumped up to an avg. of 45 FPS. However, as you’ll see in the video below, the jank is clearly visible — but less frequent.
Next up, I performed the state updates inside the ‘unstable_deferredUpdates’ method (which presumably will be called deferredUpdates once stable). Heres hows that looked on the screen —
This is clearly the winner. Even when using the fiber renderer, using deferredUpdates to queue state changes resulted in a much higher FPS. This is very interesting to me. I reckon that pushing state updates using deferredUpdates makes sure that the state updates do not get in the way of current animations — thus demonstrating the whole concept of fiber being able to schedule its tasks. As to how it does it, well, I’ve got a ways to go figure that out.
Till then, if you come across any material that’d be useful in understanding the inner workings of fiber, do share them.
