Transcript from the "Performance Issue Q&A" Lesson
>> But I guess the other issue is that our input sets stayed on each key press and we should probably debounce that.
>> I mean, that depends, right? Debouncing, the act of debouncing it, like, on the input, you don't really get to debounce it, right? You do have to update the input when they hit keys.
[00:00:17] Right, you play a game where it's like, Sure you'll be calling less things right? But if again, that comes down to that like heuristic of did it take? I mean, like 2.1 milliseconds, right? And is it what are you going to do bounce you're going to wait for how long do you show them a keystroke, right?
[00:00:37] And so becomes a little bit tricky, and does the cost of debouncing. Add more, so on and so forth. Now If they were typing, and this is actually like the example that we end on which is the final example in this like our time together is a forum where like loading and filtering the list takes Forever, right?
[00:00:54] And like how do you like concurrent react update the input while waiting on the list. So like, should you denounce? Like hitting the network on a autocomplete for a search? Yes. Right should you to bounce rendering everything else? But I think like prioritizing the feedback for the user that they did the thing right you do usually that's what you know the difference between what is an urgent update and what can wait a little bit, right?
[00:01:21] Especially like there is a certain amount of insofar that network requests take time, there's a certain expectation that things aren't always immediate. But me, typing should be right me clicking on a thing I should get feedback, right? The idea that the network request goes out and comes back or something happens.
[00:01:38] There's a certain amount of grace for that but If I hover over a button, it should change. If I type in an input field, it should respect that field. But if I click, I should get that response. And those are the things like I think we've all used enough UIs in our life to know as those are the things that drive us absolutely nuts, yeah.
>> Yeah, I think it pretty that the effects will be very similar to oversee, right?
>> Yeah, we'd purposely create the issue, right? We have a set of conditionals here, and we're just gonna call it, right? Should we Do you use effect to let it finish this thing so on and so forth, right.
[00:02:09] During the use effect would let it finish and then go for it again, do the whole commit phase it's tricky. With concurrent react like if there was a this would count as an urgent update because we haven't like things are urgent lists you say they're non urgent, like this would stop a non urgent thing because it's counted as urgent.
[00:02:28] So maybe you would want that, I mean, this app is one that's supposed to intentionally have problems. So yeah, you can find a few more in here too. And you will, but like with this one like what I put in a use effect probably not what I put it maybe in a use memo which is like hey only if only even try to figure out.
[00:02:46] Like if any of these things that depends on have changed right that might make a lot more sense in this case here we're going to check no matter what. But like, yeah, like I don't know if I would use use effect but I would probably use a use memo, right to be like, run this function.
[00:03:04] Right? If and only if the things that he's even cares about have changed at all right and what we said before React is for every hook React is keeping track almost like I'm As every version of it, it's like almost like linked lists like structure, right? It knows when these things changes to trigger a use callback, to trigger use effect, to trigger use memo, but, since use memo has a dependency list, and then recalculates the value Setting a use effect to have a dependency list, and then you'll manually set the thing is just like, I would use probably in this case, but then also this is just flipping of too, right?
[00:03:43] And so the question there is like, we completely a game of, let's measure it. But they will probably both be infinitesimally nothing. All right, so the question was, Why is it bad this way and not the other one is like the simplification of the question, right? This one is like almost not, it's React adjacent but not necessarily a React thing which is.
[00:04:12] Before this ever even gets into U state right where like jobs is going along it's like yeah cops I love cops, right It's gonna be stored it's gonna be a table that we split up into an array I love it I'm here for it. Or look a call to U state.
[00:04:49] It gets the return value. The hooks in React only care about that value the first time they're ever called. Right that's why hook order matters if you ever like tried to put like a hook in a conditional React is like absolutely not right like this is all held together by like it's both very sophisticated and very fragile at the same time right that's why if you have anything like you put the hooks in a for loop react will yell at you If you put the hooks in a continuous like the order of the hooks matter and so when react see is like, hey, this is a second use days like I already had a value for that.
[00:05:43] We say, just par says, yeah, this is a function. Cool. I don't have to call it yet, cuz this is like an uncalled function, right? Hey, react if this is your first time with this hook, go run this function and it'll give you the initial value and react again.
[00:05:59] It's like I've already run this hook before. I'm aware of it. It's the second hope The second hook of the four that are happening in here are five I guess. And the use, it's easy to be in the right order, the sets can obviously happen wherever. But it's the second of the fourth of the four hooks that I know about.
[00:06:16] I already have a value for that. Thank you for this anonymous function which happens to be expensive. You. We'll be throwing it on the floor now, and it has never called and not calling the extension function is faster than calling the expensive function.
>> Why after every keystroke wasn't it?
[00:06:31] Like giving you a different answer? Like you said earlier,
[00:07:23] Is it not always best practice is having to bounce yeah, like I said before on an input field, like, generally speaking the like for most performance advice, it is never an always right. Like it is, you know, otherwise frameworks would do it. Out of the box, or the DOM would I mean, you can't trust the DOM to adjust the stuff, right?
[00:07:45] But generally speaking, it would be just kind of in place by most frameworks or things along those lines. But that is probably not always the UX you want. Now, should you debounce the side effect from that change? Should you to bounce it slamming the server as you're like typing out your like magnum opus and to search for you know the whatever Pokemon you're looking for?
[00:08:06] Absolutely, you should have bounced because you don't want to like slam the server because like they're still typing, but you should show them the characters that they're typing. Right. So there's like usually the bounce things about the inputfield Absolutely. Right. The actual like Cuz React is not gonna change the contents of the input field.
[00:08:24] If you take off the onChange handler, you can hit buttons all day. It will just never show it in there. Other frameworks might, with two-way bindings and stuff like that, handle it. But unless you change the state, you will not see the letters you typed in that input field.
[00:08:40] In that input field. So it will look like I said before, it will look like you have the performance issue in there. So yeah, the question was, did I get it right? The first version of the function generate random color was still called on every stroke. It just didn't update the state.
[00:08:55] Yeah, it was called, it was expensive. And so now we're saying hey useState, only call this if you think you need it. And after the first one, it's like I don't need this. And so it doesn't get called, and not calling the expensive function is way faster than calling it, exactly