Announcing Live Toast: a replacement toast/flash component for Phoenix LiveView, heavily inspired by the look of Sonner (the amazing toast component for React).
I’ve been cooking this up for a while. It’s still pre-1.0, but the general API should be solid.
My biggest gripe with the default flash system in Phoenix is that you may only have one toast for a given severity level. No more! Now you can use Live Toast to get around this, but it will also continue to render your flash messages in the same style so you can incrementally move towards the toasts instead.
As I said, its still early days so let me know if you find any problems.
This is great! It looked promising when you first mentioned it and I’m into the further work you’ve done.
I’m in the processes of converting a project over to it. A couple of problems off the bat which are only related to docs: you aren’t properly indenting the @doc examples so they aren’t rendering as code in Hexdocs. The code link (</>) is also broken in a bunch (possibly all) places. Not sure why that one is.
Lastly: I would love a :bottom_center option (and of course probably include :top_center) as that’s what I’m currently using. Happy to send a PR.
Oh, also while it’s fairly obvious, the docs mention using the put_toast helper without any instructions on how to import it.
Oh I figured that out, just nice to include in the docs as it’s not 100% clear and causes a bit of mental dissonance Or even like just put LiveToast.put_toast so it’s super obvious it’s not in a submodule or something. I just appreciate idiot-proof docs
PS: Client project has been converted to LiveToast and it’s working like a charm
Little belated but a couple weeks back I released a large new version, 0.7.0 to hex, which fixes some long standing issues with making the flash-fallback function properly across page navigations. have fun!
Question: Is it possible to configure it so that flash clearing is automatic after x milliseconds? So that I don’t need Process.send_after(self(), :clear_flash, x) somewhere.
I personally feel it’s a little out of scope, because the purpose of the library is that you would use the toasts as much as possible and just deal with the issues with flashes yourself (ie, if you want to add that send_after you can and should). But feel free to open a GH issue and we can discuss further and have others weigh in.
For me it’s confusing to treat Flashes and Toasts differently although they look and feel exactly the same. Also, it means I can’t use this library because I have a lot of LiveViews that update a record and redirect back to the main view afterwards, which means I use Flashes more than Toasts.
If you use ‘put_toast/3’ but don’t navigate away, it’s a Toast. If you navigate away, it’s stored in the flash assign and becomes a Flash message. LiveView only uses Flash messages, LiveToast adds toasts to that which look and feel the same, but have slightly different behavior (e.g. auto-hiding). LiveToasts are assigned to the toasts_sync assign IIRC.
I’m going to write some more in the documentation about this (which I know is lacking right now), but the way it works and the philosophy is basically this:
The default flash system has some quirks. The two big ones are:
You can only ever have one flash of a given ‘kind’. You can’t have multiple info level events. You can only ever have one on screen at a time. This is the big problem. It makes the flash system basically incompatible with the UI people are used to where events can trigger multiple messages that push the last one up.
You can’t really trigger them without having a reference to the socket. This isn’t usually a big deal but sometimes is slightly annoying in some async code.
This is why LiveToast creates a new system designed to replace the default flashes. It is not possible to solve the big issue number 1 without making something new.
However, I wanted it to feel like a drop in experience where you wouldn’t have to go and change all your put_flashs to put_toasts. So the library aims to make them look identical. But the idea would be you would go and change all those at some point because the toasts are strictly better.
Navigations
The early implementation of the library presented an issue with navigations however: if you used put_toast on the socket during a navigation, you wouldn’t get anything showing up after the navigation occurred. This was because the library stores state on the assigns of that socket (the one being navigated), and:
Those assigns go away after the nav
All events stop happening once the nav starts
These two things make it basically impossible to show a toast the way the library is designed across navigations. The only way we could do it would be to use some kind of extra sticky LV (which would suck to force people to have to do) or to store more state on the frontend, which would just add a huge complexity.
The simpler option was to force the library to just use flashes whenever we were in the middle of a navigation. Because they look the same, it should be a fairly seamless experience.
Like PJ said, originally flashes did not have any kind of auto-dismiss option, which was initially done on purpose because I kind of wanted to show that they were different, but that option has been added now (it’s called flash_duration).