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.appcache
file, served with the content typetext/cache-manifest
- 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.appcache
as an attribute on thehtml
tag of the page that will use it - If the
manifest.appcache
file 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 index.html
.
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 manifest.appcache
index.html
...
<iframe src="./iframe-inject-appcache-manifest.html" style="display: none"></iframe>
...
iframe-inject-appcache-manifest.html
<html manifest="manifest.appcache"></html>
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
Automate AppCache
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[1].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