Maintaining Interactivity

[00:00:00]
>> As I just joked, we're gonna take the more perilous ones to live code. We'll do it at the end, yeah. Go out with a bang. So this is one of the newest APIs in React 18. And if suspense is one where it's either background fetching, getting rid of a loaded route, and stuff along those lines, is a great way to build a strategy around it.

[00:00:21]
This one is definitely if you need it, right? It's not like I would not, but there's a powerful concept that solves a bunch of issues which is, so I have got this large list. It's got 10,000 items, it's filtering and sorting them. It might be intentionally slowed down a little bit because this is a very fancy MacBook.

[00:00:42]
If you throw out your computer, you get it nice and painful, right? It's big, and sometimes it is. There's an example on the use of the doctors. It's one of those things that does a whole network graph and shows you all the related nodes and charts out an entire thing.

[00:00:59]
There are tons of times where there is something that it is computationally expensive, right? Sometimes, it's like, all right, let's whip it out to a web worker and stuff like that, but that comes with its own sets of problems, right? There's some things that you can't necessarily do, right?

[00:01:16]
There's some times what your infrastructure will constrain you on, right? There are lots of different trade-offs that you have to make. And one of the problems earlier in React 17 and before is that when you triggered a render, it was synchronous. It's still synchronous, but it would trigger and it would go through and if it was blocking, we had a problem, right?

[00:01:45]
And one of the things that the concurrency model in modern React and React 18 and later brings is at least this idea, and I kind of mentioned this in the beginning, of, well, if everything's urgent, then nothing is. And if nothing's urgent, then everything is, right? And so really one of the most core things that it brings is this idea.

[00:02:10]
It's not that you can say that this is urgent, but you can say that something else is not urgent, right? There was a really great question at the beginning of like, should we debounce inputs all the time, right? And it's like, there's nuance to that question, right? There's a lot of stuff like, should you debounce the network calls that an input makes?

[00:02:32]
Yes, right, especially if they're typing a lot in a field, you don't wanna slam the server. You might get four twenty nined, right? There's lots of reasons why you could do that. If you're gonna fill a large list of 10,000 things, you might choose to debounce it, right?

[00:02:51]
But with a lot of the ways that our hooks are working of like, yeah, this triggers this thing and then effect goes off and stuff along those lines. That can get a little bit gnarly as well. And the idea that React itself, once it starts, doesn't really have a great way to handle things.

[00:03:08]
And this is part of the reason why the concurrency model in React 18 exists, right? And it's this idea to say, non-urgent things can and should be either paused, stopped, thrown away if a new urgent thing comes in. And so that we can prioritize that not all user actions and not all events and not all state changes are created equal, right?

[00:03:34]
And then we can say, these things are important but less important. So if I go back to this example over here, this is literally because we had that great question. We talked about this a little bit in the beginning. It makes my job easier now. Showing the user feedback that they typed in the box, critical, right, it is.

[00:03:56]
I built the app to be intentionally slow and needed it to be slow to make a point, and still got annoyed when it was slow, right? Yeah, but I typed a thing, and it wasn't showing up is both what I wanted and frustrating, right? It's like that old thing, which is bad Internet is worse than no Internet.

[00:04:17]
Unreliable Wi-Fi is worse than just not having the Internet. Not having the internet, you go read a book, right? Having spotty Wi-Fi, you will get very angry. And we're very used to sometimes, especially if it has a network request, seeing a loading indicator. Yeah, we want that to be as fast as possible, obviously.

[00:04:38]
But when I typed a letter, it not showing up on the screen and getting that little happy beach ball that macOS still has, right, and stuff like that, is not great. Or locking up the main thread completely, it isn't great. So this idea that there is now kind of the primitives and the infrastructure within React to say, yo, showing the actual updated list, especially if they're still typing.

[00:05:07]
It's not important to show them the thing they asked for. It's saying, actually catching the characters and getting them there is probably more important. And kind of building on some of the primitives to cancel stuff, so on and so forth, right? This stuff has existed. We did a course on RxJS a while back.

[00:05:27]
And in observables, there is this concept of cancellation and doing all sorts of things. And just ignore that, we moved on to this new version. They typed a letter again, abandon that stream, shift over to the next one. These ideas exist. They just weren't fundamentally in the 2013 version of React, right?

[00:05:47]
It's one thing to then do them fresh, but then also how do you migrate and keep? How do you not rewrite React in the process or at least on a fundamentally, on API level and end up with a new framework, so on and so forth, right? And so we have a lot of us now in React 18, and we'll show it in this example.

[00:06:05]
And it's definitely like, should you immediately go and find a thing that you should do it in your app tomorrow? No, you should not. Some point, there will be a problem. Everyone's debating about a whole bunch of terrible solutions and you will be like, [LAUGH] right? You will be the hero of the day.