petelacey

LiveView 'live' macro and accessing assigns

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

5 comments

/phoenix #assigns #liveview

9 1950 5

2020-01-05 19:29:28 UTC

Most Liked

petelacey

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

Post #6

LostKobrakai

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.

Post #2

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

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.

Post #4