Skip to content

Tweak LiveComponent docs #4007

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 30, 2025
Merged

Tweak LiveComponent docs #4007

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 10 additions & 13 deletions lib/phoenix_live_component.ex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ defmodule Phoenix.LiveComponent do
This is a contrast to `Phoenix.Component`, also known as "function components",
which are stateless and do not have a life-cycle.

The smallest LiveComponent only needs to define a `c:render/1` function:
The simplest LiveComponent only needs to define a `c:render/1` function:

defmodule HeroComponent do
# In Phoenix apps, the line is typically: use MyAppWeb, :live_component
Expand All @@ -23,7 +23,7 @@ defmodule Phoenix.LiveComponent do
end
end

A LiveComponent is rendered as:
A LiveComponent is rendered with:

```heex
<.live_component module={HeroComponent} id="hero" content={@content} />
Expand All @@ -34,17 +34,14 @@ defmodule Phoenix.LiveComponent do
component. All other attributes will be available as assigns inside the
LiveComponent.

> #### Functional components or live components? {: .neutral}
> #### Functional components or live components? {: .tip}
>
> Generally speaking, you should prefer function components over live
> components, as they are a simpler abstraction, with a smaller surface
> area. The use case for live components only arises when there is a need
> for encapsulating both event handling and additional state.
> Generally speaking, prefer function components over live components as they
> are a simpler abstraction with a smaller surface area. The use case for
> live components only arises when there is a need to encapsulate both
> event handling and additional state.
>
> Similarly, avoid using LiveComponents for code design purposes, where
> their main goal is to organize code, rather than sharing it across
> LiveViews. When it comes to code organization and design, Elixir developers
> prefer to use functions and data structures.
> Avoid using LiveComponents merely for code organization purposes.

## Life-cycle

Expand Down Expand Up @@ -211,8 +208,8 @@ defmodule Phoenix.LiveComponent do

All of the life-cycle events are summarized in the diagram below.
The bubble events in white are triggers that invoke the component.
In blue you have component callbacks, where the underlined names
represent required callbacks:
In purple are component callbacks; the underlined names
represent required callbacks.

```mermaid
flowchart LR
Expand Down
Loading