Anko
Hey guys,
I have a pattern I’ve been using on a few projects and I just wanted to share ![]()
Quite often I want to notify a user if something has happened when the browser window is in the background. For my use case, the js Notification API is perfect. This is what I do;
in app.js;
let Hooks = {}
function sendNotification(title, message) {
if(Notification.permission === "granted") {
try {
new Notification(title, {body: message, requireInteraction: false});
} catch (e) {
console.debug("notifcation error: " + e)
}
}
}
Hooks.Notification = {
mounted(){
if(Notification.permission === "default") {
Notification.requestPermission();
}
this.handleEvent("notification", ({title, message}) => sendNotification(title, message));
}
}
Note that this will ask the user for the notification on mount, which might not be what you want. You could easily have a button that pushes to the client with an event that asks for notification.
To hook it in your need to add the hooks to your liveSocket call like;
let liveSocket = new LiveSocket("/live", Socket, {params: {_csrf_token: csrfToken}, hooks: Hooks})
then on your live view;
<div id="notification" phx-hook="Notification"></div>
And finally in your live view supporting code eg a handle info callback;
{:noreply, push_event(socket, "notification", %{title: title, message: message})}
![]()
There are lots of enhancements you can do like only send these notifications if the browser is in the background eg. watch for phx-window-blur and phx-window-focus events and set some state so you know when it’s in the background. You could also enhance it by using a service worker and sending the notifcations via gcm/apns but that was an overkill for my use case.
Overall it’s been a nice pattern - I love when i’m uploading a file or processing some work and get a notification when it’s complete.
Cheers,
Anko
Trending in Discussions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Anko
I noticed something really interesting about this. If your browser doesn’t have focus, Safari and Chrome will disconnect the websocket after about 10 minutes.
A way around this is to push an event from the server to the client, waking it up. phoenix keepalives seem to be from client to server so they do not work for this.
This is what I do;
and in my mount make sure you start with a
Maybe pings should go from server to client? @josevalim @chrismccord
Has anyone else noticed this?
related:
https://github.com/primus/primus/issues/348
https://github.com/socketio/socket.io/issues/2924
josevalim
Perhaps we should have a configuration for it. But after 10 minutes unfocused… it probably makes sense to disconnect until focused again? Otherwise you always risk consuming battery on devices, etc.
Anko
It’s not that they are closing the websocket directly; they are stopping the timers running on unfocussed pages which is stopping the client side ping which is closing the websocket.
I agree a configuration would be a good compromise. It’s hard to know the right approach but it seems like getting notifications would be a use case where we don’t mind the battery drain as much - the point of them is to alert you when the web page is not in focus. I guess if it’s abused the browser developers will actively disconnect websockets when they have lost focus.
Anko
You could also argue that the reconnect work is more expensive than just keeping the websocket open!
josevalim
Are we reconnecting immediately or only when the user focus again?
Anko
It seems to have some backoff but it doesn’t need user focus. I need to perform more testing.
patrickberkeley
@Anko FWIW there’s a PR out there related to Chrome disconnects: Schedule heartbeat on reply to avoid intensive throttling by mcrumm · Pull Request #4309 · phoenixframework/phoenix · GitHub