This course has been updated! We now recommend you take the State Management with Redux & MobX course.
Transcript from the "State Patterns and Anti-Patterns" Lesson
[00:00:01]
>> Steve Kinney: All right, so we'll talk a little bit more about patterns and anti-patterns. And this is again echoing something that we saw. When we were thinking about that, the thinking and react piece. Which was state should be considered private data. This is unique to this component. It can be passed down to children.
[00:00:19] But generally speaking we don't want to like modify it from outside a component or anything along those lines. And it's a little bit more dangerous than working with props. Because with props, we have PropTypes to warn us if we change it to the wrong thing. With states, we don't necessarily have that, right?
[00:00:37] So one solution for having safer code, in this case would be, what if we had our state like effectively get passed in as props. We'll see some patterns for that, we'll see a container pattern and a higher-order component pattern, and other patters along those lines that allow us to do that.
[00:00:53] But just working with state we don't have the same protections, that we have for props. And again, we talked a little bit about this but again, should something be in captain react state. If you can calculate it from the props, no, all right? Then we talked about the full name example.
[00:01:08] Then what we'll see a little bit later as well. If you're not using it in the render method, it shouldn't be state. We'll talk about where to put that stuff in a second and a use case for that. So, we're not gonna use state as derivation of props.
[00:01:22] So we don't wanna like, make a full name that we have to keep up to date. We wanna derive it. So we wanna either in the render method, we can say like hey, fullname = firstname + lastname. If that's getting a little out of control or there is too much happening, right?
[00:01:37] If you're making simple string concatenation, fine, do it in the render method. However, like we all have a friend. Sometime that friend is ourself, who take us an excuse to write like seven ternaries long, right. To try to figure what the state should be to derive at that point.
[00:01:54] You're better off pulling it out into a method on the class you can come and then use it right then and there, right? Again, this is not the state fullName. This is simply a method on the components class that will go ahead and get you the fullName based on the two parts of states.
[00:02:14] So this isn't any different from doing it in the render method. It just gets it out of there, so you're not getting a 20-line-long render method for a simple div, or something along those lines. So when you pull it out and we can use it, right? Again, this is a slightly different.
[00:02:29] We can break stuff out in the helper methods and that works for a lot of things. When we're trying to like map over some state. So here we have a user profile, we can also like pull that out and do a helper method of renderUserProfile, and get very simple render methods.
[00:02:46] Because it is very hard to debug a giant render method that is 100 lines long. Trust me, I've done it. I've also created it. I'm not proud of myself, but there are patterns that we can use to kind of pull in as much data out of the render method and like having it be a little more clean to read.
[00:03:04] Now when we read this render method, it is very clear what's happening here. We'll have the very important user controls. We'll render all the users. And then we'll have whatever the footer is, right? We can see it. It's a lot more easy to kind of read in parts.
[00:03:15] Cuz remember, you will be reading code a lot more than you write code, right? So you always wanna think about the most important developer in the world, which is future you, right? Future you is six months from now and doesn't remember the code that previous you wrote. All right, the last one we talked about when we looked at the tweet is, let's not use state for things that we're not going to render.
[00:03:35] So for instance, if we have a Twitter live stream, for some reason, and it's using just basically on an interval, gonna call the API, we don't want to put that in state, because we're not rendering that. Well you're like, well I need to hold on to it, so I can get rid of it when the component announced.
[00:03:54] Yes, you do need to hold on to it, otherwise you have a memory leak, very true. However, it shouldn't be in the state, it's not something you're rendering, you can put it on the class, right. You can put it, you can store it on the actual class itself and so here we can like put it on this.tweetChecker, right?
[00:04:12] Which we can store on the instance and then we can remove it. It's not part of state. All right, if you find yourself putting things you're not rendering on state, try not to do that. Routing back to the prop tags things that we were talking about before is when possible use sensible defaults, right?
[00:04:31] If you're expecting from the API, you're normally gonna get an array. Then, you should have the default state of that component, be an array. Cuz otherwise what's gonna happen if that call takes longer than you thought, and you try to map over it.
>> Steve Kinney: Kaboomies, right. Things are not going to go well.
[00:04:51] So we need to think about it because we won't get a prompt type warning or anything along those lines cuz it's just state. And so we need to program defensively around that.