| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
The default behaviour of a service worker is to check for updates any time the site associated with the worker is visited, but to only activate the new worker once no clients are open for that site. That effectively means that you need to open the site, close the site, and then open the site again to use new service worker capabilities, which is counterintuitive at best.
I believe that the spec works this way for good reasons: probably because it means that the running service worker never changes out from underneath of a page while it's open, and only changes _between_ visits to a site. That's a good default.
However, it does make testing service worker changes more difficult, as you need to restart the client application twice to see the results (or, at least, restart it once and then exit it). Since most of what we intend to use a service worker for mediates live app behaviour, it will be convenient to see those effects immediately when the service worker changes.
|
| |
|
|
|
|
| |
This was added as part of the original service worker spike, without much consideration for design goals or correctness, and while it _works_, it doesn't meet any specific needs. We can get most of the same behaviour by letting the browser handle fetches directly.
The main thing we lose is offline rendering of the Pilcrow UI, but that only worked partially and only by accident. We should build that from the ground up.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a user clicks "send a test notification," Pilcrow delivers a push message (with a fixed payload) to all active subscriptions. The included client then displays this as a notification, using browser APIs to do so. This lets us verify that push notification works, end to end - and it appears to.
The API endpoint for sending a test notification is not documented. I didn't feel it prudent to extensively document an endpoint that is intended to be temporary and whose side effects are very much subject to change. However, for posterity, the endpoint is
POST /api/push/ping
{}
and the push message payload is
ping
Subscriptions with permanent delivery failures are nuked when we encounter them. Subscriptions with temporary failures cause the `ping` endpoint to return an internal server error, and are not retried. We'll likely want retry logic - including retry logic to handle server restarts - for any more serious use, but for a smoke test, giving up immediately is fine.
To make the push implementation testable, `App` is now generic over it. Tests use a dummy implementation that stores sent messages in memory. This has some significant limitations, documented in the test suite, but it beats sending real notifications to nowhere in tests.
|
| | |
|
| | |
|
| |
|
|
| |
Service worker basics I guess.
|
| | |
|
| | |
|
| |
|
