More convenience functions to deal with assigns inside LiveView

My guess around assign_new only accepting a function is that since there is likely no good reason to ever store a function as an assign, it’s more concise—especially for framework code—to just have the single higher order function. It’s also kind of self-documenting to say, “Hey, there’s no good reason to store a function in assigns!” Highly speculative, of course, since there’s nothing stopping you from using assign to store a function.

I don’t see a version of assign_new that took a non-function arg being accepted because now you have a function that looks like it just assigns stuff but gives functions special treatment. This means it would have to be more verbosely documented and there would probably still be a steady enough stream of people asking: “Why did assign_new(socket, :foo, fn -> "hello" end) store "hello" and not my function??” I believe that is called Principle of Most Surprise

Where are the places you are using assign_new a lot? I’ve only ever used it to store defaults which was made obsolete by attr. And defaults for live components can always be done in mount/1. I’m interested in your usecase regardless!

Good point! I see how this could be confusing if we have both options under assign_new. In that case, making the distinction by having different functions would be better (eg: assign_new_lazy), but now we are talking about introducing a breaking change to the API (still doable though).

There are still some cases where attr is not enough, especially when you are dealing with computed assigns (e.g.: if are doing stuff like class variance authority) or when you have more complex slots (IIR attrs in slots don’t support required and defaults yet).

For this game I was developing, I had fewer components that needed something like assign_new but I used assign_merge a lot… I had GenServers representing part of the game world and they were responsible for holding the game state (like player actions and such). Because LiveViews acted as “windows” into what was happening in the GenServer, they were always receiving communication back from those GenServers with new information that had to be merged back, usually in the shape of maps with many assigns.

Edit.: I thought about another use-case after posting, which is using assign_new on an LV mount to compute stuff just once… I’m not sure if I remember this right, but since LV is mounted twice, I guess I was using assign_new to process expensive stuff just once, so I was using that a lot too

about assign_merge

Currently assign/2 allows to pass a map or keyword list:

A keyword list or a map of assigns must be given as argument to be merged into existing assigns.

though, it doesn’t have a “lazy” counterpart that would take a function..

That’s interesting, I never thought to do that. If the computation is still going when the socket connects, do you have to handle that scenario? Will it trigger a re-render in that case when it does complete? I’ve never developed a game so it’s that would be full of considerations I’ve never, uh, considered, ha. That case does seem like a good fit for the upcoming assign_async.

I’ve never had attr need anything more than a simple value. I’ll have to look up class variance authority as I have no idea what it is so definitely not in a position to comment!

The problem I guess is that since mount is called before and after the socket has connected, if you do just assign, you’ll be processing the value twice (going to the database two times for instance). I’m not sure if it’s the same use-case for assign_async, which seems more useful for slower computations (like you mentioned).

(For this game in particular, the computations are not usually too complex and don’t take longer than some ms, but I still have to do lots of queries to retrieve the state of game objects from the db, and some of those depend on others to be computed and so on).

As is typical of me I either neglected to express some thoughts or was careless while deleting sentences in an attempt to be less verbose. I was imaging using assign_async in conjunction with testing for connected?(socket).

This is unavoidable, and does not change by using assign new. The static connection and the live connection do not share values at all, they may not even happen on the same elixir server.

Where assign new helps is that in the case of the static render, you may have assigns already set from your plug pipeline. Assign new lets you reuse those on the static render, and then forces you to tell Phoenix how to fetch that same assign for the live render. This helps you fetch it only the 2 times and not 3 (twice in the static render, once in the live).

The only way to avoid fetching things twice is to use live redirect between pages so that you skip the static render entirely.

You can also do:

socket =
  if connected?(socket) do
    assign(socket, :foo, App.get_foo())
  else
    assign(socket, :foo, nil)
  end

no? Or are you making another point I am missing?

Yes sorry, I was not as precise as I could be. The mount itself is unavoidable, but you can condition on connected to avoid loading stuff in the static mount. Mostly what I mean is that if you need a value on both the static and live renders then it will necessarily be fetched twice, assign new doesn’t change that.

Right, yes, I think I introduced confusion by not directly asking if @thiagomajesk required it on static mount and sort of ran with “maybe” while trying to answer