This has been asked for a few times. To me this always sounds like mixing up notifications with flash messages.

Flash messages are responses to the last action a user made.

Notifications are everything else that happens async while a user is online.

Generally I’m happy with a single message per type for the former task. The latter one however is something else and usually not just done by removing the single msg per type constraint, but also needs additional metadata of how long messages stay up, if they need to be explicitly closed or not, or they might even have follow up actions to be taken based on them, ….

Personally I think it would be much more useful to develop the latter in isolation from flash messages. E.g. they’ll likely never care for session storage and normal http.

The fact that flash messages in the default boilerplate look like notifications certainly doesn’t help though

Agreed. And in the world of round-trip HTTP requests, you only need one flash message of each type per page render because there is no opportunity to enqueue further actions.

I think it’s less true in LiveView projects, where user input is a continuous stream of events triggering asynchronous updates from the server. Multiple user actions can happen in a very short space of time, each deserving a “response to the last action a user made”. In a realtime scenario, you can stomp on your own feedback about earlier user actions if they happen to do two things that cause errors.

It’s a very frustrating user experience to look up at an error message only to see it get replaced by another before you can finish reading it. Allowing more than one flash message per type allows providing feedback on multiple successive actions.

For any following this, I started my own library as well. its very early but you can start to check it out if you want: GitHub - srcrip/live_toast: A beautiful drop-in replacement for the Phoenix Flash system. · GitHub