Become a member
to unlock all features

Level Up!

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


    AngularJS $cacheFactory service

    Ben ClinkinbeardBen Clinkinbeard

    Angular's $cacheFactory can be used on its own or to customize the behavior of $http calls. This lesson introduces the API and shows how to integrate $cacheFactory into your project.



    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




    Angular's CacheFactory service is just a simple function that will let us create and use cache objects. If you pass a name to the CacheFactory, that will give you back a cache instance, and then, it's basically just a simple keyvalue store. We can put in a key of "key," and a value of "val," and we've got our string of val is now in our cache.

    We can then retrieve that value by using mycache.get key, and then, that will give us back the value, which is the string val.

    Cache instances also have an info method that will let you get a little bit more information about your cache as a whole, such as its ID, and its size, how many values are actually stored in it. If we were to add a second value here, we'll just add the string "bar" keyed on the string "foo."

    If we then run that again, we're going to see that our size is now two, because we've got two values in there. The other side of the coin is obviously to remove values from the cache. If we say "mycache.removekey," then check the info again, we're going to see that our size is now back down to one.

    Alternatively, if you just want to clear out a cache, and reset it completely, you can use the remove all method, and that will put your size back down to zero.

    Lastly, there's a destroy method that actually destroys the cash entirely. If you are then to call CacheFactory.get, and use your cache's name, which is how you retrieve an existing cache, you'll see that that is now undefined.

    Now that we've got a basic API review out of the way, let's look at a more realistic use case here. We'll get rid of this code, paste in some code here, which we'll see in just a second, at some buttons up here for our UI, and then, you can see we've got a fully skeletoned app here. We've got the NG app attribute to bootstrap our app.

    We've got our controller specified on the body itself. It's going to control the whole app. We've got our three buttons here, which all call a function called "load person," and they're just passing in a number here.

    Then that load person method, here, takes in that number, and then it's going to call the Star Wars API, past that number as part of the URL, and then, we're just going to log out the name property in our result.

    If we go ahead and run this, and we click on C-3PO, and Luke Skywalker, you can see that those names do in fact come back. You can see here in the network panel that it is actually making that call every time we click one of those buttons. This is where a cache can come in handy.

    If you just add an options object to the get call here, with a property that says "cache-true," what's actually going to happen is that behind the scenes, the cache is going to cache these responses based on the URL used, and then, just pull from the cache as necessary.

    If we then click "Luke Skywalker" three times in a row, you can see it's actually only going to fetch that data one time from the remote server. After that, it'll just pull from the cache.

    Same thing with these other buttons, the first time we use them, it'll make that remote call. Afterwards, it's just going to pull from the cache, and avoid any network activity. You can also specify a custom cache object for your HTTP calls to use by just passing in a reference instead of that Boolean value.

    If we tell it to use something called "mycache," which we'll create here. We're just creating a new cache instance by passing that to CacheFactory, and then this time, we're going to give it a capacity of two, which basically just means, "cache up to two URLs."

    If we then reload our app here, and we can use the Luke Skywalker and C-3PO buttons, then, you can see if we just stick to those, we're not going to get any extra network activity, because those two calls have been cached.

    But when you give your cache a capacity, it turns into an LRU cache, which stands for "Least Recently Used." Moving on to this third value, our URL is going to push the first one out of the cache, meaning that only the second and third URLs are cached, but the first one no longer is.

    The last thing I want to show, it would get tedious if you had to specify this cache in every single call you make.

    What you can actually do, we can go ahead and get rid of this, and instead of setting this to a variable that will use, we can actually set the http.defaults.cache to the instance of our own cache.

    Every http call, unless they specify their own cache in their config, is going to use this cache that we have just created. If we save that, go over here and refresh this, we can then verify that our behavior is the same as before.

    We've got two of these URLs cached, nothing happening there. Once we've moved to the third, then, we see a new network activity, and we can again use the last two without any network activity. Go back to the third one, and we got another network call.