Repository navigation
add ability to override service worker onPush #24387
Description
EDIT(@gkalpak): Related to issue #26413.
I'm submitting a...
[x] Feature request
Current behavior
The current service worker displays notifications but not offer interaction options, the ability to send messages back to the app to update the app state, or consume web push messages arbitrarily shaped or empty data.
Expected behavior
To override the onPush response of the service worker with my own code. This code would be integrated into the service worker completely replacing the current onPush response when the project is compiled to JavaScript. The code could pass messages to angular services in my project, to allow me to update my app state in response to push messages. The code would responsible for displaying the notification, so that I would have full control over the appearance and behavior (up to what the Web Standard allows).
My suggestion would be to allow an angular service implementing an interface (which containing an onPush function) to be passed to the service worker module on registration. The service worker would then call that service instead of its own method on push events. A disadvantage of this solution would that custom service would run in a different context from normal service workers (since it would run in the service worker context, not the window context). This would be surprising to new developers.
A simpler though perhaps less elegant solution would be to pass a callback function to the service worker module instead of a service. Or the service worker could expose an observable which could be subscribed to for overriding the default push notification system. I believe that these solutions would also have the context weirdness problem. I am not deeply familiar with the angular code base so I am unsure of how easy to implement or angular in style these particular solutions would be.
What is the motivation / use case for changing the behavior?
The angular service worker support caching really well, likewise for updating the service worker. It handling of push notifications is lacking; however, even in world where the service worker configuration covers most common things, like navigating to a URL on click or even simple user interaction, there would be a need to integrate code from the app into the behavior of the service worker.
For example, to display the new message in the app even if the user is no longer connected to the internet at the time of clicking the notification. (In this hypothetical, the user was connected to the internet when they received the notification, of course) This would avoid the awkward experience of being told there is a new message and seeing the message in the notification and then clicking the notification and being brought to a page which doesn't show the message because the page cannot load it from the server anymore.
If we could override the onPush event in the service worker, then the app could add the message to the page at the same time as it displays the notification, thus preventing the user from losing their ability to view it when clicking the notification.
An alternative reason for overriding the onPush even is if one needs to consume push events which one doesn't have tight control over the shape of the data inside. For example, if one is using third-party server app to generate the push notifications, or changing the data inside would require making a request to another development team. Additionally the developer could make their app respond to empty notifications which are easier to test and emit from a server.
Additionally, the web app notification interface is fairly new and it would be nice if angular let web developers use as poorly supported (or as widely supported) features without having to wait for angular to implement them.
Environment
Angular version: 6.0.4
Browser:
- [x] Chrome (desktop) version XX
- [x] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
For Tooling issues:
- Node version: 8.11.1
- Platform: Windows 7
Activity
gkalpak commentedon Jun 11, 2018
One way to solve this, would be allowing users to specify scripts that are loaded along with
ngsw-worker.js(as described in #20756 (comment)).ribbon-otter commentedon Jun 12, 2018
I was looking at writing a pull request to support
importScripts()at the top of ngsw-worker.js as @gkalpak described in #20756 (comment). However, if custom javascript is injected into the service worker, this reasoning in Service Worker Driver Constructor no longer would apply exactly because that custom javascript could be tightly integrated with the client side app.Loading the custom javascript with the application cache would work to preserve the reloading of the service worker, except then we would have to enable be able to "unload" the custom javascript, which is either complex or not possible (correct me if I am wrong). The unloading would be needed so that a single service worker could serve both the old and the new versions of the app.
gkalpak commentedon Jun 12, 2018
It is true that supporting
importScript()would offer a way for people to shoot themselves in the foot 😱The original idea was to be able to provide the equivalent of
polyfills, so that people can work around bugs in certain browsers.Using it for adding functionnality (or changing the behavior of the SW) is more dangerous and should only be done "on one's own risk" 😛
In any case, one should always strive to keep this extra functionality decoupled from the application code and content (and backwards compatible).
TBH, it is a "risky" feature and I am not sure if it is a good idea to add it. (Yeah, I know, I proposed it as a possible solution - doesn't mean it is a good solution 😛)
On one hand it allows more flexibility for people who know what they're doing, but on the other hand it opens the door for lots of self-inflicted frustration for people who think they know what they're doing 😛
(ServiceWorkers are a different beast.)
CharlBest commentedon Jul 4, 2018
@gkalpak I think this would be a very good feature to have. It would make the service worker more usable for developers to use for their own purpose/use case and not lock them down via the available configs. Also handy for polyfills like you mentioned. I get your concerns but think it's like that with many implementations. Developers can make crazy complex things just out of any simple features. It's up to them to be diligent. I understand that is easier said than don't and still get where you are coming from.
I came here because I'm also having this issue: #20756
PS: the service worker is really easy and handy the way it is currently. It is an ever changing area/space at the moment and is probably difficult to keep up. But great work!
angular-robot commentedon Jun 4, 2021
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
angular-robot commentedon Jun 24, 2021
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
alxhub commentedon Apr 14, 2022
By design, the Angular Service worker does not support adding in user code - it was designed to be a drop-in SW and is necessarily limited in its functionality as a result. We have #21197 to consider adding custom extension points like this, but for now other service worker implementations (e.g. Workbox) are a better option for user-defined behavior in the SW.
angular-automatic-lock-bot commentedon May 15, 2022
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.