I am playing a bit with Phoenix LiveView and Surface, and I’m struggling to find the right way to do a component.
Basically, I wanted to do a component with LiveComponent, that takes some text as a property. Then the component would display the text progressively, starting from a blank line and adding characters at a regular pace, like dialogs in video games.
Intuitively, I thought my stateful LiveComponent would be able to use Process.send_after and update the text being displayed in an handle_info. As it turns out, LiveComponents run in the process of their parent LiveView so I can’t do that. The only solution I found then is to handle that in the parent LiveView, but that means breaking the encapsulation as most of the component’s behaviour would not be handled by itself.
So I’m curious, how would you handle such a component?
Alternatively this might mean it is time to transform this LiveComponent into its own LiveView process proper.
However, it seems like in this case you’re only trying to show an aesthetic effect. There are ways to do this kind of thing nowadays using only CSS I believe, which might be a better way to go, as it reduces network chatter and allows the browser to optimize animation. EDIT: Ah, @preciz already linked to some CSS resources just now .
The case I’ve given as an example does not really matter to me. I’m just playing with the lib.
Sure, I could use Javascript to do that, but I wanted to see how LiveView would be able to handle something like that by itself. After all, it’s often presented as a “you don’t have to write Javascript” solution.
Alternatively this might mean it is time to transform this LiveComponent into its own LiveView process proper.
I thought about that, but could not find a way to pass properties to it like I can do with a LiveComponent.
Basically, I’m surprised I can’t have a reusable and configurable component that is as dynamic as a LiveView process.
We’ve had similar real world situations (components subscribing to external information) and at the moment you simply can’t encapsulate it without using private Phoenix LiveView APIs. We just bit the bullet and have the parent live view do a handle_info to send_update.
However, I believe there are plans to allow send_update to work from external processes which would allow you to ping the component directly.
We’ve had similar real world situations (components subscribing to external information)
Thanks! That’s the kind of thing I was thinking I would want to do in the future. Too bad there is no better solution, but at least now I know I haven’t missed anything obvious.
However, I believe there are plans to allow send_update to work from external processes which would allow you to ping the component directly.
I wrote a clock component, and ran into this self-updating issue too!
My solution also requires a handle-info handler in the parent LiveView…
defmodule MyApp.ClockComponent do
@moduledoc """
Renders a live clock that updates at a periodic interval.
The clock update frequency (`interval`) and the output format (`strftime`)
are configurable options.
To call from the parent template:
<%= live_component(@socket, MyApp.ClockComponent, id: 1, interval: 10_000 %>
<%= live_component(@socket, MyApp.ClockComponent, id: 2, strftime: "%H:%M" %>
To make this work, the parent LiveView needs a handle_info function:
@impl true
def handle_info({:tick, assigns}, socket) do
send_update MyApp.ClockComponent, assigns
{:noreply, socket}
end
The parent `handle_info` is required because there is no `handle_info` callback
for LiveComponent.
Ben Wilson (@benwilson512) on Elixir Forum says that in the future, there may
be a `send_update` feature to allow external processes to ping the component
directly.
https://elixirforum.com/t/livecomponent-updating-itself-at-regular-intervals/37047/6
Also the code in the `update` callback is more complex than desired.
Ideally the timer would start once in the `mount` callback. This was not
possible because the timer interval should be configurable in the assigns,
and the assigns are not available in the `mount` params. (AFAIK)
Maybe there is a simpler approach for starting the timer...
"""
use Phoenix.LiveComponent
@impl true
def render(assigns) do
~L"""
<%= @date %>
"""
end
@impl true
def mount(socket) do
{:ok, socket}
end
@impl true
def update(assigns, socket) do
opts = update_assigns(assigns)
unless assigns[:timer], do: start_timer(opts)
{:ok, assign(socket, opts)}
end
defp update_assigns(assigns) do
strftime = assigns[:strftime] || "%H:%M:%S"
[
id: assigns[:id],
timer: "started",
interval: assigns[:interval] || 1000,
strftime: strftime,
date: local_date(strftime)
]
end
defp local_date(format) do
NaiveDateTime.local_now()
|> Calendar.strftime(format)
end
defp start_timer(opts) do
:timer.send_interval(opts[:interval], self(), {:tick, opts})
end
end
I had another look at this, re-implemented as a LiveView, and everything is much simpler.
defmodule MyApp.ClockLive do
@moduledoc """
Renders a live clock that updates at a periodic interval.
The clock update frequency (`interval`) and the output format (`strftime`)
are configurable session options.
To call from the parent template:
<%= live_render(@socket, MyApp.ClockLive, id: 1, session: %{"interval" => 10_000}) %>
<%= live_render(@socket, MyApp.ClockLive, id: 2, session: %{"strftime" => "%H:%M"}) %>
"""
use Phoenix.LiveView
@impl true
def mount(_params, session, socket) do
start_timer(session["interval"] || 1000)
strftime = session["strftime"] || "%H:%M:%S"
state = [strftime: strftime, date: local_date(strftime)]
{:ok, assign(socket, state)}
end
@impl true
def render(assigns) do
~L"""
<%= @date %>
"""
end
@impl true
def handle_info(:clock_tick, socket) do
newdate = socket.assigns.strftime |> local_date()
{:noreply, update(socket, :date, fn _ -> newdate end)}
end
defp start_timer(interval) do
:timer.send_interval(interval, self(), :clock_tick)
end
defp local_date(format) do
NaiveDateTime.local_now()
|> Calendar.strftime(format)
end
end
.
