phoenix-thinking

Phoenix Thinking

Mental shifts for Phoenix applications. These insights challenge typical web framework patterns.

Where to Load Data: mount vs handle_params

Default: load data in mount/3.

def mount(_params, _session, socket) do
  posts = Blog.list_posts(socket.assigns.current_scope)
  {:ok, assign(socket, posts: posts)}
end

Yes, mount runs twice on initial load (HTTP dead render + WebSocket connect). So does handle_params/3. That's the LiveView lifecycle, not a bug to route around. Moving queries from mount to handle_params does not dedupe them.

Use handle_params/3 for data that changes on live navigation (push_patch / <.link patch={...}>). mount does not re-run on patches, handle_params does.

def handle_params(%{"filter" => filter}, _uri, socket) do
  posts = Blog.list_posts(socket.assigns.current_scope, filter)
  {:noreply, assign(socket, posts: posts, filter: filter)}
end

When the initial double-load actually matters, the real tools are:

• connected?(socket) to gate work to the connected render (loses SEO / no-JS rendering)
• assign_async/3 to load after mount returns, in a separate process
• assign_new/3 to reuse values already set on conn.assigns by upstream Plugs (e.g. :current_user), or shared from a parent LiveView. It does not dedupe arbitrary work across the dead/connected boundary: the function still runs on connected mount.

def mount(_params, _session, socket) do
  posts = if connected?(socket), do: Blog.list_posts(socket.assigns.current_scope), else: []
  {:ok, assign(socket, posts: posts)}
end

Scopes: Security-First Pattern (Phoenix 1.8+)

Scopes address OWASP #1 vulnerability: Broken Access Control. Authorization context is threaded automatically—no more forgetting to scope queries.

def list_posts(%Scope{user: user}) do
  Post |> where(user_id: ^user.id) |> Repo.all()
end

PubSub Topics Must Be Scoped

def subscribe(%Scope{organization: org}) do
  Phoenix.PubSub.subscribe(@pubsub, "posts:org:#{org.id}")
end