sezaru
Currently, every dynamic data that you want your LV to render needs to be stored in LV’s state as an assign.
This creates some specific challenges when you want your LV’s to consume as little memory as possible so it scales better.
For example, let’s say I have a Property schema and a LV that will load a property and render it.
That Property schema has a bunch of fields (address, baths, beds, square feet, images, etc), but all of these fields are expected to be “static”, meaning that I will render a page showing the property address, but I don’t have any other code that will use it. In other words, I loaded the schema struct just to render it to the user, but I don’t use it to do anything else inside my LV (except, perhaps, the property id field).
This means that I want to render all information about the property in my LV, but there is no real reason to store all that information in the LV’s socket assigns.
This proposal tries to tackle this scenario by allowing the user to add a special assign that is “ephemeral”. It would work like this:
The user has some state that they need to render but don’t need to store in the LV’s state:
def ...(..., socket) do
property = load_property()
socket = socket |> assign(property_id: property.id) |> temp_assign(property: property)
end
def render(assigns) do
~H"""
<div>Address: <%= @temps.property.address %></div>
<div>Square Feet: <%= @temps.property.square_feet %></div>
<div :for={image <- @temps.property.images}>Image: <img src={image} /></div>
...
"""
end
The above code will store property_id inside the socket assigns map as expected, and property into a temps assigns map that will be reset to %{} after the subsequent render.
After that render, unless the temps assigns map has a key property again, it will just ignore all calls to @temps.property in the ~H code.
If, later, the user calls temp_assign(socket, property: property) again with a new property, then the LV’s engine will see that the property key is available again in the temps assigns map again and re-render it.
Any suggestions and improvements are welcome.
Trending in Proposals: Ideas
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










First 6 of 6 Posts
sodapopcan
There are
temporary_assignswhich was used before streams. Not sure if it will be deprecated or not. I would think not as you can use it for this purpose.sezaru
It is not the same thing,
temporary_assignscan only be set in a LV’smount/3call, you can’t use it inside a live_component or with more modern features likehandle_async, etc.sodapopcan
Ohhhhh fair enough. Ya this would indeed be nice (although I clearly never run into it much).
steffend
This is not correct. In fact
temporary_assignsis exactly what you are proposing hereI’m attaching a single file example that demonstrates temporary assigns both inside a LiveComponent and with handle_async:
Temporary assigns tell LV to reset the value of the assign to the value given in mount and only re-render the parts of the template using the assign when it is assigned again.
sezaru
You are totally correct! I just tested it myself with your code and it worked great, now I feel dumb to not realizing that myself
sodapopcan
Ha, I also am feeling dumb