Is Using Nested LiveComponents and Process Dictionary an Antipattern in LiveView?

user20230119

I’m currently working on a LiveView project where I have a fairly complex UI with nested components. Specifically, I’m using nested LiveComponents to represent hierarchical data structures. Additionally, I’m leveraging the Process Dictionary (Process.put/2 and Process.get/2) to store and retrieve some state, such as the currently selected child entity.

Here’s a simplified example of what I’m doing:

# LiveComponent
~H"""
...
<.button phx-click="select_child" phx-value-id={@entity.id}>Select</.button>
<.button phx-click="link_child" phx-target={@myself} phx-value-path="parent">Link</.button>
...
"""

def handle_event("link_child", %{"links" => path} = params, socket) do
  id = case Process.get(:selected_child) do
    nil -> ""
    child -> child.id
  end

  socket =
    with {:ok, entity} <-
      MyApp.Entity.update_entity_links(socket.assigns.entity,%{path: path |> List.wrap(), value: id})
      do
        socket |> assign(:entity, entity)
    else
      {:error, error} ->
        error |> dbg()
        socket
    end

  {:noreply, socket}
end

# LiveView
def handle_event("select_child", %{"id" => id}, socket) do
  socket =
    with {:ok, child} <- MyApp.Entity.get_entity_by_id(id) do
      Process.put(:selected_child, child)
      socket |> assign(:selected_child, child)
    else
      {:error, error} ->
        error |> dbg()
        socket
    end

  {:noreply, socket}
end

The nested LiveComponents are used to render and manage parts of the UI, and the Process Dictionary is used to share state between different parts of the LiveView. Are there any pitfalls I should be aware of, or alternative approaches you’d recommend?

7 comments

/phoenix #liveview #livecomponents

0 558 7

2025-04-30 19:15:01 UTC

Showing Posts 7 to 1

Show Best Posts
Show All (oldest first)
Show All (newest first)

olivermt

What you want to do is track selected child in parent liveview and send two send_update when it changes.

One that unsets the currently set and one that sets the new.

Post #7

user20230119

I tried passing the selected_child down nested live_components. The problem I had was @selected_child wasn’t used to render anything, but a diff with a blank string for every nested component would still be sent.

<.live_component
  module={MyAppWeb.Entities.IndexLive.EntityComponent}
  id="root"
  entity={@root}
  selected_child={@selected_child}
/>

Post #6

garrison

There is also a more subtle problem here.

If you need to propagate an assign you still have to pass it down through the component tree. Likewise you may want to propagate information via send_update and such. If you mix these things with the process dictionary (as you inevitably would if you take this approach), you could end up observing state changes out of order. In database theory this would be a consistency violation. In reactive programming they call these glitches, for some reason.

I didn’t even know Surface had a Context system (I’ll have to look into it), but I’m curious: does it use the process dictionary? And if so, how does it deal with the above?

Post #5

garrison

A simple answer would be that it’s not idiomatic in LiveView. The comment above points out the change tracking issues.

There are push-based and pull-based reactive systems (really it’s more of a spectrum). LiveView is more on the push side of things - assigns are marked dirty at assign() time and then the dynamics are re-sent in a batch computation. The point being: diffing actually happens when you call assign(), not at render time. In React for example it’s closer to the other way around (though not exactly - they are both somewhere in the middle of the “spectrum”).

If you start storing state outside of the LiveView system you are playing with fire. Technically in the examples from the OP the assigns are not actually used in the template so it should work, but in practice you often want to update your UI based on what item is selected. If you are passing data around via the process dictionary you can no longer propagate information about which assigns are dirty in each render, and the UI will no longer update properly. It’s bad practice to go down this path.

I’m sure there are situations where if you know exactly what you’re doing you could get away with this, but the OP is asking whether it’s an antipattern, and the answer to that is yes, absolutely.

And I know you’re probably aware of this, but for anyone new who’s happening across this thread: we generally try to avoid using the process dictionary in general. It’s an escape hatch which is there for when you really need it.

Post #4

olivermt

You sidestep change tracking.

A lot of research was put into this fof the Context provider in Surface and it still has some foot guns.

If you are ok with reattaching yourself to the change tracking lifecycle this can work, but it feels a little bit like working outside and against the framework instead of with it.

Is the goal to avoid the verbosity of a send/send_update cycle?

Post #3

Schultzer

Why is it a bad idea?

Post #2

garrison

Nesting LiveComponents is fine.

Using the process dictionary like that, though, is a very bad idea. You should pass state down explicitly through assigns. If you need to send information between components you can use send() and send_update().

See “Managing state” in the docs.

Post #1

— All posts loaded —