React Fiber

[00:00:00]
>> Steve Kinney: We're going to talk a little bit about React Fiber. You're like, I have heard these words. I don't really know what they mean. Well, guess what? You're about to, because we're going to talk about what it means. So React Fiber is effectively the newish, I say ish because it's been around for a while, right? New-ish way that React figures out what the changes to the DOM are. And, you know, the answer to what is React Fiber, it's a cooperatively scheduled rendering engine, which for most of us, you're like, neat, that's cool.

[00:00:41]
And what it basically means is it doesn't really necessarily change the way that React works, it just tries to be a little bit smarter about it, you know, as I mentioned earlier, the way that the earliest baby React used to handle figuring out what changes it made to DOM is that it either as classes or functions, kind of just went, start at the top and just blew through the entire component tree, which is probably fine and great if your app is relatively small, right?

[00:01:18]
But like once that process started, it was blocking the main thread and it was going to complete. Effectively, no matter what happened, right? And there are ways, you know, if you got to the point where it's like, hey, every keystroke is triggering the state change, that is triggering this giant resorting of the DOM that I have to do, because no one ever gives me the APIs I need, then like, you could come up with things that you could do.

[00:01:46]
Could you like, you know, get nuanced with the debouncing and the throttling of the input, use something like RxJS to kind of figure out how to cancel stuff if it doesn't happen in a certain time frame. You absolutely could, right? And in earlier, like in other workshops, we have done stuff like that. The nice part is, like, with these changes under the hood for React Fiber, you know, if there's a time and place for all those tools still, right?

[00:02:12]
I still occasionally have to reach for them myself. But the nice part is, because a lot of under the hood work happened to React and, maybe you don't even know about, like, you can opt in to a lot of these things and have very elegant and easy solutions for less code than you might expect if you didn't know about it. It's one of those things where the added complication in the way that React does stuff actually benefits you versus like also mean your life is more complicated because usually, new and more complicated features just make everything that was once simple hard.

[00:02:47]
So, basically, it is that kind of, it gets us that thing we were talking about before, which is what is the urgent stuff. It's not, you know, React compiler is probably the technology that will like most save us the necessary versus unnecessary. React Fiber is the technology that will help us with urgent versus this can wait a second. Right. And so instead of being a, like, once we're going down this component tree, we're in, right?

[00:03:13]
And the only way to make things faster is again, stop the component tree, you know, higher up or start it lower down, we can actually say like, hey, I might need to interrupt this. Right? I might need to like pause this and come back to it. I might just need to like stop this, throw away whatever was doing completely, and, you know, like things have changed enough. And this effectively will give us the primitives to do all of that stuff, right?

[00:03:40]
And like the TLDR and we'll get a little bit more into the details, but the TLDR is that like, it gives you the ability, instead of like, it will check in every so often to go, should I still be doing what I'm doing, which honestly, like I've had people report to me that I wish would do that a little bit more often. But like, it will stop and check, like, is this work that I'm still doing valuable?

[00:04:03]
Is there more important things I should be doing? Oh, there are. Let me go do those things. And then either A, I will come back to this, or I'll start this over, right? Because doing that more important thing might have been worth it. You'd be like, isn't that doing more than technically slower? And these are where the two rules become interesting, which is wasting a bunch of effort to then respond to something much more important and having to do some stuff over again is technically slower.

[00:04:33]
But in ways that everyone is very OK with cause it feels way faster. So, effectively, like, you know, you should not, and if you look at the code, you'll understand why. It's basically a bunch of plain functions, a linked list tree, and a small scheduler hiding in a trench coat. There's nothing like outside of JavaScript in this. It is very kind of standard stuff. But it's really cool in the way that it works, right?

[00:04:59]
It's not any faster other than like if you had continued optimizing the old way React does. It's not faster in and of itself, right? Like I would like to believe that every version of React gets slightly faster, maybe. But this is not necessarily a speed play. What this is, is introducing this idea of priority, right? Previously it would have been like, cool, change happened, let me finish that. Oh, another change is queued up, let me finish that, right?

[00:05:30]
Like the way that like, JavaScript works is generally speaking, like some languages that have like true concurrency like functions can be stopped midway through, so on and so forth. JavaScript effectively, once a function starts, it runs to completion, which is either a return value, the end of the function which is returning undefined, yielding a value with a generator or throwing an error. But like once you start a function, you're in, right?

[00:05:54]
And so effectively, a lot of what React Fiber does, instead of like, you know, going from one function recursively going down the tree, it's breaking it up into pieces, putting it on an event queue-like thing, right? And then like coming up for air every so often to check to see if it could continue. If you were writing a regular JavaScript, a pattern that you'll see a lot, if you had a big expensive thing, which is use like a setTimeout of zero.

[00:06:20]
Like do 10 of them, setTimeout 0 with the rest, do another 10, that lets other stuff get online in the event loop, so you're not blocking the main thread. That's not necessarily how this works, but the metaphor works, right? And so it's like, I'll do a little. I'll let other stuff get in line behind that. I'll come up for air. I'll do a little bit more. I'll let a bunch of other stuff happen, right?

[00:06:40]
And there's some heuristics that we'll hope that I put in the slides. If not, I'll tell you about them. But the key feature is that it can, if something more important came in, stop what it's doing, let that happen. The other nice part is, even if there's nothing important, a lot of times React is not the only thing running in your application. There might be a CSS animation. There might be other things going on, right?

[00:07:05]
It will also come up for air, like the browser tries to paint 60 frames a second, which is 16.6 milliseconds for those keeping track at home. It will try to come up for air that often as well to let all of the other stuff happening in your application happen, right? You know, promises resolving, so on and so forth. So even if you don't use or know about any of this, your life did get slightly better by its sheer existence because it does like allow other stuff to kind of get in line and check in every so often.