Now the typical way that's solved is using a technique called debouncing. And debouncing basically means that if an event occurs multiple times within a certain time period, say a second or half a second, then we're not gonna fire it. We're gonna wait until at least that time period has passed before we actually fire the event. So that's completely solved the problem with the application locking up with large data, because I can just keep on typing and our circle just keeps on going around the little clock and the green area keeps small. But if you look at the chart behind it, nothing happens. They're never updated. And so only when I stop typing, do they get updated. And if there's a lot of characters there, so a lot of notes, that kind of makes sense. But if there are just a few, you see I type a character now and it takes like half a second before the charts are updated. And if I keep on typing slowly, well there's plenty of time to update the components, but I'm sticking typing within the debounce period. So nothing is actually updated. So we get a responsive application, but a slow updating one. Even if it's not needed. Now what's called asynchronous here, they called it time-slicing asynchronous mode back then is called concurrent mode these days. And as I mentioned, the actual underlying codes probably very different now, but the principle of how it works remains the same. If I start typing and I type slowly, but within that half seconds, I just now see that everything updates and keeps on updating. And there's not really a slow down and everything kind of works. But if I keep on typing getting into the area where there are so many DOM nodes that it can't really keep up. And now it's not updating with every key stroke, it's updating whenever it's possible, but if it can't update within some key events, some key down events, then it's just gonna skip that update. So my application responds as fast as possible while still keeping it interactive, which is exactly what happens here. It does stuff and then if there's an event, it comes in and lets that event kick in, and then it keeps on going. If it can't finish what it does, it will discard some work and then queue it up again so it can do it later, and hopefully do as much as possible, keep it as practical as possible. Now in a browser, there are a couple of ways you could do this. But it turns out there is a real natural way for a browser, because a browser tends to refresh itself, at least most browsers do, at 60 frames per second. So, 60 times a second, the browser tries to draw a frame on, in the DOM. Now, that boils down to roughly 60 milliseconds between each frame. So if we can split these blocks up in such a way that they're inside of 60 milliseconds, then it's kind of like, if the user does something, it can happen almost immediately, and we've got really nice boundary. And there are some really nice APIs in the browser, like request animation frame, and inside an animation frame, you can request how much time you've got left inside of that animation frame. So that's the kind of code you can use to say, well, I start rendering here. How many components can I do? Well, if I'm here, I've still got eight milliseconds left. Okay, we can do some more. Here I've got four milliseconds left. We can do some more. And then where did my mouse go? Here, we've got one millisecond left. Now we don't have enough time left to render another component, so let's pause and start the next frame. So we get our pauses and we get all the interactive behavior. So as I mentioned, we're in Beta Land here. Be careful to not use this in production. Now the first thing you need to be aware of is this little chart. And this is always a bit painful. It starts here with legacy mode, and then there is blocking mode and concurrent mode. So what they call legacy mode is actually the current released version of React, but calling it legacy modes makes it sound dirty, like you're still using legacy mode? Well, no, that's the released stuff. That's nothing old with nothing wrong with it. What can you do in there? Well, you can use string refs, you can use the old version of contexts. This only applies to the old style context, not the new. That will still work. You can use find DOM node, another API, which is not very much used. So the first three are not very commonly used. And you can use suspense, which we already used. Now to be honest, we were using the experimental preview version of React, but that would have worked perfectly fine with normal React. All the other stuff behind this, so suspense lists, deferred values, interruptible pre-rendering, which I described, none of that works with legacy mode. Rendering is just one big chunk executing, no interruption, no priorities there, none of it. And no suspense list. There is an intermediate mode, what they call blocking mode. It's not fully concurrent, but it gives us some of the APIs like suspense list. Not a 100% sure why they include it, because it's kind of like, well, it's not the old stuff, but it's not a new stuff either. So it's kind of, well, it's on the fence, but it's only available in the preview version of React, the experimental version. So you can't use blocking modes in the current version either. If you could, it would kind of make sense, start adopting some of the new stuff, but no, you need to run the experimental version. And if you do, you might as well go to the full concurrent mode. So I've never actually done any serious experimentation with blocking modes. I go from legacy mode or the actual production mode, as I like to call it, that makes it sound better, to the concurrent mode. Now, what you lose is string refs, legacy context, and find-dom-nodes, but those are pretty old APIs which are not that important anymore. And you gain a whole set of things. Suspense, which we could use anyway, but you gain suspense list, which will show and will look at used transition, and a couple of other things. Now, how do you know your application is not using one of those first three? Turns out it's already checking. So, if I go to index.tsx, where is this thing, React.strictMode? If you run your application or part of your application in React.strictMode, it checks whether those components are not doing anything wrong. Those features are invalid, but also things like updating state from render functions, et cetera. So, in order to find that, it will actually double render all your components in development mode, not only in development mode, in production mode, this does nothing. So, it kind of helps you prepare.
Comments