Caching is a really hard problem, but it's important for good user experiences to make the app snappy, especially when you know that the data you're showing to the user is unchanged on the server. In this lesson we'll take a quick look at how we could do this in a simple way.
How does this compare to Browser caching, I wonder? Is this approach only a good idea because you are faking your Pokemon requests?
Thanks for the course :)
You might be better served to leverage the browser cache, yes.
@Kent Hi Kent, thanks for awesome material.
Closer to the end of the video you mentioned "the reason this is working is because the resource maintains the state"
But isn't the reason in not calling the createPokemonResource
in the first place for already existing pokemons? I don't see how status
of the promise is related to returning an object from the cache.
Can you clarify please?
Other than that - awesome as always <3
Yes, you're correct. And the reason that works at all is because the resource is maintaining the result
and status
. So what I was trying to say is that we're not holding onto the data specifically, we're holding onto the resources, and the resources are holding onto the data. And we don't need to create new resources for ones that already exist. That's why all of this works.
Thanks, got it! :tada: