If you travel a bit, chances are you have probably found yourself stuck with zero network connectivity way too often. This is frustrating, especially if you just wanted to continue reading some news articles, blog posts, or you wanted to get some work done.
Unfortunately, with your browser, attempting to make requests for something from the network while being offline doesn't quite work out so well.
Even though on planes, the subway, in hotels, and at conferences, Wi-Fi may provide you with opportunities to restore your connection, in general you will have to wait for the network to return online in order to request the pages you want to view.
Previous attempts to solve this issue include AppCache. It seems to work, to some extent, but the issue with AppCache is that it makes a lot of assumptions about user interactions. When those assumptions are not met, the application will fail to function as expected. It is also designed to work well with single page apps, not the traditional multi-page websites.
Also, one of the most challenging problems with providing a seamless user experience with web apps is making them functional while offline. This is an important issue to resolve, given that most users today access web apps on the move. Enter service workers, a script running in the background of our browser.
Being able to use a web app, regardless of the connectivity, means users can operate uninterrupted when they are on board a plane, the subway, or in places where connectivity is limited or not available. This technology will help boost client productivity and will increase the availability of the application.
With service workers, we are able to pre-cache some assets of a website. What we are referencing as assets are JavaScript files, CSS files, images, and some fonts. This will help us to speed up the loading time, instead of having to fetch information from the web servers every time we visit the same website. And of course, most importantly, those assets will be available for us when we are offline.
A service worker is a script that stands between your browser and the network, giving you, among other things, the ability to intercept network requests, and respond to them in different ways.
In order for your website or app to work, the browser fetches its assets, such as HTML pages, JavaScript, CSS, images, and fonts. In the past, managing these resources was mainly the browser's responsibility. If the browser couldn't access the network, you would probably see its Unable to connect to the Internet message. There were techniques you could use to encourage the local caching of assets, but the browser often had the last say.
One feature service worker uses heavily is promises. So it is important to have a good understanding of promises.
Promises are a great mechanism for running async operations with success dependent on one another. This is central to the way service workers work.
Promises can do a great many things, but for now, all you need to know is that if something returns a promise, you can attach .then() to the end and include callbacks inside it for success, failure, and so on, or you can insert .catch(), the end if you want to include a failure callback.
Let's compare a traditional synchronous callback structure to its asynchronous promise equivalent:
sync
try {
var value = Fn();
console.log(value);
} catch(err) {
console.log(err);
}
async
Fn().then(function(value) {
console.log(value);
}).catch(function(err) {
console.log(err);
});In the sync example, we have to wait for Fn() to run and return a value before any more of the code can execute. In the async example, Fn() returns a promise for the value, then the rest of the code can carry on running. When the promise resolves, the code inside then will be run asynchronously.