Passing flash from LiveView to DeadView

Is there a “proper” way to set “flash” message on a LiveView/socket and redirect to a DeadView where the said message would be consumed/displayed?

I guess that’s a “no” :wink:

I would have answered if I knew a definitive answer. :sweat_smile:

Here’s a blog post I was going to follow, before LiveView .18 came out, and Phoenix 1.17 demo.

Live View components can be embedded in non live view pages, so perhaps you can embed a live toast component.

I don’t think there is. Flash messages with http are handled via the session. The session can hand off data to LV, though the same is not possible the other way round. That’s the same reason why you cannot login purely in LV.


Some Ideas

  1. Use JS to store message in local storage and present upon redirection

  2. Implement “Announcements” system which uses in-memory KV store plus intra-node clustering to broadcast and retain messages keyed to particular user IDs until dismissed. Lodge announcement prior to redirection. Implement UI which displays such announcements with LV backed DOM elements that look like flash messages

  3. Use a query parameter or variable in the POST request for reflection of message in DOM

  4. Redesign system, emit flash message from the controller that serves the dead view

Basically, I see several approaches to this problem all possible with a few hours work. It all boils down to how you are redirecting, if you are doing it via location.href in JS usually it’s a GET but you can use some JS magic to make it into a POST then it is easy to put in any sort of additional payload including message.

If the session store is server-side, then you can. It should be possible to update the database directly, by passing the session management.

Yes, thank you. I can imagine a few ways to work the problem around. I was basically trying to confirm that I didn’t overlook anything “built-in” before I start working around/against framework.

{:noreply, redirect(socket, to: Routes.user_path(socket, :show, user))

Which translates to window.location.href as far as I understand

It’s the Phoenix default, cookie based approach

I see. I haven’t found anything either but wanted to confirm that there’s nothing I overlooked.

Tnx. The problem there is a bit different, although related indeed. For the case at hand I’ll probably redesign the flow and display the message still on LV, before redirecting to DV. I think that’d be the easiest way. Need to check whether that will be acceptable.

1 Like