Complete Intro to React, v6 Rules of Hooks and Q&A

[00:00:00]
>> Let's dive a bit more into like what a hook is. The reason why these are called hooks is because, react has this render cycle, right? So every time that I type in here, react kicks off a re-render. And it's gonna call these hooks, and the order that it calls them is particular.

[00:00:17] So if I had three of these, right, just pretend that these were different looking. It's depending on that these hooks are called in the same order. So this one's gonna be the first one, this will be the second this be the third one. Like if this was animal and breed.

[00:00:36] Just ignore the other two for now. And this was dog and this was poodle It's really essential that these are called in the same order because react is depending on the fact that these are gonna be called New York because they're kind of like getting hooked up by the React re-render, right?

[00:01:01] The reason I'm telling you all this so if I do like if, I don't know Some thing is true. I put that in here. This is gonna really mess up my renders because then if I have something like underneath that like this sometimes this will get called sometimes this will not get called.

[00:01:28] It'll mess up the order and those hooks will go out of order, which means that you might have dog in this piece of poodle or you might have Seattle in the post, like so you'll get the wrong piece of state at the wrong time. So, in other words, never ever put hooks inside of for loops, never put them inside of if statements.

[00:01:47] Never ever do that. That's a huge no, no. In fact, we're gonna add an es lint rule that's not gonna let you do that. Does it re-render the entire page, or does it re-render just a component. So react is actually quite smart about where we renders and how that's actually why it's able to get a lot of performance out of it.

[00:02:05] And why companies like Facebook and Netflix and all those other big companies like is it's really intelligent about it three render cycles. So is actually able to pick out just the part of the page that's changed and re-render just that and leave the other parts of the page alone.

[00:02:18] So in this particular case, notice that this thing changed. So if I had another component on this side of the page, it wouldn't rerender that one it would only rerender this one.
>> Hooks seem like a great place to store a state that you want to update every render.

[00:02:34] But where would you store a state that you don't necessarily want to render? They're affected render Exactly.
>> Sure. So the question is, this seems like a good place to put data that wants to like that can update frequently that you want to affect the renders and those kinds of things.

[00:02:53] Why would I wanna store data that I don't necessarily update that frequently or I don't want to affect the render. So kind of two separate questions. The first one that I answer is where do I put data that I don't update frequently? And the way I'll answer that is if it ever updates the render, you should put it in state, right?

[00:03:16] So even if it updates in frequently, that's fine. React is plenty efficient with those kind of things. So just go ahead and put that in a hook. Now the question is what happens if I have a state that I don't want to affect the render, which is, I'm gonna go with pretty rare but if it never updates, and it's kind of a singleton, you could actually just put it outside of here, right?

[00:03:40] And I could say const something equals here, right? And then this is gonna stay the same across renders. But it's not gonna change between components, right, if you have multiple components are gonna share the same state. So that's something to keep in mind. Otherwise, there's things like refs, which we can talk about in a different world.

[00:03:59] We'll talk about an intermediate, but there's another hook called use ref that would be helpful for that.
>> I guess a question I would have is, I'm curious if you could. So you were saying like not to set state and for loops, what would be the best practice of setting state conditionally based on like the state of another variable, so it'd be to have state variables for both and then render it conditionally.

[00:04:26] Or could you say like if like use a ternary operator to say like if location equals Seattle do this or if it equals Detroit equal that.
>> So I think the question becomes like you kind of have dependent state right where one piece of state is dependent on another piece of state that comes before it.

[00:04:45] So let's say basically what I would do with something like that if I have like location here, and I'm gonna show that it's raining or not, and if it's in Seattle, it's definitely raining obviously. And then anywhere else, it's not raining. You would just calculate that state here, right?

[00:05:03] So I'll have another variable say like const is raining. This wouldn't be in a hook, right? Because it's derived from other pieces of state. So, location triple = Seattle WA, True, false, right? And so I would like calculate that outside of that and not store that in a hook.

[00:05:25] Now there's something called memo where you can actually kind of store things like that if it's a really expensive computation, and we will talk about that in intermediate react as well.
>> Would it be possible to get the non de structure version of line four, just so I can see it?

[00:05:41]
>> Yeah, sure. And actually, thank you for calling that I meant to talk about that. So this probably looks really weird to people. It's really common. You'll see this a lot in react, but this is exactly what as he said, this is called destructuring. So let's just rewrite this.

[00:05:58] So what it looks like without destructuring. Actually, we'll call this location and it really is a tuple at the end of the day, and I know you say this tupple and I will die on the hill that I'm still gonna call it a tupple. tuple I don't know, I don't even care anymore.

[00:06:16] So now I have this thing. This is an array now. In fact, you can see here, it pops up a nice type definition for me that it's gonna be a string and a dispatch function. So now I would have location equals constant Location, Location tuple, zero and const set location Equals location tuple 1.

[00:06:43] So all this is saying here is like I know that these are gonna come back in this particular order, call them these names says look, 0 is gonna be location and 1 is gonna be set location. Is that better?
>> Yes, thank you.
>> Cool, good question. This is extremely common in reacts, so It's one that you'll wanna get used to.

[00:07:17] The nice thing about this is it types very well for TypeScript. So everything comes in with very defined types.