Instructor: Now, this query component is a render prop API. That makes it really nice, because we can declaratively use this query component, passing our query variables and our normalize function, and then get the state and render based off of that state.
It's a really nice API, but it is a little bit nested. What if we could actually turn this query into a custom hook? This query isn't actually rendering anything. What if, instead of calling the children prop that we're passing it, it actually just returned these items of state?
Let's take a look at what that might look like. We're going to need these items of state. We'll just pull these out right here. I'll say const those. We'll destructure those off of useQuery, and then we'll want to pass all of these values to useQuery.
We'll go from here to here and paste that in. Wow, that's a lot less nested. It's actually quite a bit easier to read. If we multiple of these render prop-based APIs, we could maybe change them to be hooks as well, and have even less nesting.
Our tree would be a lot smaller, which would be good, too. Sweet. Let's go ahead and make this happen. I'm going to take this useQuery, I'm going to scroll up here to the top, where I'm importing query, and I'm going to do a named import for useQuery.
Now, let's go back to our query component here, and let's make this a custom hook. Instead of query, we're going to do useQuery. Instead of children, we're going to just simply return the state. Then we can have export useQuery.
Now, we probably aren't going to be able to refactor our entire application to be using this new custom useQuery. We probably will still have some areas of the application that need to have a render prop-based API of this query component.
Let's go ahead and make that. We'll just say const query equals a function component that has children. Then it takes a bunch of other props, as it was before. Here, we'll just call children with useQuery props.
That's identical to what we had before. We've done a simple refactor. Nothing has changed for the users of this query component. If we save that, we can even take a look at our tests, and our tests are still passing as well.
Our tests are actually using our query component. Actually, this is the way that I prefer to test custom hooks, is by creating a render prop-based API out of them, and then rendering that render prop-based API, and testing it like a regular React component.
In review, to make this work, we went to our user situation. We took all the contents of the children prop, the things that we were returning from our children function, and we simply returned that. Then we got the data we needed from the useQuery, from the custom hook version of our render prop-based component.
We plucked off the data that needed in our render, and we provided as an object, the options that this custom hook needs. Then to make that work in our custom hook, we simply rename this useQuery. We removed the children prop, and we treated this as a regular options object.
Then instead of returning a call to children and passing the state, we simply return the state. Then to make this easier to test, and to ensure other places in the application can continue to use the render prop-based query component, we created a very simple render prop-based query component that simply uses the useQuery hook.