Offline support with service worker

[xtuc]

First naive implementation to support offline mode.

Refers to issue #647

Some points:

• [x] Search is broken (search will work only for already searched items because Algolia doesn't support offline mode)
• [x] Handle trailing slashes in URLs (cache first strategy won't get invalid URL)
• [x] Remove worker development logs
• [x] Add offline indicator ?
• [ ] If the ressource is not in the cache, show an offline page ?

Note that it is necessary to know the files to be cached in advance. That's why I need Jekyll templating in service-worker.js.

@thejameskyle @marcobiedermann What do you think ?

[boopathi]

Why not use sw-toolbox ? ... which provides a declarative way of handling routes

[xtuc]

The offline indicator looks like this :

Might not be the most beautiful way to do.

[xtuc]

Or the grey version:

[xtuc]

Label version:

[existentialism]

Nice work!

I feel like the notification should stand out enough to draw attention, but not be distracting. Maybe black (fits color scheme and contrasts with the yellow header)?

[boopathi]

I tried a variant of grey version. I like the label version. My opinion is that removing/changing yellow might give the feeling of offline.

[addyosmani]

This is all really awesome to see come together. Fwiw, we're seeing a few sites choose the grayed out pattern for indicating offline (coupled with a top or bottom bar with the 'offline' labelling):

Some alternatives we've suggested elsewhere include showing a toast when switching online state or just having something prominent in the UI that can be toggled depending on when the user has a network connection again.

[ikhattab]

using glyphicon glyphicon-off and background color of #f55555 and we can fade color to green and fade out the offline div when the user is online

[marcobiedermann]

@xtuc Awesome, great work you did there. I quite like that there would be a little indicator on the top which shows if the user is offline. Looking forward getting this into production 😄 🎉

[mbj36]

'offline fallback' for the last point would do the same. We have to make a offline page for it. We have to add service worker 'fetch' event in index.js .

Any idea what should offline page looks like ?

[jeffposnick]

Apologies for the drive-by feedback. I work on sw-toolbox/sw-precache, and I've spent some time thinking about best practices for using service workers with templated sites, so I wanted to throw in my two cents.

I'll leave some inline feedback on this PR, and I've started a series of posts laying out some best practices for this scenario, with part 1 at https://jeffy.info/2016/11/02/offline-first-for-your-templated-site-part-1.html

[jeffposnick]

After looking through the code, my high-level comment is that it's unfortunately tricky to effectively implement this type of runtime caching: you have to balance a few things:

• making sure that every user who visits your site once doesn't end up downloading a large amount of data in the background, which might be expired before they ever get a chance to make use of it
• the flexibility to make small changes to specific pages and only causing those changed URLs to be purged and refreshed
• the desire for the speed of cache-first with the need to ensure that updates to previously cached content are exposed to the user

I don't think it would be safe to move ahead with the current implementation, for the reasons outlined in the inline comments. If you did want to go with an approach that relied on sw-toolbox, then switching to a networkFirst strategy for the URLs on your site would end up being safer in general, but it would still not be as ideal as it could be. (I'd be happy to try out an approach that I've been working on at https://github.com/jeffposnick/jeffposnick.github.io/tree/work/src, but it's not quite ready for production at this point.)

[xtuc]

@mbj36: There is a 404 page : http://babeljs.io/404 but I wanted to create a dedicated "Sorry, you are offline" page.

@jeffposnick: Yes, good explanation of the problem. Your comments pointed out the bad points. I will update them. Thanks.

[xtuc]

An other try :

[xtuc]

@boopathi @marcobiedermann @mathiasbynens @jeffposnick what are you thought about this ?

[jeffposnick]

The current implementation, with toolbox.fastest for (most of) the requests means that you'll have a much better upgrade story, and you'll avoid the issues I've previously pointed out where content would be cached once and potentially reused indefinitely. I don't see any specific shooting-yourself-in-the-foot issues.

What I'd recommend is that you try doing some sanity checks in a local deployment by keeping an eye on Chrome DevTool's Cache Storage display in the Applications panel, and the Network panel.

The Cache Storage display will give you a list of URLs that are being cached, and you can verify that you're not accidentally caching anything that you don't intend to. (Your /* route is very broad, and it's possible that there are requests that the site is making which you realize don't need to be cached.)

[xtuc]

Thanks a lot @jeffposnick for your explanations.

LGTM, @hzoo @boopathi can we merge it ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity 😴. It will be closed if no further activity occurs. Thank you for your contributions 👌!

[babel-bot]

Deploy preview ready!

Built with commit 18d25806d5d4ff72bf07b7aed5a5de8b261eb9dc

https://deploy-preview-978--babel.netlify.com

[thenamankumar]

@jeffposnick @xtuc Hello I am new here and trying to contribute.

I was thinking of if we can have different named caches for different kind of assets. Like for images we can have a separate cache, so that we can manage it differently and even it may improve the performance while matching requests from the cache.

Also I think it would be safer to go with networkFirst for the website assets, with cache maxAge.

And do we need maxEntries? Can't we let it be maximum as they will get expired by age and so the the caching of assets won't be limited.