Phoenix Liveview logo

Phoenix Liveview

Community
bobmatnyc
phoenix-liveview

Phoenix Framework with LiveView on the BEAM

Overview

Publisherbobmatnyc
Repositoryclaude-mpm-skills
Skill namephoenix-liveview
Stars
75
Forks
19
Bundled files
1
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 1 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by bobmatnyc on GitHub. Read the source before you install it.

Installation

Install the Phoenix Liveview AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/bobmatnyc/claude-mpm-skills.git /tmp/claude-mpm-skills
mkdir -p .claude/skills
cp -r /tmp/claude-mpm-skills/toolchains/elixir/frameworks/phoenix-liveview .claude/skills/phoenix-liveview
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Phoenix Liveview in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Phoenix Liveview on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Phoenix Liveview is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Phoenix + LiveView (Elixir/BEAM)

Phoenix builds on Elixir and the BEAM VM to deliver fault-tolerant, real-time web applications with minimal JavaScript. LiveView keeps UI state on the server while streaming HTML diffs over WebSockets. The BEAM provides lightweight processes, supervision trees, hot code upgrades, and soft-realtime scheduling.

Key ideas

  • OTP supervision keeps web, data, and background processes isolated and restartable.
  • Contexts encode domain boundaries (e.g., Accounts, Billing) around Ecto schemas and queries.
  • LiveView renders HTML on the server, syncing UI state over WebSockets with minimal client code.
  • PubSub + Presence enable fan-out updates, tracking, and collaboration features.

Environment and Project Setup

bash
# Erlang + Elixir via asdf (recommended)
asdf install erlang 27.0
asdf install elixir 1.17.3
asdf global erlang 27.0 elixir 1.17.3

# Install Phoenix generator
mix archive.install hex phx_new

# Create project with LiveView + Ecto + esbuild
mix phx.new my_app --live
cd my_app
mix deps.get
mix ecto.create
mix phx.server

Project layout (key pieces):

  • lib/my_app/application.ex — OTP supervision tree (Repo, Endpoint, Telemetry, PubSub, Oban, etc.)
  • lib/my_app_web/endpoint.ex — Endpoint, plugs, sockets, LiveView config
  • lib/my_app_web/router.ex — Pipelines, scopes, routes, LiveSessions
  • lib/my_app/ — Contexts (domain modules) and Ecto schemas
  • test/support/{conn_case,data_case}.ex — Testing helpers for Ecto + Phoenix

BEAM + OTP Essentials

Supervision tree (application.ex): keep short, isolated children.

elixir
def start(_type, _args) do
  children = [
    MyApp.Repo,
    {Phoenix.PubSub, name: MyApp.PubSub},
    MyAppWeb.Endpoint,
    {Oban, Application.fetch_env!(:my_app, Oban)},
    MyApp.Metrics
  ]

  Supervisor.start_link(children, strategy: :one_for_one, name: MyApp.Supervisor)
end

GenServer pattern: wrap stateful services.

elixir
defmodule MyApp.Counter do
  use GenServer

  def start_link(initial \\ 0), do: GenServer.start_link(__MODULE__, initial, name: __MODULE__)
  def increment(), do: GenServer.call(__MODULE__, :inc)

  @impl true
  def handle_call(:inc, _from, state) do
    new_state = state + 1
    {:reply, new_state, new_state}
  end
end

BEAM principles

  • Prefer many small processes; processes are cheap and isolated.
  • Supervise everything with clear restart strategies.
  • Use message passing (GenServer.cast/send) to avoid shared state.
  • Use ETS/Cachex for in-memory caches; keep them supervised.

Phoenix Anatomy and Routing

Pipelines and scopes (router.ex): keep browser/api concerns separated.

elixir
defmodule MyAppWeb.Router do
  use MyAppWeb, :router

  pipeline :browser do
    plug :accepts, ["html"]
    plug :fetch_session
    plug :fetch_live_flash
    plug :protect_from_forgery
    plug :put_secure_browser_headers
    plug :fetch_current_user
  end

  pipeline :api do
    plug :accepts, ["json"]
  end

  scope "/", MyAppWeb do
    pipe_through :browser
    live "/", HomeLive
    resources "/users", UserController
  end

  scope "/api", MyAppWeb do
    pipe_through :api
    resources "/users", Api.UserController, except: [:new, :edit]
  end
end

Plugs: composable request middleware. Keep plugs pure and short; prefer pipeline plugs over controller plugs when cross-cutting.


Contexts and Ecto

Schema + changeset

elixir
defmodule MyApp.Accounts.User do
  use Ecto.Schema
  import Ecto.Changeset

  schema "users" do
    field :email, :string
    field :hashed_password, :string
    field :confirmed_at, :naive_datetime
    timestamps()
  end

  def registration_changeset(user, attrs) do
    user
    |> cast(attrs, [:email, :password])
    |> validate_required([:email, :password])
    |> validate_format(:email, ~r/@/)
    |> validate_length(:password, min: 12)
    |> unique_constraint(:email)
    |> put_password_hash()
  end

  defp put_password_hash(%{valid?: true} = changeset),
    do: put_change(changeset, :hashed_password, Argon2.hash_pwd_salt(get_change(changeset, :password)))
  defp put_password_hash(changeset), do: changeset
end

Context API

elixir
defmodule MyApp.Accounts do
  import Ecto.Query, warn: false
  alias MyApp.{Repo, Accounts.User}

  def list_users, do: Repo.all(User)
  def get_user!(id), do: Repo.get!(User, id)

  def register_user(attrs) do
    %User{}
    |> User.registration_changeset(attrs)
    |> Repo.insert()
  end
end

Transactions with Ecto.Multi

elixir
alias Ecto.Multi

def register_and_welcome(attrs) do
  Multi.new()
  |> Multi.insert(:user, User.registration_changeset(%User{}, attrs))
  |> Multi.run(:welcome_email, fn _repo, %{user: user} ->
    MyApp.Mailer.deliver_welcome(user)
    {:ok, :sent}
  end)
  |> Repo.transaction()
end

LiveView Patterns

LiveView module (stateful UI on server)

elixir
defmodule MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

  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"""
    <div class="space-y-4">
      <p class="text-lg">Count: <%= @count %></p>
      <button phx-click="inc" class="btn">Increment</button>
    </div>
    """
  end
end

HEEx tips

  • Prefer assign_new/3 to lazily compute expensive data only once per connected session.
  • Use stream/3 for large lists to minimize diff payloads.
  • Handle params in handle_params/3 for URL-driven state; avoid storing socket state in params.

Live Components

elixir
defmodule MyAppWeb.NavComponent do
  use MyAppWeb, :live_component
  def render(assigns) do
    ~H"""
    <nav>
      <%= for item <- @items do %>
        <.link navigate={item.href}><%= item.label %></.link>
      <% end %>
    </nav>
    """
  end
end

PubSub-driven LiveView

elixir
@impl true
def mount(_params, _session, socket) do
  if connected?(socket), do: Phoenix.PubSub.subscribe(MyApp.PubSub, "orders")
  {:ok, assign(socket, orders: [])}
end

@impl true
def handle_info({:order_created, order}, socket) do
  {:noreply, update(socket, :orders, fn orders -> [order | orders] end)}
end

PubSub, Channels, and Presence

Broadcast changes from contexts

elixir
def create_order(attrs) do
  with {:ok, order} <- %Order{} |> Order.changeset(attrs) |> Repo.insert() do
    Phoenix.PubSub.broadcast(MyApp.PubSub, "orders", {:order_created, order})
    {:ok, order}
  end
end

Presence for online/typing indicators

elixir
defmodule MyAppWeb.RoomChannel do
  use Phoenix.Channel
  alias Phoenix.Presence

  def join("room:" <> room_id, _payload, socket) do
    send(self(), :after_join)
    {:ok, assign(socket, :room_id, room_id)}
  end

  def handle_info(:after_join, socket) do
    Presence.track(socket, socket.assigns.user_id, %{online_at: System.system_time(:second)})
    push(socket, "presence_state", Presence.list(socket))
    {:noreply, socket}
  end
end

Security: authorize topics in join/3, verify user tokens in params/session, and limit payload size.


Testing Phoenix + LiveView

Use mix test with the generated helpers.

elixir
# test/support/conn_case.ex
use MyAppWeb.ConnCase, async: true

test "renders home", %{conn: conn} do
  conn = get(conn, "/")
  assert html_response(conn, 200) =~ "Welcome"
end
elixir
# LiveView test
use MyAppWeb.ConnCase, async: true
import Phoenix.LiveViewTest

test "counter increments", %{conn: conn} do
  {:ok, view, _html} = live(conn, "/counter")
  view |> element("button", "Increment") |> render_click()
  assert render(view) =~ "Count: 1"
end

DataCase: provide sandboxed DB connections; wrap tests in transactions to isolate data.

Fixtures: build factories with ExMachina or simple helper modules under test/support/fixtures.


Performance, Ops, and Deployment

  • Telemetry: Phoenix exposes events ([:phoenix, :endpoint, ...]). Export via :telemetry_poller, OpentelemetryPhoenix, and OpentelemetryEcto.
  • Assets: mix assets.deploy runs npm install, esbuild, tailwind (if configured), and digests.
  • Releases: MIX_ENV=prod mix release. Configure runtime env in config/runtime.exs. Start with PHX_SERVER=true _build/prod/rel/my_app/bin/my_app start.
  • Clustering: add libcluster with DNS/epmd strategy for horizontal scale; use distributed PubSub/Presence.
  • Caching: use ETS/Cachex for hot paths; prefer short TTLs and invalidate on write.
  • Background jobs: Oban for retries/backoff; supervise it in application tree.
  • Hot path checks: enable :telemetry metrics, check LiveView diff sizes, avoid large assigns; prefer streams.

Common Pitfalls

  • Forgetting to subscribe LiveViews to PubSub after connected?/1 check — events will be missed on initial render.
  • Doing heavy work inside LiveView render; move to contexts and precompute assigns.
  • Not using Ecto.Multi for multi-step writes; failures leave partial state.
  • Blocking BEAM schedulers with long NIFs or heavy CPU work; offload to ports/Oban jobs.
  • Overusing global ETS without supervision or limits; leak memory.

Reference Commands

  • mix phx.routes — list routes and LiveView paths.
  • mix phx.gen.live Accounts User users email:string confirmed_at:naive_datetime — generate LiveView CRUD (review context boundaries afterward).
  • mix format && mix credo --strict — formatting and linting.
  • mix test --seed 0 --max-failures 1 — deterministic failures; pair with mix test.watch.

Phoenix + LiveView excels when domain logic stays in contexts, LiveViews stay thin, and the BEAM supervises every component for resilience.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Phoenix Liveview AI skill do?

Phoenix Framework with LiveView on the BEAM

Why use Phoenix Liveview on TypingMind?

Because you install it once and use it with any model. Phoenix Liveview is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Phoenix Liveview in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/bobmatnyc/claude-mpm-skills/tree/main/toolchains/elixir/frameworks/phoenix-liveview. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Phoenix Liveview?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Phoenix Liveview?

As many as you like. As long as a model supports skills, you can use Phoenix Liveview with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Phoenix Liveview AI skill free?

Yes. It is published on GitHub by bobmatnyc under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇