Advanced Redux with Redux Toolkit

Custom Hooks for Async Requests

Steve Kinney

Steve Kinney

Advanced Redux with Redux Toolkit

Check out a free preview of the full Advanced Redux with Redux Toolkit course

The "Custom Hooks for Async Requests" Lesson is part of the full, Advanced Redux with Redux Toolkit course featured in this preview video. Here's what you'd learn in this lesson:

Steve creates a useTasks custom hook that returns the array of Tasks and a boolean value representing whether or not the data is loading. This hook is added to the TaskList component, and the loading property is bound to the Loading component.


Transcript from the "Custom Hooks for Async Requests" Lesson

>> I didn't do this but let's actually have another little brief aside. Which is, I can do use selector but I have made myself that hooks file for stuff like this, where you do something, we'll say, use tasks. And we can say that that is going to, that one's going to take everything and it's just going to take, And this is before we said, if we don't really love using app selector a lot of times, I will abstract it into these hooks they're just like get me the tasks.

Whatever that means to you get them for me, right? And then if I ever decide I hate Redux later, I can just swap the internal implementation or if I've done this already with some other either set state or use reducer, cool, cool cool. Tasks.entities, parenthesis close. That should, I don't know if it's off the top, I would have to look at the Redux react dev tools, because that is probably only changing when entities changes.

I don't feel the need to memoize it. I guess I should, because I guess tasks will change now that loading changes. So I probably do in fact wanna memoize the task cause I don't need to like re-render because it started asking for new tasks. That's a good point that I asked myself.

So we'll do loading and here we can do useAppSelector and we'll say state. .loading and I'm just going to make sure that that is a boolean because if it's undefined, we'll say that if we're not loading. Awesome. And then so what I will do is, There's yeah, there's a question of would I break these out into two separate things, right?

Because then I could like triggers, re-renders differently, right? Because even if I don't use memo, loading changes would be the same thing as if the Object got changed. So this app is small that some of the advantages of using a use memo wouldn't serve me. If I bundle these together and these two dependencies are loading and entities, and the, to avoid when loading changes getting new tasks to render, and I bundled them the same react.memo, they would be the same thing.

So I would have to, theoretically, put them in two different hooks, but they're actually going into the same component anyway. So we're re-rendering no matter what. So you could do it if you wanted to. I don't know about the efficacy of it, but it's a thing. And so we could say you could either do the, like tuple syntax, tuple, tuple, tuple, loading.

You just wanna do it as a constant so it knows that it is actual tuple. But you could probably omit the useMemo if you wanted to. Right, and now I can just use, useTasks whenever I want. And you can see that it is an array of exactly only two items.

The tasks and whether or not we're loading. If this had more things like is error state, is updating, you might turn it into an object. But if we wanted a different syntax or, yeah, you might have the error. The data structure is up for interpretation. But. Now we know the task lists and we can switch this out.

Did I export it? It did. Look at me. And now we just change this out. Import it. That'll be the tasks and loading. Tasks start as an empty array so that's cool. Loading we're not using so here was just pop in. That's the word loading a lot. This component I just made just renders null if this is false, so I don't have to put a conditional in there which is a pattern I really like rather than putting loading.

And then the loader component I'm, hey, loading component I will tell you whether or not we're loading. You decide if you're gonna return null or not. So we can have that in place. All right, let's verify, loading. There. So it is setting and triggering the state. And we can get.

You have full control over everything you choose to do. And because it's simply kicking off a promise, you probably, the nice part is it's not a big lift to kind of move into this if you want because you probably already have the promise code somewhere else in your code base, right?

You're just kind of wrapping it in an action that you kick off wherever maybe you were calling it otherwise and then like selecting that data as you need it.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now