-
-
Notifications
You must be signed in to change notification settings - Fork 364
[Notify] Add Notify bundle #49
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
Conversation
56433be
to
4ac0d8e
Compare
Push notifications (native) |
Hello @mtarld I think this component still makes sense, could we perhaps use latest Symfony changes (especially on ux-mercure) to finalize it? Would you have time to have a look at the failing tests/rebasing? |
Hi @tgalopin! |
f553489
to
efef096
Compare
Hi @tgalopin! I updated the bundle to be consistent with other bundles (and to reuse some good ideas taken from ux-turbo-mercure) Still, some questions remain:
|
5a1469c
to
eb64ba5
Compare
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.
LGTM
16ab0ea
to
de8d8eb
Compare
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.
Very cool 😎
6d30370
to
eb2d549
Compare
As we required PHP 8.1 for that bundle, I updated the test workflow to run the bundle's tests on PHP 8.1. |
Thanks for that wonderful review @weaverryan 🙂! |
As we required PHP 8.1 for that bundle, I updated the test workflow to run the bundle's tests on PHP 8.1. The test matrix DOES need some work. But if a bundle advertises that it works on php8, we need to keep testing it on php 8.0 (though, we should probably also test on php 8.1). Btw, I think we need to improve the test matrix further to be dynamic. There is way too much repeated config, and that's only going to get worse as the number of components grows. If you're interested, I had a WIP version of this at https://github.com/weaverryan/ux/tree/typescript-central-ci - where each package created a dynamic build. I think it's an interesting approach. For this PR, I'd love to see your excellent explanation put into the docs. But after that, it's ready to merge! |
environment variable by specifying the ``topics`` query parameter. | ||
Otherwise, notifications will be sent to ``https://symfony.com/notifier`` topic. | ||
|
||
Then, you can inject the ``NotifierInterface`` service and send messages on the ``chat/mercure`` channel:: |
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.
Then, you can inject the ``NotifierInterface`` service and send messages on the ``chat/mercure`` channel:: | |
Then, you can inject the ``NotifierInterface`` service and send messages on the ``chat/myMercureChatter `` channel:: |
Example of a native notification | ||
|
||
Extend the Stimulus Controller | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
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.
This looks a tiny bit to short
Thank you Mathias! Wonderful work! |
Docs tweak over at #325 |
In Symfony 5.3, Notifier was shipped with a Mercure bridge (symfony/symfony#39342)
Then, with a simple
$this->notifier->send(new Notification('My message', ['chat/mercure']));
(and a running Mercure server), it'll be easy to create "Server-Sent-Events".Therefore, the Notify bundle idea is to listen to these events using JavaScript event sourcing and convert them as native HTML5 notifications (using the
{{ stream_notifications() }}
Twig function).(The "Notify" name was the first that came to my mind a could/should be challenged)