Working with Live Data in the Service Worker

Key Takeaways

[Music] this is an example of an e-commerce site with multiple kinds of data in this case there are images and numeric data as well as HTML and CSS resources and probably JavaScript as well the question here is which data should go where the general rule is that resources addressed through a URL will be stored in the cache dynamic resources will be stored in an indexed DB database for example app shell resources images and style sheets should be stored in the cache dynamic JSON data should be stored in index DB start by storing data locally here we're using the cache API and the index DB API also known as the ID V let's look at storing JSON data with ID B so what does ID b look like it does not look like a conventional SQL table ID B data is sort of key value pairs in object stores a single ID B database can have multiple object stores this could be a clothing object store inside a product database now the activate event is a good place to create an ID B database point one you don't want to create it more often than needed for efficiency sake and point two doing that during installation could cause issues with the existing service worker note that event dot wait until ensures that the service worker does not terminate preemptively during async actions here we create an ID B products database it is version one inside the products database we create a closing object store this will hold all of the clothing objects the clothing object store has a key path of ID now this means that the objects in this store will be organized and accessed by the ID property of the clothing objects note that we're using Jake Archibald's indexed DB promised library to enable promise syntax we IDB so let's look at storing resources with the cache API now a common pattern is to cash assets on service worker installation note that event or wait until ensures that the service worker does not terminate preemptively during async actions like we said in this example we create a cache v1 cache and store stack assets that's HTML CSS JavaScript images and so on with the cache API now we can get data from ID B instead of the network here we open the products database and create a new transaction on the clothing store of read-only type we don't need to write data we can then access the store and retrieve all of the items these items can then be used to update the UI or whatever is needed are just a word on transactions these are a wrapper around an operation or group of operations to ensure database integrity if one of the actions within a transaction fails none of them are applied and the database returns to the state it was in before the transaction began all read or write operations in index DB must be part of a transaction this allows for atomic read-modify-write operations without worrying about other threads acting on the database at the same time now we can also get resources like HTML CSS JavaScript and images from the cache instead of the network here we add a fetch listener to the serviceworker when a fetch is made for a resource we try to find the resource in the cache and return it however if it isn't in the cache we still want to go to the network for it there are plenty of resources to help you get started for links take a look at the materials that accompany this video but first one more thing what can we do about actions that a user takes when they're offline for example purchasing a product we can record them in ITB it's possible to record actions a user takes while offline in this example the user is trying to make an item purchase via HTTP request which will fail if offline if the purchase fails the catch block will execute this is where we can store the item or user action in ITV how do we use this once connectivity returns well once connectivity returns the recorded items or actions in a DB can be retrieved and sent if the requests are successful the corresponding item action can be deleted from the IDB records