anagrius

anagrius

Hey,

I try to keep my application state free of derived state. So I don’t for instance have:

{a: 1, b: 2, sum: 3}

But rather compute the derived state when I need it.
In liveview applications you often need derived state while rendering HTML, and it natural to do the calculation once and store the derived state in assigns so it can be used with the @-notation:

<div><%= @sum %></div>

The alternative is of course:

<div><%= @a + @b %></div>

in this trivial example, but often it is much more complex calculations involving many inputs, and these have to be passed to the calculation function:

<div><%= calculate_derived_state(@a, @b, @settings.displayFormat, @x, @y, @z) %></div>

Again fine if it is used once or twice.

Reassigning assigns in function components is allowed which means I can do:

def some_component(assigns) do
    assigns = assign(assigns, :sum, assigns.a + assigns.b)
    ~H"""
    <div><%= @sum %>
    """
end

But this is not allowed in the top-level render function of a liveview or live-component.

So, my question: Why would I not just do:

def render(assigns) do
    ~H"""
    <.render_inner {assigns} />
    """
end

def render_inner(assigns) do
      assigns = assign(assigns, :sum, assigns.a + assigns.b)
     ~H"""
      <div><%= @sum %></div>
     """
end

I understand that sum is calculated each render, but that is a small cost to avoid managing stale derived state.

Is there some hidden cost I don’t see? Doe passing {assigns} to render_inner for instance for the rendering of the entire view-tree or something.
I understand that render_inner must be recalculated on each render - but that should be equivalent to what render would do anyway.

Showing Posts 1 to 4

sodapopcan

sodapopcan

Citation needed for this one! Maybe this is a new thing as my project is not using 1.0 yet but this is the first I’ve heard of this! I could be wrong.

Putting the raw assigns variable directly in a template means that you won’t get the benefit of change-tracking. This effects what get sent back over the wire, so you will end up with really inefficient diffs.

steffend

steffend

Phoenix Core Team

You’re not wrong. Using the assign function in the render function of a LV or LC is perfectly valid.

anagrius

anagrius OP

Unlike LiveView’s render/1 callback, a function component can modify the assigns it receives via the assign/2 , assign/3 , assign_new/3 , and update/3 functions. Therefore, you can assign the computed values before declaring your template.

Maybe it is just outdated? Since it works perfectly well in render/1. It also says you “can’t” which you can, not that you shouldn’t.

sodapopcan

sodapopcan

Oh right you are. Should probably report that as it’s quite confusing, especially when it does indeed say “can’t” when you clearly can. I’ve been doing this for years at this point, though, lol. Only once in a while, but never thought too much about it.

— All posts loaded —

Where Next? Top

Trending in Questions Top

RSP87
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
nseaSeb
Hello, I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
kpanic
Hi everyone, I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding. I sta...
New
brecabral
Documentation While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
asweet-confluent
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
apz
I’m new to elixir and just tried to install the elixirLS extension for VScode(ium) and it is throwing some errors that I would like help ...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
georgeguimaraes
Just published claude-code-elixir, a plugin marketplace for Claude Code with Elixir support. These are the plugins I’ve been using for my...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews