Instructor: To create a caching behavior, I'm going to create an object called cache and a function, which we'll call cache person. Which takes a cache then returns a function that takes the URL. Later on, we're going to call this cache person function and pass in this cache. Then that will return this function which will expect a URL.
This will simply return cache URL and check that property. If that exists, it will just return it. If it doesn't exist, we'll set the cache URL to our create Loader which is down here. Let me delete all of this example stuff. To our create Loader, where we pass in the URL.
With all of this intact, all we have to do is come into where I said exhaustMap and create Loader. Now, we're going to switchMap on cache person, where we pass in our cache. It's saved there, and you'll see the same behavior.
The difference now is, if I look at the network tab, I'll refresh and clear everything out. If I click on C3PO, you'll see he was requested. R2D2 was also requested. If I go back to C3PO, you'll see there is no request for number two, yet it's still showing up -- because that data is cached.
If I go to Darth Vader, I'll make a request for four. Back to C3PO, no request, Vader, no request. I can load all of these up and switch over to slow 3G. Because everything is cached, it behaves super-responsively because it doesn't have to load anything.
Let me clear this out, and you can see the requests are only for images that are already cached from the disk. Since the browser handles the image caching. Looking at how this works, switchMap will take this URL that map generates and pass the URL to the cache person function.
You can see in cache person, it's this function that's getting the URL. The cache is coming from here and, again, returning that function. There's the cache, the URL coming from the map. Each of these URLs are just the URL to the person to load.
I use those as keys inside of an object. You can think of this cache of having properties of https, then Star Wars egghead training/the person number. Then the values are going to be the observable that's loading in that URL.
The caching is possible because of the promise behavior we discussed, where promises will always return that same value that it resolved. Otherwise, if you're not using a promise in this scenario, you'd have to chain on something like shareReplay.
Which could store that value inside of a subject. Then anytime that observable was accessed, it would give that replay value. Because we're using promises, we can live with just the simple behavior.
Anytime cache person is called again on that switchMap, it's going to look up that URL and grab that observable off of our cache object. If the syntax is a bit unfamiliar, I can write it like this. Where I say this is a function that takes the cache and returns a function that takes a URL.
This will check if the cache has that property already set on it. If it does, return that. Otherwise, make sure that the cache URL is set to our create Loader URL, then return cache URL.
You'll see that same behavior where, if I click on a few of these and go back, it's not making those requests again because they're cached. If I click a new one I haven't gone to yet, I'll make that request. Click, it did not make either of those requests, because our cache has keys of the URL.
Which was storing the observables, and the promises always return what was resolved.