Deepen your Phoenix LiveView vocabulary — the lifecycle callbacks, socket assigns, and component patterns behind real-time Elixir UIs.
0 / 5 completed
1 / 5
During a code review, a teammate's LiveView crashes on page load. You trace it to mount/3. What is the role of mount/3 in a Phoenix LiveView?
mount/3 receives params, session, and socket; it populates initial assigns. It runs twice: once for the disconnected static render and again when the WebSocket connects.
2 / 5
In a standup, a feature request needs the server to push a JS event to the client (e.g., to trigger an animation). You reach for push_event/3. What does it do?
push_event(socket, name, payload) sends a custom JS event to the client. A JS Hook listening with this.handleEvent(name, fn) receives the payload for client-side side effects.
3 / 5
A PR uses handle_event/3 to process a form submission. In a review, you note the function signature must be:
handle_event/3 takes the event name string, params map, and socket. It returns {:noreply, socket} (most common) or {:reply, payload, socket} for push replies.
4 / 5
During a design discussion, you propose extracting a form into a LiveComponent. A colleague asks how a LiveComponent differs from a functional component. The key difference is:
LiveComponents have lifecycle callbacks (mount, update, handle_event) and isolated assigns, but share the parent LiveView's process — unlike live views which each have their own process.
5 / 5
A teammate's LiveView leaks memory because subscriptions in mount/3 aren't cleaned up. You suggest implementing terminate/2. In LiveView, terminate/2:
terminate/2 is an optional LiveView callback invoked when the process stops (disconnect, redirect, error). Use it to unsubscribe from PubSub topics or release external resources.