dantswain
LiveView asynchronous task patterns
Hi! I was wondering what patterns people have used for the following scenario.
- When the page first loads, spawn some (potentially longer-running, e.g., fetching data from an external API) task.
- When that task finishes, update the UI.
What I have after a couple iterations is something like this:
# do this in handle_params because I want live_patch to trigger it
def handle_params(params, _uri, socket) do
if connected?(socket) do
view_pid = self()
spawn(fn ->
result = make_slow_api_call(params)
send(view_pid, {:api_call_done, result})
end)
end
{:noreply, socket}
end
def handle_info({:api_call_done, result}, socket) do
{:noreply, assign(socket, api_result: result)}
end
defp make_slow_api_call(...) do
# ...
end
This works OK, however there are a couple shortcomings that I would love to handle better:
- It’s hard to test for multiple reasons.
make_slow_api_callis private, so the only way to trigger it is to render the view.- Whenever I render the page, I need to wait for
make_slow_api_callto finish, else I have stray processes after the test finishes. Doing this is not trivial and is error prone.
- Handling errors is complicated - I could
spawn_linkbut if there’s any error in the task then the view reloads, which is ok sometimes but not if the error is due to, say, an upstream service being down, which would lead to an infinite loop of reloading. I can monitor the process, it just feels clunky to need to do that on my own.
I’m curious if anyone has come across a better pattern for this, or maybe there’s something obvious I have just missed.
Most Liked Responses
benwilson512
I think the thing here is less about managing access to the remote server and more about how to not block your liveview processes whether you’re directly pinging the remote endpoint or whether it goes through a genserver.
@dantswain this is a good question! We’ve done basically the same thing (I think we use a task but same idea) and it definitely is a challenge for testing. I think our solution involved setting an assign which controlled whether it was done sync or async, and then in the tests we set that assign to sync. Definitely an area that could use some slightly more ergonomic patterns though!
dantswain
Thanks for the good suggestion @vsoraki. We generally do use a similar pattern to that to mock out our api calls. The thing that makes this difficult to test is that the call (mocked or not) is being done in a process that is spawned from the view. So to test it, we need to know when that separate process has finished, sent a message back to the view process, and the view process has consumed that message.
The simplest way to do that is to repeatedly render the view and check for the effect that you expect, but that can be slow and fail in unexpected ways. What we’ve been doing is actually using the API mock (using Tesla) to capture the pid of the spawned process and relay it back to the test process, then have the test process monitor the spawned process and assert_receive that we get the :DOWN message for the spawned pid. This works ok most of the time but is still sometimes flakey (false negatives) and it requires a bit of overhead in terms of set up.
It looks something like this
test "fetches data from API and renders results", %{conn: conn} do
test_pid = self()
tag = :api_call # tag because we may have multiple APIs to call
Tesla.Mock.mock(fn ->
send(test_pid, {tag, self()})
{:ok, "Hello from the API"}
end)
{:ok, view, _initial_html} = live(conn, "/")
assert_receive {:api_call, spawned_pid}
ref = Process.monitor(spawned_pid)
assert_receive {:DOWN, ^ref, :process, _pid, _reason}, 1_000
assert render(view) =~ "Hello from the API"
end
Supamic
I just wanted to post this shorter ElixirConf talk and accompanying github repo this for anyone else landing here looking for more recent information on this topic because I found it very useful.
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Develop your skills with books, videos, and courses.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"