This course has been updated! We now recommend you take the React Performance course.
Transcript from the "setState Patterns" Lesson
[00:00:00]
>> So this is kind of a lot to think about this a little bit as a public service announcement around things you should do and not do, predominantly not do with state management. I regret to inform you that I have seen all of these. So this is like they go and usually like most things like this don't happen from someone right here, they come from like a series of refactorings over time, where you end up in a given situation through many small well meaning things.
[00:00:33] And so just to kind of call them out when you see them cuz they could have some some implications. So one of the things, we do need to remember is let's say that we don't say of any kind of, with props, we have PropTypes, so we can say, there should be a string or there should be a number.
[00:00:49] You can get a little squarely with state. Now if you something like typescript a flow, some issue, there should always be a number, there should always be a string. But it is important to realize that with state, you don't necessarily have the same safeguards that you have with props.
[00:01:05] And so a lot of times I like this damn even off tweet, which you have to use in any talking about react you have to like reference at least one damage even off tweet in order for you to be taken seriously. So this is my foray into that which is all right, should we keep something in actual react state, can we calculate it from the props?
[00:01:22] I'll go into what that means. If you can calculate it from props that were passed in, you should not store it in state. And we'll see a quick example of that in a second. If you're not using it in the render method, you should not store Oregon State.
[00:01:34] The reason we have to use this as a state or the hook for your state is because we want to be like, I want to update this value. And I also want to tell react to go ahead and rerender to figure out what changed. If you're not rendering it you don't need to store it in state because you don't want react to run it.
[00:01:53] You can just use regular old JavaScript. You can store it as a class property. You can store it in a variable. You can do anything along those lines. You can put it on a method. You only want to do stuff that when it changes, I want to trigger that rerender.
[00:02:07] If those two things aren't true, then maybe yeah, you should be using back state for it. So what does it mean by derivations of props? A really great example that I've seen from time to time is when you take two other things, and the easiest example here is, all right, this component got in a first name and a last name property, for showing a user profile or something like that.
[00:02:26] Cool, let's put a space in between and store that in state. The problem is, is, and we'll see this in a much later example when we're actually using routing, but the same component can be reused on the page with different props. And since this only happens in the constructor, what happens there is, this won't get re-calculated, right?
[00:02:46] You'll still have the old, full name, right, which is probably not what you want. And again, that is not necessarily an error, per se, it is how react behaves. So you're not gonna get an error message. It's just gonna be one of those things where, suddenly, it's not doing the thing you think it's supposed to do, and you don't know how to handle that.
[00:03:02] So what should you do? Well, you can just put the props together as you need them. So you could do it in the render method like this. Now, if the props change that will trigger the render method, everything will work as expected. If you don't like that, and using a class component, you could theoretically make your own method.
[00:03:20] You'll notice the get key word here. All get does, is it lets you call it like a property without having to use the parenthesis. So that gives you effectively the same effect, but in a way it will actually respond to the process. We're not actually kinda accidentally caching stuff and state that you shouldn't.
[00:03:39] And if you don't wanna shove everything to the render method like I saw before, you can break stuff out. So, for instance, if you wanted to pull out, render in this user profile component, you can break it out. This pattern works all over the place and if it doesn't use this anywhere, you could actually just pull it out into a regular old function, this would actually be more performance.
[00:04:00] Because instead of getting called every time, it's just one place that's hoisted up there and to find once. There's actually battle plug-ins that will try to go through your code and do this for you as well. All right, don't use state for things you're not going to render.
[00:04:15] So this is a really, again, [LAUGH] inspired by a true story. Which is like, cool, we wanted to hold on to this web socket connection or in this case, like this is a set interval, the key polling. But we wanted to hold on to this thing and continue polling, right and we'll hold on to state so that we can access it when the component will unmount.
[00:04:38] Like, you don't need to do that. You can do it with other life cycle methods, right? But a lot of times if you don't know that happens when you think that like, I need to store this but you're not rendering it.
>> About the last example that you had up there with the alternative approach is that the reason why I guess I'm looking what about get derived state from props, the life cycle method there the static method that's available there?
[00:05:04]
>> Yeah,
>> You see a lot of people saying like, yes this is okay or no, don't do this because it's bad.
>> Is I have never been convinced that you need to do it.
>> Okay.
>> Right, I have never seen a situation where something similar didn't work out right.
[00:05:18] A lot of times a non zero part of my job is to ask why seven times in a row. We have to use it. Why? Why that? Why that? And then eventually is that we don't actually have to do that, right? And it's hard in the in the esoteric but generally speaking, I haven't found that we always, rarely do we actually need it.
[00:05:37] Does it probably exist in the codebase that I work on? It's probably in there somewhere, right? But generally speaking in a code review, it usually doesn't pass the kind of scrutiny of like, is there kind of a simpler thing? Because it's really when you're doing very tricky stuff like that, to well six months from the you understand why you did it, right?
[00:05:56] And we all thing that we're like poets when we write comments, and that we'll always understand what it is, that never happens.
>> So even before, you did say too, there's no silver bullet to anything.
>> Mm-hm, yep.
>> But the ideas is that even if you have to compose multiple pieces of properties together, of plops together, you don't necessarily want to store those in state.
[00:06:15]
>> Yep.
>> Only when have you ever run into example when you do actually you want to store them in the state.
>> No,
>> Okay.
>> [LAUGH] That's also just trying to dig through my memory banks real quick like I'm sure someone I work with could get blamed me on something.
[00:06:30] And unclear if I was right. But I'm gonna go with a no as my kind of like gut check on that one All right. And then finally, you can use sensible defaults. If you are gonna set something with a component mounts, just make sure that, cuz if it's gonna be an array, just start out with an empty array.
[00:06:47] That way you don't have to do conditional logic in the render. Cuz if you're gonna map over undefined, that's gonna go poorly for you.