Typed Custom Hook for useSelector

[00:00:00]
>> This strategy that I use, and I will continue to build on this strategy, and this I think, at this point, the conventional strategy for this as well. This is not a Steve Kennedy personal, do it this way or get out kind of thing. It is a useful way to do this, I think it's at this point conventional.

[00:00:23]
So we can take that. What we can also do is we'll go ahead and do the same thing for dispatch and then what we'll do is make custom hooks, right? Which means that instead of useSelector, you make either, you have to name it something fun, right? You can name it useSelector and then welcome to autocomplete never working again.

[00:00:40]
I think the convention I see a lot now is useAppSelector, which I don't love, but I'll show you how I get around that in a little bit. But we have, we can make our own selector that we know the type. We know that we can create our own functions.

[00:00:54]
We saw ourselves do it with createTask before, so we could create a hook that has the correct types and just use that from this point forward. So yes, for a lot of this, a lot of this is solved for us, there are still certain things that we have to deal with and do.

[00:01:07]
So let's go take a look at that. This is where I make another file. And that file is gonna have the very glamorous name, Of hooks.ts. If that grows, should you break it out into smaller files? You absolutely should. Should you start out with a complicated folder hierarchy that you don't know if you're gonna need?

[00:01:28]
That's a personal choice. I can tell you my opinion, which is don't, right? And because this is a pattern, there are some helpers for you in this case. So here we're gonna grab useSelector, And what we're gonna do is, I'm gonna go with the convention. I don't love this name, but, useAppSelector is going to be something that then calls, we'll write it kinda like pseudocode first.

[00:02:00]
It's is gonna take the state, it's gonna figure out, ApplicationState, and then it will hand that state to useSelector. It's really gonna make a function, so on and so forth, right? But you could theoretically, okay, this takes a state or should really take a selector cuz that took a function, right?

[00:02:28]
I'll do just a second or two of this because you can see how this eventually ends with on some subset of it. And so this would take the, And even in this case, it would return something from that object, right? The nice part is, could you sit there and acquiesce?

[00:02:48]
Could you look and figure out what all the properties are? You absolutely could. Turns out that this is a common of enough thing where what you can do, there is actually a version of this that you can simply go ahead and try this. You say that this is, whatever I'm gonna assign to this variable should be of the TypedUseSelectorHook, right?

[00:03:17]
And we say that that's gonna be based on my ApplicationState. And then we just assign useSelector to it. And so now this version of useSelector is simple, I just took it, I assigned it to one where it's like, let me tell you something about my expectations of the type for this.

[00:03:35]
And that one, you look, it is typed and ready to go, right? So if you find yourself struggling with this and you find anything that makes you feels like this feels like I'm setting myself up for tedium, right? The heuristic that I would like to engender in you is you should use that as an excuse to be like, I think there might be a better way, right?

[00:03:55]
Because the goal of some of these patterns is to take the common pain points that we all feel and kinda prevent yourself from writing stuff that works but kinda might become problematic, and be able to kind of use it in your files. So let's save this and then we'll jump back over cuz now we're cooking.

[00:04:16]
Right, and now in this case, instead of useSelector, we will do, useAppSelector, it knows what state is, and watch this. state.tasks.entities. Yeah.
>> It's a bit of a derailed question, but how does this work in terms of rerenders when state updates? You mentioned that map state to props takes advantage of memo, what is it working in this case?

[00:04:54]
>> We can look totally under the hood, I know that doing this from memory, I know that map state to props took the component implicitly wrapped in memo. I do think that this only gets retriggered if the state changes, but it doesn't do the thing because it's inside the component already.

[00:05:15]
It doesn't do the thing where then there is that equality check to make sure they're the same. So I think it is slightly less performing, and what you would do in a lot of cases is you break the selectors up, you'd have one that just got the tasks and so if that was a different object, right?

[00:05:27]
And generally speaking, you could break it up into smaller pieces and, yeah, I will do a version of that in a little bit, I think so. So yeah, I think less performant out of the box or less memoized, performance is like, we're just grabbing an object off it, V8 will compile that down to byte code so fast, right?

[00:05:48]
But yeah, it does not implicitly memorize the props going into the component cuz the call is coming from inside the house. Awesome, so that is a pattern that if you're kind of using hooks and you're using any amount of TypeScript with Redux, then I highly recommend. Because it will allow you to then not have to do a whole bunch of stuff that's gonna make you feel really bad about types.