⚠️ This lesson is retired and might contain outdated information.

Cache Remote Data Requests with RxJS and Vue.js

John Lindquist
InstructorJohn Lindquist
Share this video with your friends

Social Share Links

Send Tweet
Published 6 years ago
Updated 2 months ago

Caching data in RxJS can be as simple as creating a caching function which can store the values in an object. This lessons walks through creating a caching function and explains how the function closes over an object then pairs a url with an Observable that returns the resolution of a Promise.

Instructor: [00:00] 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.

[00:23] 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.

[00:48] 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.

[01:08] 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.

[01:31] 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.

[01:52] 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.

[02:13] 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.

[02:33] 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.

[02:49] 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.

[03:03] 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.

[03:17] 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.

[03:38] 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.

[04:00] 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.

[04:19] Which was storing the observables, and the promises always return what was resolved.

egghead
egghead
~ 28 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today