-
Notifications
You must be signed in to change notification settings - Fork 124
feat: add Declarative Web Push message support #216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Hi @wapacro! Thanks for this PR. I was not aware of Declarative Web Push, so the provided resources were very useful. As I understand, Declarative Web Push requires a pre-defined format of the push message and this class is providing that. It's backwards compatible in a way that non-supporting clients can have a Javascript-handler that uses this predefined format. Am I right? I'm willing to merge this, however as the spec is still evolving I'm not sure if this is the right time? |
| * @var array<string, mixed> | ||
| */ | ||
| protected array $options = [ | ||
| 'contentType' => 'application/json', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the documentation I saw application/notification+json, but not sure if this is now a requirement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given this comment, the absence of the content type header in the parser spec draft and that there's been no activity on the RFC 8030 side of things for years I assume the specific header will no longer be taken into account. This can obviously change in the future, but for now application/json is a safe bet that can easily be changed if needed imho. I also tested this with Safari, and it works flawlessly with the regular JSON content type.
Yes, that's right. For non-supporting clients it's just a regular invocation of the service worker's You are right in that the spec is not final. But looking at the W3C repository it looks to me like the format itself is mostly a done deal and already merged; the only open discussions are more on badging and the implementation from browser perspective itself (like which APIs to expose where). And since there is already a real-life use case with Safari on iPhone, iPad and Mac computers today, I'd argue that by merging it now some apps can already benefit from the advantages of Declarative Push (while staying fully backwards compatible). Let me know what you think 🙂 |
Hi there 👋
Apple proposed to amend the existing specifications around Web Push with a model for Declarative Web Push notifications and already implemented this for Safari 18.4 on macOS, iOS and iPadOS. From their blog:
W3C is actively working on getting this standardized - the core specs are already merged at w3c/push-api#385, although it's still a working document.
This pull requests introduces the ability to (optionally) send Declarative Web Push messages with Laravel. Since these are by design backwards compatible, they can already be used even when targeting browsers other than Safari. There are also no breaking changes for existing generic Web Push deployments.
References