Why is choo-service-worker not being used?

choo-service-worker is commented and installed in a fresh choo app and I don’t know why? if we uncomment that line tests would also start green and we could also close #22

[YerkoPalma]

So, I’ll answer to most of your comment, but first I think I didn’t put much emphasis in this offline guide from Jake Archibald, is pretty much the main resource of almost anything I have to say here haha. So, here we go:

Bankai exposes a few env vars, most importantly process.env.FILE_LIST. We could do var URLS = process.env.FILE_LIST or something similar. This will then get auto-updated on runs ✨

Cool, considering there is different kinds of files in a web app, I think that the file list mentioned is the minimum resources to have your app running offline, but still people could load resources that are not in that list. I would do as you say and map that list to the initial cache files, and maybe comment out or point to On install - not as a dependency strategy from the guide I linked, to guide people that want to load resources without changing that environment var of the file lists. This would look like this

      cache.addAll(
        // other resources
      )
      return cache.addAll(
        // core FILE_LIST
      )

We should have a commented-out url check to disable the worker. Something that if it returns false, it disables the entire worker. We can’t trust things to always go right, so having a hard killswitch to roll back a deploy can work wonders. Even if it requires a custom backend, and is disabled by default.

I guess that having service-worker activation only when NODE_ENV is set to true is enough. Anyway I’m not against this, but if we keep this commented, we should mention in comments that running tests in fresh installs will always fail until the line is uncommented or choo-service-worker is uninstalled.

the “add to cache by default on fetch” code should probably be enabled by default - and it should probably not register resources if incorrectly fetched. Otherwise there’s not too much use for service workers, right?

True to all of that. We are not registering resources when fetch fails, not sure why you said that haha.

VERSION should probably be set to process.env.npm_package_version. Turns out we don’t support this yet in Bankai, but we should (opening up an issue about this right now).

👍

Use the package version as the sw version, this allows, for instance, only delete cache on major version, minor and patch only updates cache.

Hmmm, I think it’s probably a good idea to always delete the cache, but try and copy over already existing resources over first. This is a large part of why we made hashes a part of the resource’s urls, so that the name itself already verifies whether or not something has changed.

👍

// to emit backgroundSync events in choo, with choo-service-worker installed, emit the event ‘sw:sync’ passing a tag you can use it to add non-urgent resources to cache or whatever you want

I’m not entirely sure what you mean by “pass a tag”. Could you explain a bit more about what you mean by this?

Well that’s how the BackgroundSync API works, you just send tags, like some kind of signaling to the service worker, that’s what we are doing in choo-service-worker.

Add some event handler to add resource to cache on user interaction, this might need some changes on client.

I’m intrigued by this. Could you explain a bit more about how you’d see this?

Well this is actually a bit similar to the background sync thing, because both actions are dispatched from the client to the service worker. The difference is that background sync is dispatched fro the client, but not the user, think about twitter in the browser, when you have a new tweet, the home page tells you there are n new tweets, without needing your interaction, this could be done with background sync dispatched in a time interval (not sure how they are actually doing it, just guessing haha). On the other hand, an user could save for offline (add to cache) voluntarily, for example, check Una Kravets blog, if you pick a random post, you’ll see a link to save for offline, so this will go in cache only when the user wants. Ideal for blog posts or gallerys with several Gb of images when users only want a few of them.

---

So wrapping up, I think we should:

• Use FILE_LIST env var as the core files to be cached for offline.
• Always delete cache on new runs (version changes).
• Add commented out sync event listener.
• Add commented out options to cache files not in the main list.
• Send notifications on new versions, which means sw updates.

The client should get some updates too:

• Add a link to activate notifications (this is necesary if we want to send feedback to users).
• Add a resource (choo HD logo maybe) that it is not in the main list of files, and add it to cache on click.

[YerkoPalma]

With the latest PR service workers are enabled in production and tests are passing. Closing 😃