Use BroadcastChannel and standardize message payloads

[jeffposnick]

The Broadcast Channel API ships in Chrome 54, and has already shipped in Firefox. It would be a good mechanism for allowing our service worker libraries to communicate with all of their client pages, without having to loop through them and use postMessage() to each one.

I'd like to see this used for cache updates notifications (see #47) and potentially other types of events in the future.

It's a good idea to standardize on the message format, and then to use a similar standardized format across our libraries. sw-toolbox recently implemented some one-to-one messaging (not using the Broadcast Channel API) that used messages like:

{
  type: 'cache-updated',
  source: 'sw-toolbox',
  cacheName: <name of cache>,
  url: <url of the updated resource>
}

But now I'm thinking that might be a bit too free-form, and not map well to new types of messages.

The FSA message format has its roots in Flux, but at the same time, it's flexible enough just to be used as an all-purpose format, and since it appears to have some traction in the developer community, it might be a good choice.

I'm envisioning broadcasting messages like

{
  type: 'CACHE_UPDATED',
  meta: 'sw-precache', // or 'sw-toolbox', etc.
  payload: {
    cacheName: 'my-cache-name',
    updatedItems: ['index.html'] // additional items
  }
}

I haven't tagged a release of sw-toolbox yet, so there's still time to switch that over to use the Broadcast Channel API (if available) and to use a FSA message format without breaking anyone.

Thoughts? @addyosmani @gauntface @wibblymat

[addyosmani]

I like the idea of moving to the Broadcast Channel API but would personally tag the current version (e.g with 5699e5d) and include BC API in the next release. I don't think it would break anyone and TBH it's probably safe, but your call :)

[jeffposnick]

I'm closing this in favor of GoogleChrome/workbox#43