phoenix-pubsub-patterns

Enforce PubSub patterns for Phoenix LiveView subscriptions, broadcasts, and topic naming.

149|15|Updated Jan 23, 2026
One-click install
npx skills add https://github.com/j-morgan6/elixir-phoenix-guide --skill phoenix-pubsub-patterns
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: phoenix-pubsub-patterns
Source: https://github.com/j-morgan6/elixir-phoenix-guide/tree/main/skills/phoenix-pubsub-patterns
Command: npx skills add https://github.com/j-morgan6/elixir-phoenix-guide --skill phoenix-pubsub-patterns

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Phoenix PubSub patterns provide a standardized approach to real-time updates in Phoenix LiveView apps, preventing misbehavior from duplicate subscriptions, misplaced broadcasts, and inconsistent topic handling.

Core Features & Use Cases

  • Guard subscriptions in mount/3 with if connected?(socket) to avoid duplicates during static render
  • Broadcast from contexts, not LiveViews to keep real-time logic in the business layer
  • Use consistent topic naming: "resource:id" for specific resources, "resource:action" for collections
  • Handle PubSub messages in handle_info/2 to treat PubSub messages as process messages, not client events
  • Immutable assigns updates: use update(socket, :items, fn -> ... end) instead of replacing lists
  • Test PubSub by exercising the full cycle via context functions and LiveView updates

Quick Start

Start by subscribing in mount only after connected, and route all broadcasts through your context using well-named topics.

Frequently Asked Questions about phoenix-pubsub-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent duplicate Phoenix PubSub subscriptions in LiveView?

Prevent duplicate Phoenix PubSub subscriptions by guarding the subscription call in your LiveView's mount/3 callback with if connected?(socket), avoiding duplicate subscriptions during static render.

Where should I broadcast PubSub messages in a Phoenix LiveView application?

Broadcast PubSub messages from your business logic contexts, not directly from LiveViews, to keep real-time logic in the business layer and ensure safe, scalable updates.

What is the standard naming convention for Phoenix PubSub topics?

Standard Phoenix PubSub topic naming uses "resource:id" for specific resources and "resource:action" for collections, ensuring consistent topic handling across your application.

How do I handle PubSub messages in Phoenix LiveView?

Handle PubSub messages in the handle_info/2 callback within Phoenix LiveView, treating them as process messages rather than client events, and use immutable assigns updates with update/3.

How do I test Phoenix PubSub broadcasting in LiveView?

Test Phoenix PubSub broadcasting by exercising the full cycle via context functions and verifying LiveView updates, ensuring your real-time subscription and broadcasting logic works correctly.