Why pwa? Similar to our internal presentation
A PWA needs to be responsive
- Responsive images - srcset, picture element
- meta viewport tag
- media queries
A PWA needs to be on HTTPS
- unless it's local host
Arrow functions
- beware of
this
Promises
- .then()
- .catch()
- these can be chained
- promise.race() is cool also
Fetch
- .fetch()
- a replacement for XMLHttpRequest, like jQuery ajax
- careful - 404 is a valid response, check
response.ok == trueorresponse == 200 - http://myjson.com/ is pretty neat
We talked about IIFE's.
Serviceworker.js Runs on a seperate 'thread' to the main javascript. Three steps required to get this working 1.Register 2.Install 3.Activate It can do all sorts of things, we'll come on to that later.
The tool in chrome, it's also available on the command line and the abilty so save reports as HTML might come in handy.
full of metadata about your site, the Android toolbar color is a cool one. Meta tag fallbacks
Gulp/webpack task to automate creation of serviceworker.js
A quick overview of fetch and promises.
.catch(), .then() (promsies) and .fetch() are everywhere in service workers.
It might be worth looking at some code that I wrote the next day, with some very simple implementation https://github.com/mattgreenfield/the-blues-issue/compare/pwa And Hob made his portfolio a PWA - https://hobadams.com/
caches can be set, updated, and read from anywhere in your javascript (does it have to be in the service worker?). Managaing the cache can be done on any event, so a service worked 'register' event, or something more familiar like a 'click' event. This allows things to only be cached once they are used and prevent unnecessary downloads.
How you manage cache is up to you and there are many statergies depening on the type of data you are caching and how it is used.
- Cache -> fallback to network
- network -> fallback to cache
- cache and network. Cache initially, replaced with network content onces downloaded Hob makes a good point that maybe browsers will one day have intelligent defaults.
...is an 'object store' in the browser, we can store json, files, blobs When online, it might be usefull to store things like progress in a game, or items in a todo list. But when using it with a PWA, it's useful for storing shop categories/products. It comes in to it's own with headless as we don't want to be caching HTML pages anymore. We cache the code to make the page, and the data we pass to that code. 'indexedDB promised' is a library that makes indexedDB easier to work with. Apparently. https://github.com/jakearchibald/idb
There are some new events that you may wish to start tracking with GA
- Notifications enabled, seen, dismissed
- Add to home screen
You cant use the standard GA JS functions when offline. You can't store them for sening once online either. GA can also be used by posting to a URL, and this can be used offiline. The 'sw-offline-google-analyitics' module is useful. It's included in WorkBox.
Notifications are pretty simple to make.
You can set up a server to send push notifications, but there are plenty of services that will do this for you, AWS, google cloud messaging.
Notifications are best when they are relvant to the user and have context. e.g. 'Check in to your flight BA123 to London', not 'Online check in is available'
PWA's can be added progressively
- just add a 'add to home screen link'
- just cache the 'app shell'
- just add notifications
- cache a few files but not everything