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.