DEV Community: Karol Słuszniak

LiveView Assigns: Three Common Pitfalls and Their Solutions

Karol Słuszniak — Wed, 06 Jul 2022 12:56:01 +0000

In the first part of this two-part series, we examined LiveView assigns in detail — demystifying assigns, looking at some key concepts, and debugging.

Now, we'll turn our attention to three common mistakes that you might make with assigns and how to avoid them.

Let's get started!

1. Evaluating All LiveView Assigns

As you pass assigns around to view helpers, and the complexity increases, you may need many assigns in some functions. For example:

<%= user_note(@user, @note, @theme, @locale) %>

Then you may be tempted to do the following instead:

<%= user_note(assigns) %>

The problem with this simplification is that it’ll completely ruin change tracking and, as a result, changing any assign will trigger an update.

To solve this, stick to passing only the required assigns explicitly and collapse multiple arguments into a keyword list if needed:

<%= user_note(@user, @note, theme: @theme, locale: @locale) %>

Note: LiveView itself hints at, and counters this problem by excluding all other assigns from the widely used @socket struct in which they’re generally stored. But it does not forbid you from reaching for the assigns directly, opening a door to this issue.

2. Re-rendering Entire Lists

Change tracking on nested data such as lists is a complex problem, regardless of the framework. LiveView goes the extra mile to represent for loops via a dedicated struct so that static parts are only sent once. But when it comes to assigns, it tracks all that appear in such loops as a whole.

Our generated live resource in the 'Caveman Debugging in LiveView' section of the first part of this series re-evaluated every table row and cell regardless of what we did with the @notes assign.

There’s a solution though. We can establish a separate tracking context using stateful live components. So let’s try it out and create a component for each note:

defmodule MyAppWeb.NotesLive.Index.NoteRow do
  use MyAppWeb, :live_component
  def render(assigns) do
    ~H"""
    <tr id={"note-#{@note.id}"}>
      <td><%= inspect(Time.utc_now()) %></td>
      <td><%= inspect({Time.utc_now(), @note.name}) %></td>
      <td><%= inspect({Time.utc_now(), @note.content}) %></td>
      <!-- ACTIONS (CUT) -->
    </tr>
    """
  end
end

Then render it within the table:

<table>
  <!-- TABLE HEADER (CUT) -->
  <tbody id="notes">
    <%= for note <- @notes do %> <.live_component module={__MODULE__.NoteRow}
    id={"note-row-#{note.id}"} note={note} /> <% end %>
  </tbody>
</table>

Now you may once again create, edit, and delete some notes for the following highly desired behavior:

When creating, only the newly added row gets updated.
When editing, only the cells for changed fields get updated.
When deleting, no other rows get updated.

Note: You should not have to worry about memory usage caused by copying assigns to live components. They reside on the same process as the parent view, and so should share immutable data.

The excellent article Optimising data-over-the-wire in Phoenix LiveView compared Websocket payload for the naive loop vs. the component-based version. Note, however, that it may not reflect the current state of affairs as these things are rapidly evolving — see the Phoenix LiveView changelog.

3. Growing LiveView Assigns Infinitely

As noted in the 'LiveView Assigns Manage State' part of the previous post, the server-side nature of LiveView places extra responsibilities on memory management. For that reason, you can't afford to grow lists infinitely, e.g., when paginating, as shown below:

defmodule MyAppWeb.NotesLive do
  def render(assigns) do
    ~H"""
    <div id="notes">
      <%= for note <- @notes do %>
        <div id={"note-#{note.id}"}>
          <!-- CUT (note) -->
        </div>
      <% end %>
    </div>
    <button phx-click="load_more">Load more</button>
    """
  end
  def handle_event("load_more", _, socket) do
    next_page = socket.assigns.last_page + 1
    more_notes = Notes.list_notes(page: next_page)
    {:noreply, assign(socket,
      notes: socket.assigns.notes ++ more_notes,
      last_page: next_page
    )}
  end
end

Here, the memory usage will grow linearly, not just with the number of users (which is a problem we definitely don't want to have) but also with the total number of notes.

The solution is to mark that assign as temporary, switch to the append update model for the note listing, and only assign new items:

defmodule MyAppWeb.NotesLive do
  def mount(params, session, socket) do
    # ...
    {:ok, socket, temporary_assigns: [notes: []]}
  end
  def render(assigns) do
    ~H"""
    <div id="notes" phx-update="append">
      <!-- CUT (notes loop) -->
    </div>
    """
  end
  def handle_event("load_more", _, socket) do
    next_page = socket.assigns.last_page + 1
    more_notes = Notes.list_notes(page: next_page)
    {:noreply, assign(socket,
      notes: more_notes,
      last_page: next_page
    )}
  end
end

Now the notes list will still accumulate newly loaded records while keeping memory usage under control.

Wrap Up

In the first part of this series, we spent some time diving into LiveView assigns. First, we demystified assigns, before embarking on some caveman debugging and socket inspection.

In this article, we examined three common pitfalls — evaluating all assigns, re-rendering entire lists, and growing assigns infinitely — and their solutions.

I hope that this series has given you an idea of some trade-offs that come with LiveView assigns, alongside ways to get the most out of the wonderful technology that Phoenix LiveView definitely is.

Happy assigning!

A note from AppSignal: We're very excited to have recently released AppSignal for Phoenix 2.1, which adds automatic instrumentation for LiveView through Telemetry.

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

A Guide to Phoenix LiveView Assigns

Karol Słuszniak — Tue, 21 Jun 2022 11:35:21 +0000

Phoenix LiveView lets you develop full-stack apps with client-side interactions while mostly avoiding cross-stack hassle. Assigns, managed by the LiveView socket, are a core tool for making that happen — allowing you to store, present, and update data effortlessly and efficiently. But as they do so much, assigns come with their own complexities and may backfire if misused.

Over the last three years, I've had the pleasure to work on multiple LiveView apps within multiple teams, so I know first-hand that assigns can feel like magic to many developers (myself included).

In this article, we're going to demystify LiveView assigns. We'll describe what LiveView assigns actually are in relation to popular frameworks, find out how assigns work in practice, and highlight some of the traps that one may easily fall into.

Note: Throughout this post, we're going to use assigns to refer to LiveView assigns — as opposed to EEx assigns, Plug assigns, or Phoenix Socket assigns.

Demystifying Phoenix LiveView Assigns

Let's start with an overview of what assigns actually are. Here's a basic example:

defmodule MyAppWeb.StatsLive do
  use MyAppWeb, :live_view
  alias MyApp.{Accounts, Notes}

  def mount(params, session, socket) do
    {:ok, assign(socket,
      note_count: Notes.get_note_count(),
      user_count: Accounts.get_user_count()
    )}
  end

  def render(assigns) do
    ~H"""
    Note count: <%= @note_count %>
    User count: <%= @user_count %>
    """
  end
end

The above snippet shows how @note_count and @user_count are assigned initial values and then rendered as dynamic fragments among the static HTML that surrounds them. That's the concept of LiveView assigns in a nutshell.

Now let's take a deeper look, pointing out some similarities and differences between assigns and mainstream front-end development.

Let's get going!

LiveView Assigns Provide Dynamic Input

Assigns in LiveView build on top of those used by EEx as well as from "traditional" Phoenix. They are just input variables — placeholders for dynamic data provided from the outside.

Run the following code from iex:

iex> EEx.eval_string("Hello, <%= @name %>!", assigns: [name: "John"])
"Hello, John!"

We can easily compare assigns to props from React, Vue, or any other web component library. This is especially true for stateless components that have recently switched to simple function syntax, like functional components in React. Consider this simple component:

defmodule MyAppWeb.MyComponents do
  def my_button(assigns = %{text: _, click: _}) do
    ~H"""
    <button class="some-class" phx-click={@click}>
      <%= @text %>
    </button>
    """
  end
end

You can surely imagine yourself rewriting it in any web component library with a very similar code structure and volume. For the record, here's how similar it'd be in React:

function MyButton({ text, click }) {
  return (
    <button class="some-class" onClick={click}>
      {text}
    </button>
  );
}

The component uses assigned input wherever it needs to, while the caller of my_button provides it like this:

<.my_button text="Click me!" click="some_event" />

Easy enough, and no room for dilemmas. But that's just the start.

LiveView Assigns Manage State

For live views and live components, assigns grow from being a dumb input into a long-lived state. As such, they derive from Phoenix Channel assigns, and shift from props into state in the React nomenclature.

Views and components may opt to update their assigns from the inside to evolve their state. This is nothing fancy on its own, so — just like with props — we can easily find an equivalent in any web component framework.

What is fancy, however, is that in LiveView this happens on the server — taking advantage of Erlang processes to deliver low latency at scale.

To understand why this is great, let's take a look at the following example:

defmodule MyAppWeb.UserSubscriptionLive do
  use MyAppWeb, :live_view

  # ...

  def handle_event("pick_subscription", params, socket) do
    # encrypted session
    %{assigns: %{current_user: user}} = socket

    # CSRF-protected user input
    %{"plan" => plan} = params

    # ACID-safe database
    subscription = Subscriptions.create_subscription(user, plan)

    # non-public, secure APIs
    Payments.charge_user(user, subscription)

    # server-only background jobs
    Mailing.send_subscription_created_email(user, subscription)

    {:noreply, assign(socket, subscription: subscription})
  end
end

Without any effort, we mix data from the session, user input, databases, APIs, background jobs, and PubSubs — in one place, untampered, and server-side rendered. Presenting the results is just as simple:

<%= unless @subscription do %>
  Pick your plan:

  <a href="#" phx-click="pick_subscription" phx-value-plan="basic">Basic ($4.99)</a>
  <a href="#" phx-click="pick_subscription" phx-value-plan="premium">Premium ($19.99)</a>
<% else %>
  You're currently subscribed to <%= format_plan(@subscription.plan) %> plan.

  <%= if @subscription.last_payment do %>
    You were last charged on <%= DateTime.to_date(@subscription.last_payment.inserted_at) %>.
  <% end %>
<% end %>

Imagine all the moving parts that it would take to produce and fully test the client-side equivalent of our @subscription assign. This is perhaps the biggest highlight of LiveView, stealing the spotlight from API layers, state managers, sagas, and browser-based test suites.

At the same time, state management is undoubtedly a challenging task, and keeping memory usage under control is one of our main concerns. This is especially true considering we're on the server, and all connected users will claim the memory needed to hold the assigns during their entire session.

We'll examine a specific use case along with its solution in a moment.

LiveView Assigns Fuel Change Tracking

If you think that assigns are "just" props and state, and the show is over, brace yourself.

You see, if you update a single React prop or piece of React state, the whole component will re-render. But LiveView assigns are different. The reason for this is HEEx — a templating engine that splits your template into static and dynamic parts, and then only re-evaluates dynamic parts to involve the changed assigns.

Since this happens on the server, it's only the actual changes that will ever take up bandwidth, saving you the effort needed to slim down JSON payloads in classic SPAs, e.g., by designing case-specific or flexible APIs. That's some cool out-of-the-box optimization.

Note: This feature is known by different names, including change tracking, reactivity, memoization, or observability. The approach towards it varies across JS frameworks — check out the above keywords regarding Angular, Ember, Knockout, or Svelte.

In React, we can achieve similar behavior in a more explicit way (so it'll serve as a great visual exercise) with useMemo. Consider the following live component:

defmodule MyAppWeb.UserHoroscope do
  use MyAppWeb, :live_component

  def render(assigns) do
    ~H"""
    <div>
      <strong>Horoscope for {format_full_name(@first_name, @last_name)} (born on {format_date(@birthday)}):</strong>
      {generate_horoscope(@birthday)}
    </div>
    """
  end
end

Out of the box, it will only call format_date or get_horoscope when @birthday changes, but not when either @first_name or @last_name do (which may be extra useful if our generator that powers the horoscope becomes complex and the user name changes). The same goes for the other <%= ... %> snippets.

With React, we start off with the following naive component that runs all helper functions, regardless of changes:

function UserHoroscope({ firstName, lastName, birthday }) {
  return (
    <div>
      <strong>
        Horoscope for {formatFullName(firstName, lastName)} (born on{" "}
        {formatDate(birthday)}):
      </strong>
      {getHoroscope(birthday)}
    </div>
  );
}

Then, we'd extend it into the following shape with useMemo so that each helper is called only when its dependencies change:

function UserHoroscope({ firstName, lastName, birthday }) {
  const fullName = useMemo(() => {
    return formatFullName(firstName, lastName);
  }, [firstName, lastName]);

  const formattedBirthday = useMemo(() => {
    return formatDate(birthday);
  }, [birthday]);

  const horoscope = useMemo(() => {
    return generateHoroscope(birthday);
  }, [birthday]);

  return (
    <div>
      <strong>
        Horoscope for {fullName} (born on {formattedBirthday}):
      </strong>
      {horoscope}
    </div>
  );
}

Note: We're not saying React is the worst here. React focuses on optimizing historically slow DOM patching while assuming that modern JS is fast enough to re-evaluate typical rendering logic (ideal for a client-side library). LiveView goes the extra mile to save on server resources and bandwidth without sacrificing the dev experience — which works well for a compiler-backed server-side library.

Overall, change tracking is a powerful feature that does some really useful stuff under the hood while keeping our code clean. But it may also raise some ambiguity and doubts as far as assigns are concerned, and, if used without care, change tracking can definitely backfire performance-wise.

Taking LiveView Assigns for a Spin

Now that we know multiple concepts are mixed in with assigns, we see how they may actually not be as simple as they look in the code.

LiveView docs have a dedicated assigns and HEEx guide, so that's the first place you should look for answers and pointers. The module page for the template engine gives some extra insight.

But, sooner or later (and I'd put my bets on sooner considering the early stage of LiveView), that isn't enough. Let's look at how to approach LiveView to:

Play with it and boost your confidence
Debug and fix suspicious behavior in a real app
Check for optimizations or regressions in new LiveView releases

Caveman Debugging in LiveView

The first technique that you may want to employ involves returning to the very roots of debugging. You'll use a battle-proven, highly sophisticated technique that's been hiding in the darkest corners of the internet under numerous inspiring names like 'caveman debugging'.

The idea is to rely on the fact that HEEx only re-evaluates a subset of code blocks and to output a timestamp as close as possible to the place you want to inspect in the template.

To try it out, generate a sample live resource for testing in your Phoenix 1.6 app:

mix phx.gen.live Notes Note notes name:string content:text

Apply the printed instructions and navigate to /notes. Then add the following inspect/1 calls to your index.html.heex:

<%= inspect({Time.utc_now(), :above_notes}) %>
<table>
  <!-- CUT (table header) -->
  <tbody id="notes">
    <%= for note <- @notes do %>
      <tr id={"note-#{note.id}"}>
        <td><%= inspect(Time.utc_now()) %></td>
        <td><%= inspect({Time.utc_now(), note.name}) %></td>
        <td><%= inspect({Time.utc_now(), note.content}) %></td>
        <!-- CUT (actions cell) -->
      </tr>
    <% end %>
  </tbody>
</table>

Now try adding and removing some notes. In the default generated live resource, you should notice that the :above_notes timestamp updates together with all the per-row ones when creating or editing notes, but not when deleting them.

This hints that something different is happening with the live view and its assigns for the delete case. And rightfully so. When you look at the code, FormComponent uses push_redirect/2 upon a save, causing the whole index to reload, while Index uses assign/2,3 upon deletion to only update that specific assign.

If you want to avoid the reload, it's as simple as replacing push_redirect/2 in FormComponent with push_patch/2, plus reloading the @notes assign in Index like this:

defp apply_action(socket, :index, _params) do
  socket
  |> assign(:page_title, "Listing Notes")
  |> assign(:notes, list_notes())
  |> assign(:note, nil)
end

Voilà: your first performance tweak!

You may also have noticed that all per-row timestamps re-render when you create, edit, and delete notes — regardless of whether a specific note is affected or not. We'll get back to this later.

Socket Inspection

Sometimes, it's useful to see what LiveView pushes down the wire. This isn't so easy to visually tie to specific places on the page. But it allows us to inspect what is getting updated, and when, without template changes, and — this is especially useful — to see payload size and structure.

In order to inspect a socket:

Visit your live view in Chrome.
Open Developer Tools.
Switch to the Network tab.
Optionally filter by the WS type.
Choose the websocket?_csrf_token=... name.
Switch to the Messages tab.
Choose the message that you're interested in.

Here's how it might look:

When working with two notes, the highlighted piece of inbound payload is responsible for filling the listing. This confirms that the entire listing is re-rendered, regardless of operation.

Note: You may find it more handy to ask LiveView's JS client to log updates to the console, by calling liveSocket.enableDebug() in it.

In the end, having insight into the raw payload can lead you to some case-specific optimizations, such as:

Restructuring the assigns (e.g., by breaking apart large or nested ones)
Using live components (to ensure some assigns are tracked separately)
Sending some data to JavaScript hooks as binary (by switching to Phoenix.Channel)

Debugging in Production with AppSignal

The caveman technique is great for a single developer working on an application that hasn't been pushed to production. However, if you have an app in production with live users, you may want to take a look at AppSignal for monitoring your application performance and checking for errors in production.

Adding AppSignal to an existing application takes a few seconds, and you can track LiveView errors from there.

Here's an example of the AppSignal dashboard collecting data from a sample application:

Wrap Up

In this post, we started off by demystifying LiveView assigns, before touching on some cross-over between assigns and mainstream front-end development. Finally, we explored caveman debugging in LiveView and socket inspection.

LiveView combines a lot of functionality in assigns, including some that's just as clever and useful as it is implicit and complex.

The key is to get a grasp on the key concepts, which are all relatable to what we can find in client-side frameworks. And, considering the framework's young age, to have a fallback solution for when existing resources can't help — a way to dig into it on your own.

Next up in this two-part series, we'll look at some common pitfalls when it comes to LiveView assigns.

Until then, happy coding!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!