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:

1. 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.

2. 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:

1. Those assigns go away after the nav
2. 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).

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!

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.

EDIT: I’m just going to create github issues.

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

Nicely done . I’ve done a few Toast versions in Phoenix myself but your version is way nicer