useState & Redundant State Anti-Pattern

[00:00:00]
>> David Khourshid: The other one is using refs. So, using refs is actually good when we have values that don't mean to cause a RE render. So you could think of component states as being two parts states or values that should cause RE renders because they are related to the actual UI that's being rendered, or states that is not related to renders.

[00:00:25]
It's sort of internal and something that you want to keep internal. So, for example, this timer, we might have a timer ID and a way to set the timer id, and the reason that we have it external. Because I know some of you might be saying, okay, the proper way to do this is put it in a useEffect and then clear, but we might have some way of externally stopping the timer, and so we have to handle that.

[00:00:52]
So that might be one instance where you would see the timer ID being external outside of a useEffect. But the idea is the same. We have this timer ID that has nothing to do with the rendering at all. So what should we do instead? We should put it in a ref, and that way the logic is a lot simpler and we're not going to trigger a RE render when we update that timer ID.

[00:01:20]
Again, this is one of those things that might not seem like a problem in your code base, but it does keep your code a lot simpler and it is just a better pattern. You want to limit the amount of RE renders and you also want to simplify the actual logic.

[00:01:38]
In short, use refs when you want something. Refs aren't just for DOM elements or things like that. They can also be for any sort of value that does not need to cause a RE render. And the third one, this might be trickier to find, but I promise you, this is something that's really going to improve the way that you handle state in your components, and that is working with redundant states.

[00:02:08]
So, just like with derived states, we want a single source of truth for all of our data. And so with derived state, we saw that in like, okay, a total can be computed from a list of items. But like I said, sometimes it's not so clear. So, an example with redundant state that I see a lot, let's say that we have a hotel selection.

[00:02:29]
So we have a bunch of hotels that we're looking at, and we want the user to be able to select a hotel. What we would typically do is say, okay, they want to select a hotel. It makes sense in our minds. We're going to let them choose a hotel and then set the selected hotel directly.

[00:02:46]
The problem with this is that we are creating redundant data. So we have a selected hotel, which is an object that's exactly the same shape inside the hotels over here. And instead we could actually derive that data. So I'll just show you how this works. Copy this over.

[00:03:12]
All right, so instead of having the selected hotel, what I want you to do instead is have the selected hotel id, because we could derive the selected hotel from that. So if we change this to set selected hotel id now, now this becomes a string instead. So we're no longer doing that.

[00:03:36]
And so now we could just select the hotel id, which is a string, change this to the hotel id, and then we could apply our first pattern, which is deriving that state. So const selectedhotel, and then we could just find the hotel based on its id. Now, this is actually really useful because let's say that you're selecting a hotel, and you also want these hotel items to dynamically change.

[00:04:11]
They might change for some reason. The price might shoot up, or a date might become unavailable. You might be fetching this data from an external source. So the problem with selecting the entire hotel is, is that because it's no longer derived from that data, and instead it's redundant data, you might be showing stale data.

[00:04:30]
So that's one of the biggest dangers of selecting the entire object. And this just makes the logic, both reading and updating a lot simpler, because now all you have to worry about is an id.