Book 5 — LiveView: Real-Time UI Without JS

In Book 4, the request process rendered and exited. LiveView asks: what if it didn't exit? Keep a process alive per browser tab, connect it over a WebSocket, hold UI state in the process, re-render on events, and ship minimal diffs to the DOM. The result: rich, real-time interfaces written entirely in server-side Elixir — and it's all GenServer machinery you already know.

1. The big idea: a GenServer per browser tab

A LiveView is a process (built on GenServer) whose state is your UI state (assigns) and whose "render" is a function of that state. The correspondence is exact:

A complete LiveView:

defmodule CounterLive do
  use Phoenix.LiveView

  def mount(_params, _session, socket) do
    {:ok, assign(socket, count: 0)}
  end

  def handle_event("inc", _params, socket) do
    {:noreply, update(socket, :count, &(&1 + 1))}
  end

  def render(assigns) do
    ~H"""
    <h1>Count: {@count}</h1>
    <button phx-click="inc">+</button>
    """
  end
end

No controller, no API endpoint, no fetch, no client state, no JSON serialization. phx-click="inc" sends an event over the WebSocket; handle_event updates assigns; the changed part of the DOM updates. ~15 lines for a working reactive UI.

Feel it: simulated counter with wire traffic

2. The lifecycle: two mounts, one process

A LiveView page loads in two phases — this trips everyone up once, so let's make it interactive:

Consequences you must know: mount/3 runs twice (once for the SEO-friendly static render over HTTP, once when the socket connects and the real process starts). Guard expensive work with connected?(socket) — subscribe to PubSub and start timers only in the connected mount. If the process crashes, the client automatically reconnects and mount runs again: your supervisor-restart story from Book 2, now with automatic client recovery.

3. Events: phx- bindings

The client side is declarative attributes; the server side is handle_event/3 clauses (pattern matching again):

# The canonical live form — validate as they type, save on submit:
def handle_event("validate", %{"product" => params}, socket) do
  changeset = Product.changeset(%Product{}, params)
  {:noreply, assign(socket, form: to_form(changeset, action: :validate))}
end

def handle_event("create", %{"product" => params}, socket) do
  case Shop.create_product(params) do
    {:ok, _} -> {:noreply, socket |> put_flash(:info, "created!") |> push_navigate(to: "/products")}
    {:error, cs} -> {:noreply, assign(socket, form: to_form(cs))}
  end
end

Note what's absent: no client validation library, no duplicated rules — the same Ecto changeset from Book 4 drives live form errors.

4. Assigns & diff tracking — why it's fast

HEEx templates compile to code that knows exactly which DOM parts depend on which assigns. When @count changes, LiveView doesn't re-render and re-send the page — it sends something like {"3": "42"}: slot 3's new value, a few bytes. The client patches the DOM (morphdom-style, like a server-side virtual DOM where the diffing happened at compile time).

5. Components — composition without a component framework

Function components are stateless partials: a function taking assigns, returning HEEx. Declared attributes are compile-time checked:

attr :label, :string, required: true
attr :count, :integer, default: 0
slot :inner_block

def stat_card(assigns) do
  ~H"""
  <div class="card">
    <h3>{@label}</h3><p>{@count}</p>
    {render_slot(@inner_block)}
  </div>
  """
end

# usage:  <.stat_card label="Users" count={@user_count}>details…</.stat_card>

LiveComponents (use Phoenix.LiveComponent) add per-component state and their own handle_event — for self-contained interactive widgets within a page. Rule of thumb: function components by default; LiveComponent only when a widget needs its own event handling; a separate LiveView when it needs its own process/failure isolation.

6. Real-time fan-out: PubSub + streams

Here's where the whole series converges. Because every browser tab is a process, and processes receive messages (handle_info — Book 2), broadcasting an update to every connected user is trivial:

# In mount (connected only!):
if connected?(socket), do: Phoenix.PubSub.subscribe(MyApp.PubSub, "orders")

# Anywhere in the app (context, background job, another user's LiveView):
Phoenix.PubSub.broadcast(MyApp.PubSub, "orders", {:new_order, order})

# Every subscribed LiveView process gets it as a message:
def handle_info({:new_order, order}, socket) do
  {:noreply, stream_insert(socket, :orders, order, at: 0)}
end

stream_insert belongs to streams — LiveView's tool for large/append-only collections: the server sends only the new/changed item and forgets it (no memory growth per client); the client keeps the DOM. Chat feeds, tables, notification lists — always streams, not list assigns.

Recap

LiveView = GenServer per tab + compile-time-diffed templates + WebSocket transport. mount (twice!), handle_event for user input, handle_info for the rest of the system, assigns as the single source of truth, streams for collections, PubSub for multi-user sync. You now know the entire modern Elixir stack — time to build something whole.