I’ve been thinking about this a lot over the past few days and was happy to find this question but a bit disappointed in the lack of discussion here. Maybe I’m not looking far enough back through the forum (very possible).

Thank you @Qqwy for making me aware of the Phoenix Phrenzy contest! This is super helpful as I’m just working on my first substantial project in Phoenix with LiveView.

I’ve been working with nested state which is nice with components but then ran into the temporary_assigns issues @mbuhot pointed out. Is anyone aware of any way to achieve this with nested state or it’s just plain impossible right now?

Regardless, I’m likely going to be converting to flat state when I get back to it tonight. My desire to nest was largely due to having a noisy bloated mount/3 and I was able to write a query with preloads to get all my initial state in one call. But then I found this solution in the winning submission to Phoenix Phrenzy which I find compelling: georacer/lib/geo_racer_web/views/race/view_model.ex at 6a54ed21f3a9705da72fc92699a5932b1071f798 · zkayser/georacer · GitHub

Deep diffing shipped many weeks ago

During @chrismccord’s Keynote-talk at ElixirConf.EU V yesterday he told us about the new changes and additions that are happening to LiveView.

One important thing he mentioned, is that there will be better diffing-support for deeply-nested states. Previous versions of the LiveView assigns-diffing would not be able to look deeper into the keys of nested maps (and especially inside structs), meaning that code like this:

<div>
  <span> <%= @post.author %> </span>
  <p> <%= @post.content %> </p>
</div>

would be re-evaluated as a whole every time one of the fields inside assigns.post would change. This is now (in the newest version on master; the latest kinks were ironed out during these last couple of days) no longer the case.

So the tl;dr: Deep states will be much better supported going forward, which means that we as developers have more flexibility in the approach we take.

I’m just learning LiveView through the PragStudio course which is excellent so far.

The temporary_assigns feature makes it feel like the framework is pushing users towards the shallow state style. Can you indicate that a nested map key is a temporary?

I found it difficult to track which assigns are available within the template without some declaration of the data structure, so I’ve adopted a convention of an inner Assigns module within the LiveView module that declares a @type and provides functions for managing the state:

defmodule MyApp.MyViewLive do
  use MyApp, :live_view

  alias MyApp.SomeContext
  alias MyApp.SomeContext.SomeSchema

  defmodule Assigns do
    @type t :: %{
            items: [SomeSchema.t()],
            filter: String.t()
          }

    @spec new([SomeSchema.t()]) :: t()
    def new(initial_data) do
      %{
        items = initial_data
        filter = ""
      }
    end

    def temporaries() do
      [items: []]
    end

    def with_filters(socket, items, filter) do
      socket |> assign(items: items, filter: filter)
    end
  end

  @impl true
  def mount(_params, _session, socket) do
    initial_data = SomeContext.get_some_data()
    socket = assign(socket, Assigns.new(initial_data))
    {:ok, socket, temporary_assigns: Assigns.temporaries()}
  end

  def render(assigns) do
     ~L""" access @items etc here """
  end

  def handle_event("some_event", %{"filter" => filter}, socket) do
    data = SomeContext.get_some_data(filter)
    socket = socket |> Assigns.with_filters(data, filter)
    {:noreply, socket}
  end
end

For the relatively small examples I’ve followed so far, this has been helpful to allow me to treat the Socket.assigns map as a data structure with well defined operations. Looking forward to some more complex examples with Components

Hi everyone! Are there more people who have given this some thought, or am I too early with this discussion?

Let me just ask you, then: In what way do you manage state in your LiveView application?