LiveView Patterns Reference
Reference for building with Phoenix LiveView 1.0/1.1.
Iron Laws — Never Violate These
- •NO DATABASE QUERIES IN DISCONNECTED MOUNT — Queries run TWICE (HTTP + WebSocket). Use
assign_async - •ALWAYS USE STREAMS FOR LISTS — Regular assigns = O(n) memory per user. Streams = O(1)
- •CHECK connected?/1 BEFORE SUBSCRIPTIONS — Prevents double subscriptions
- •EXTRACT VARIABLES BEFORE assign_async CLOSURE — Closures copy entire referenced variables
- •LOAD PRIMARY DATA IN mount/3, PAGINATION IN handle_params/3 — handle_params runs on EVERY URL change
- •NEVER PASS SOCKET TO BUSINESS LOGIC — Extract data before calling contexts
- •CHECK CHANGESET ERRORS BEFORE UI DEBUGGING — Silent form save = check
{:error, changeset}first, not viewport/JS - •HIDDEN INPUTS FOR ALL REQUIRED EMBEDDED FIELDS — Every required field in an embedded schema MUST have a
hidden_inputif not directly editable
Memory Impact
| Pattern | 3K items | 10K users × 10K items |
|---|---|---|
| Regular assigns | ~5.1 MB | ~10+ GB |
| Streams | ~1.1 MB | Minimal (O(1)) |
Decision: Lists with >100 items → Use streams, not assigns
Quick Patterns
Async Assigns (CRITICAL)
elixir
def mount(%{"slug" => slug}, _session, socket) do
# Extract needed values BEFORE the closure
scope = socket.assigns.current_scope
{:ok,
socket
|> assign_async(:org, fn -> {:ok, %{org: fetch_org(scope, slug)}} end)}
end
Streams for Lists
elixir
def mount(_params, _session, socket) do
{:ok, stream(socket, :items, Items.list_items())}
end
# Insert/update/delete
stream_insert(socket, :items, item, at: 0)
stream_delete(socket, :items, item)
PubSub with connected? check
elixir
def mount(_params, _session, socket) do
if connected?(socket), do: Chat.subscribe(room_id)
{:ok, socket}
end
Navigation Decision Tree
code
Same LiveView, different params? → patch / push_patch Different LiveView, same live_session? → navigate / push_navigate Different live_session or non-LiveView? → href / redirect
Component Decision Tree
code
Does component need BOTH internal state AND event handling? │ ├── YES → Does it encapsulate APPLICATION logic (not just DOM)? │ ├── YES → Use LiveComponent ✅ │ └── NO → Refactor to function component with parent handling │ └── NO → Use Function Component ✅
Official guidance: "Prefer function components over live components"
Common Anti-patterns
| Wrong | Right |
|---|---|
DB queries without assign_async | Use assign_async for all queries |
assign(socket, items: list) for lists | stream(socket, :items, list) |
PubSub subscribe without connected? | if connected?(socket), do: subscribe() |
| Passing socket to context functions | Extract socket.assigns first |
Business logic in handle_event | Delegate to context |
References
For detailed patterns, see:
- •
references/async-streams.md- assign_async, stream_async, streams - •
references/forms-uploads.md- Forms, validation, file uploads - •
references/components.md- Function components, LiveComponents - •
references/pubsub-navigation.md- PubSub, navigation, JS commands - •
references/js-interop.md- Third-party JS libraries, phx-update="ignore", hooks - •
references/channels-presence.md- Phoenix Channels, Presence, token auth