phoenix_live_view v0.5.0 Phoenix.LiveView.Helpers View Source
A collection of helpers to be imported into your views.
Link to this section Summary
Functions
Renders a Phoenix.LiveComponent
within a parent LiveView.
Generates a live link for HTML5 pushState based navigation without page reloads.
Renders a LiveView within an originating plug request or within a parent LiveView.
Provides ~L
sigil with HTML safe Live EEx syntax inside source files.
Link to this section Functions
live_component(socket, component, assigns \\ [], do_block \\ [])
View Source (macro)Renders a Phoenix.LiveComponent
within a parent LiveView.
While LiveView
s can be nested, each LiveView starts its
own process. A LiveComponent provides similar functionality
to LiveView, except they run in the same process as the
LiveView
, with its own encapsulated state.
LiveComponent comes in two shapes, stateful and stateless.
See Phoenix.LiveComponent
for more information.
Examples
All of the assigns
given are forwarded directly to the
live_component
:
<%= live_component(@socket, MyApp.WeatherComponent, id: "thermostat", city: "Kraków") %>
Note the :id
won't necessarily be used as the DOM ID.
That's up to the component. However, note the :id
has
a special meaning: whenever an :id
is given, the component
becomes stateful. Otherwise, :id
is always set to nil
.
Generates a live link for HTML5 pushState based navigation without page reloads.
Options
:to
- the required path to link to.:replace
- the flag to replace the current history or push a new state. Defaultsfalse
.
All other options are forwarded to the anchor tag.
Examples
<%= live_link "next", to: Routes.live_path(@socket, MyLive, @page + 1) %>
<%= live_link to: Routes.live_path(@socket, MyLive, dir: :asc), replace: false do %>
Sort By Price
<% end %>
Renders a LiveView within an originating plug request or within a parent LiveView.
Options
:session
- the map of extra session data to be serialized and sent to the client. Note all session data currently in the connection is automatically available in LiveViews. You can use this option to provide extra data. Also note the keys in the session are strings keys, as a reminder that data has to be serialized first.:container
- the optional tuple for the HTML tag and DOM attributes to be used for the LiveView container. For example:{:li, style: "color: blue;"}
. By default it uses the module definition container. See the "Containers" section for more information.:id
- both the DOM ID and the ID to uniquely identify a LiveView. One:id
is automatically generated when rendering root LiveViews but it is a required option when rendering a child LiveView.:router
- an optional router that enables this LiveView to performlive_link
andlive_redirect
. Only a single LiveView in a page may have the:router
set and it will effectively become the view responsible for handlinglive_link
andlive_redirect
. LiveViews defined at the router with thelive
macro automatically have the:router
option set.
Examples
# within eex template
<%= live_render(@conn, MyApp.ThermostatLive) %>
# within leex template
<%= live_render(@socket, MyApp.ThermostatLive, id: "thermostat") %>
Containers
When a LiveView
is rendered, its contents are wrapped in a container.
By default, said container is a div
tag with a handful of LiveView
specific attributes.
The container can be customized in different ways:
You can change the default
container
onuse Phoenix.LiveView
:use Phoenix.LiveView, container: {:tr, id: "foo-bar"}
You can override the container tag and pass extra attributes when calling
live_render
(as well as on yourlive
call in your router):live_render socket, MyLiveView, container: {:tr, class: "highlight"}
Provides ~L
sigil with HTML safe Live EEx syntax inside source files.
iex> ~L"""
...> Hello <%= "world" %>
...> """
{:safe, ["Hello ", "world", "\n"]}