Why would you use AppCache ? An API that is messy, not as advanced as service-workers and moreover, which is being removed from the Web Standards ?…
With the Progressive Web Apps, we hear a lot about service-workers. They are very powerfull for a lot of things (including offline support). Though, they’re not supported on IE nor Safari … 🙁
So, until the rest of the browser vendors catch up, if you want to provide some offline experience to all your users, you’ll have to use AppCache which is still widely supported.
AppCache in a few words
- You have to provide a
manifest.appcachefile, served with the content type
- This file will consist of three different parts:
- CACHE: files that will be explicitly cached after they’re downloaded for the first time (this is the default section)
- NETWORK: white-listed resources that require a connection to the server
- FALLBACK: fallback pages the browser should use if a resource is inaccessible
- You will reference this
manifest.appcacheas an attribute on the
htmltag of the page that will use it
- If the
manifest.appcachefile is updated, the browser will download the resources listed in this manifest (if not, or offline, it will use the cached resources)
AppCache in a SPA
Note: Skip this part if you don’t bother about providing different
index.html file whether your users are online or offline.
If you’re developing a SPA, and you want to provide a different
index.html entry point whether you are online or offline, you’ll have to use a little trick. You won’t reference your
manifest.appcache directly in your
index.html but in an other html file that you’ll include in an iframe to your
That way, the
index.html file won’t be cached by default (as the master entry) and you’ll be able to define a fallback in the
... <iframe src="./iframe-inject-appcache-manifest.html" style="display: none"></iframe> ...
dummy manifest.appcache file
CACHE MANIFEST # v1 (some version id) assets/foo.png assets/bundle.js assets/style.css # more assets ... NETWORK: * # that way, you'll be able to force the fallback of index.html # to an other file when you're offline FALLBACK: . offline.html
If your app relies on a large code base, with a build step, you will need to automate this task. You’ll also have to ensure that AppCache doesn’t mess with your development workflow (meaning disabling it when developing).
I will describe the steps I took to automate AppCache support on topheman/rxjs-experiments, a little project using RxJS (no other frameworks involved). The workflow of this project is based on a seed I made and open-sourced: topheman/webpack-babel-starter.
Step 1 – Define if we should “activate” AppCache
When you’re running webpack in dev-server mode, that means you’re developing, so you want your sources to be kept up to date (you don’t want AppCache to cache them).
const MODE_DEV_SERVER = process.argv.indexOf('webpack-dev-server') > -1 ? true : false; // ... const APPCACHE = process.env.APPCACHE ? JSON.parse(process.env.APPCACHE) : !MODE_DEV_SERVER;// if false, nothing will be cached by AppCache