Flash messages should allow more than one of the same type

Phoenix Forum Proposals/Suggestions
,
1

Hello all,

Apologies if this has been proposed before I guess, but I have a very simple one:

With the increasing importance of LV, I think the flash system that comes out of the box in Phoenix needs tweaking to allow more than one flash message of the same level at a time, so they could perform like toasts.

Thanks!

1 Like
2

The good news is that there’s a library for that:

3

I agree. I’ve done this with Phoenix and LV before, reimplementing the flash store as a Keyword list and re-implementing helper functions to append tagged tuples to the list of unresolved flashes, and have my flash template group by type (errors at top, info at bottom) and iterate instead.

Can’t find the source code for the life of me, though. But I’d back a proposal to Phoenix readily!

4

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 :sweat_smile:

4 Likes
5

I’d be satisfied with a separate system. It can be phx-toast or whatever. But we probably gotta be honest here that toasts are more common than flashes in 2023. I also think it’s too important of a thing to be confined to user space, at least while the flash system also exists, which opens the door to solving this problem better out of the box.

1 Like
6

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.

2 Likes
7

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

2 Likes
8

and I will make a dedicated announcement thread for it when its a little more polished.

2 Likes