This lesson has been retired.
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Optimize Suspense HTTP requests with createResource from react-cache

    Kent C. DoddsKent C. Dodds

    NOTE: The react-cache API is not stable and has changed. Check this issue for more details.

    Many components in your application will need data that has to be fetched over the network. When that data is loaded, however, you don't want to make a network request because you have the data stored in cache in the browser.

    React gives us an API to handle cache for us. We can use createCache and createResource to set data in the cache after fetching over the network.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson


    Instructor: 00:00 If I had to do this every single time I wanted to make an HTTP request in React, I would probably switch to Vue. Let's go ahead, and we'll clean this up. We'll make it function, and we'll call it createResource. That's going to take a function for our fetchPokemon, and then it's going to return an object that has a read property.

    00:19 It will accept an ID, then we'll put all of this logic in here. I'm going to just copy this. We'll paste it here. Then instead of Pokemon and Pokemon name, we're going to use ID. For Pokemon, we'll say data. Then, here, we'll say return the data, in the case that there actually is data.

    00:37 If there's not, then we're going to make this fetchPokemon request. We want to make this generic, so we'll use this function here. All this function needs to be is a function that accepts a single argument and returns a promise. That is what our fetchPokemon thing is.

    00:52 We have fetchPokemon. It accepts a single argument, and then it returns a promise that resolves to the data that we want to have stored in the cache. Then we can go ahead and call this createResource. We'll say const myPokemon equals createResource, and our resource fetcher is going to be this fetchPokemon, so we'll pass that in here. 

    01:13 Then we can say myPokemon, instead of all this code, this Pokemon equals myPokemon.readPokemonName. Cool. Then if we go in here, we can say new. Sweet, we get that. We can say Pikachu, and we get that. Then if we try to get new again, it's going to be instantaneous, because it's already in the cache. Perfect.

    01:36 Now, I'm still not a fan of all of this code. It has some pretty significant performance problems. Luckily for us, the React team is building a React cache that we can use in our React projects. Instead of all this stuff, I'm going to import unstable_createResource. We'll alias that to createResource, and that's going to come from react-cache.

    01:59 Now, the unstable prefix here is indicative of the fact that createResource from react-cache is actually not ready. react-cache is currently in Alpha. When it's actually released, this unstable prefix will come off, and we'll be able to just import it as createResource.

    02:16 Now that we're importing this, and we're releasing it to createResource, that's clashing with our own createResource function name here. We can get rid of our own createResource, and we'll use react-cache's createResource instead. Luckily for us, we implemented our createResource with the same API that react-cache uses, so we don't need to make any change there.

    02:36 We actually are no longer using this cache object, so we can get rid of that. We'll save this, and then we can try out new, perfect. Can we get Pikachu? Indeed we can, and then it's right in our cache, so it loads instantaneously. 

    02:53 react-cache is way more optimized than that little createResource function that we created, and all of this is only working because we have the suspense component, with a fallback telling it to react to what it should render while that promise is in flight. 

    03:06 Again, this is an API that is unstable. I would not recommend shipping things to production this way, but it's likely that whatever react-cache ends up being, it will look similar to what we're looking at right here.