There have been a number of questions on this forum and on SO regarding accessing Conn.assigns in LiveViews that are mounted via the router’s live macro. Here’s a typical one..
Over in this similar question, @chrismccord clearly states
No assigns are shared from the conn to the LiveView mount
My question is why?
Is this a technical issue or a design choice? I’m new to Elixir/Phoenix, so if it’s a technical issue, I would love to hear it. But if it’s a design choice, may I would humbly suggest that it be reconsidered? I ask that because many applications and libraries have fully adopted the notion stated in the Programming Phoenix book that “Your web applications are pipelines of plugs,” and accordingly alter Conn.assigns to communicate up and down the stack. The typical example being current_user. Not having access to these settings is a little clumsy and non-intuitive.
I appreciate that we may not want to wholesale copy Conn.assigns to Socket.assigns (though I don’t know why), but can we have functionality similar to what we have for sessions? That is, something like this:
live "/resource/:resoure_id", ResourceLive, assigns: [:current_user]
Please know that I’m not being critical. I’m loving Phoenix and LiveView, I’m just hoping to understand better and maybe help with a suggestion.
Thanks,
Pete
Liveviews are mounted multiple times and only the first time is in the context of your current request. All other times are after the website is rendered and the liveview javascript starts the channels connection for updates. At that time the initial request is fully handled and therefore the assigns are long gone. Only data you put into the liveview session (which gets encoded into the actual html) will be available.
There is however an optimization with assign_new, which allows you skip querying the db for the mentioned first static mount if assigns already holds a value for the same key. Later connections will need to be able to retrieve the same data without assigns being available.
2 Likes
Thank you, @LostKobrakai, that was helpful. I had a pretty good understanding of how liveviews are mounted multiple times, but your response helped clarify things even more. Your explanation of assign_new was especially illuminating.
I’m still unclear, however, as to why the live macro does not offer the onetime opportunity to copy elements from Conn.assigns into the liveview session? In a manner similar to how it currently allows copying from the HTTP session, and how you can manually do so in a controller before a call to live_render.
Anyway, thanks again!
1 Like
The HTTP session is communicated using cookies, which have size limits since they have to make it all the way to the end client and then get sent back in a follow on request. Conn assigns and socket assigns reside in memory in your servers, and can safely be very large (assuming you don’t run out of ram of course). Most importantly though, there’s no guarantee that the initial page render and the subsequent live render even happen on the same server! If you’re running several servers behind a load balancer, it’s entirely possible that the initial request is handled by server A, and the live render ends up happening through a websocket assigned to server B. Trying to copy arbitrarily large state between them via the client isn’t going to work.
2 Likes
I completely grok all of that, and it perfectly explains why Phoenix wouldn’t want to bulk copy Conn.assisgns to the http session. But that’s not exactly what I’m asking. My question is why Phoenix doesn’t allow us to pluck and item or two out of the assigns and into the socket session? To repeat the example I used earlier, why is the following a bad idea?
live "/resource/:resoure_id", ResourceLive, assigns: [:current_user]
Notice the made up uses of assigns: in that snippet, not the actually supported session:.
In the Elixir Forum post I linked to above, Chris suggests the following as a solution:
Phoenix.Controller.live_render(conn, Mylive, session: %{local: conn.assigns.current_user})
Which makes perfect sense, but isn’t viable if your LV uses live_link/live_redirect. I suppose one could argue that any particular assign might be too large, and that’s why it’s not supported. If so, then that’s cool. In my case, I already have workarounds. Maybe it’s a documentation issue. It just seems a little odd.
Thanks again,
Pete
I’m back to say that @LostKobrakai and @benwilson512 could not have been any clearer or more helpful, but my brain was a bit muddled yesterday. This morning, however, immediately upon waking, the scales fell from my eyes, and everything slid into place. Your responses were so crisp and accurate that I can’t even rephrase them to help future readers. I was just being dense. Anyway, I just wanted to say thanks again. --Pete
4 Likes
