How to correctly handle latency with Liveview

krishandley · March 2, 2024, 12:09am

Yea I would do exactly that, update the URL with a patch (either directly or from a push event) and show some kind of loading state while waiting.

handle_params would be called but if the state needed to persist across reconnections I would just update the URL via live view to make things easier to test.

If you change the URL on the client without telling the server then I’m sure you could create some interesting bugs too.

sodapopcan · March 2, 2024, 12:56am

Oh I misunderstood, I’m so sorry! I tried this out and it works nicely!

If you use a query param whose sole purpose is the state of a modal and only change that you shoooouuuuullllld be fine probably maybe, but I like your way better!

defmodule MyAppWeb.HomeLive do
  use MyAppWeb, :live_view

  @impl true
  def handle_params(%{"edit" => "edit"}, _uri, socket) do
    {:noreply, assign(socket, :edit, true)}
  end

  def handle_params(_params, _uri, socket) do
    {:noreply, assign(socket, :edit, false)}
  end

  @impl true
  def render(assigns) do
    ~H"""
    <button
      type="button"
      phx-click={JS.show(to: "#foo") |> JS.patch(~p"/?edit=edit")}
    >
      Open Modal
    </button>

    <div id="foo" class="border-4 border-black" style="display: none;">
      <div :if={!@edit}>
        Loading...
      </div>
      <div :if={@edit} phx-mounted={JS.show(to: "#foo")}>
        Loaded
      </div>
    </div>
    """
  end
end

…and of course:

> liveSocket.enableLatencySim(2000)

on the JS console.

krishandley · March 2, 2024, 1:56am

I wrote the snippet on my phone so probably lacked some detail.

For custom dropdowns/selects that interact with the server I add a loading class to the button which gets removed when the dom is patched. It was the simplest solution, plus a loading spinner with CSS.

I have another annoying case where radio options can sometimes be overridden if you change them too fast. But I haven’t tried to work around that yet.

sezaru · March 2, 2024, 4:49am

I didn’t test this, but I’m pretty sure that the phx-mounted will break on high latency because of the following scenario:

Imagine that the div also has a close button that will call JS.hide and a patch with edit as false;
You click in the show button, that will first show the div with the loading part because @edit is false;
You click in the close button, that will hide the div again;
The server receives the first button click and change @edit to true, that will trigger the phx-mounted command and will show the div again even though you already closed in in the client.

Basically is a similar issue to the one I showed in my select gif in the first post.

krishandley · March 2, 2024, 1:04pm

I tested this and was able to open, and close (before @edit had loaded) and it didn’t re-appear. (And it works across re-connects)

<button type="button" phx-click={JS.exec("js-show", to: "#edit") |> JS.push("EDIT")}>
  Edit
</button>

<div
  id="edit"
  style={if !@edit, do: "display: none;"}
  js-show={JS.show(transition: {"transition transition-opacity duration-200", "opacity-0", "opacity-100"})}
  js-hide={JS.hide(transition: {"transition transition-opacity duration-200", "opacity-100", "opacity-0"})}
>
  <button type="button" phx-click={JS.exec("js-hide", to: "#edit") |> JS.push("CLOSE")}>
    Close
  </button>
  <div :if={!@edit}>
    Loading...
  </div>
  <div :if={@edit}>
    Editing
  </div>
</div>

sezaru · March 2, 2024, 3:16pm

I tested it here, if you put a latency simulation of 2~4 seconds and click in the edit button then the close button and the edit button again really fast, the div will not show up the second time.

sezaru · March 2, 2024, 4:17pm

In case anyone is interested, I opened an issue in LiveView’s github page talking about the second example I gave in the first post.

github.com/phoenixframework/phoenix_live_view

live_component with FormField update function is called twice on server restart

opened 04:14PM - 02 Mar 24 UTC

sezaru

### Environment * Elixir version (elixir -v): 1.16.1 * Phoenix version (mix …deps): 1.7.11 * Phoenix LiveView version (mix deps): 0.20.11 * Operating system: Fedora Silverblue 39 * Browsers you attempted to reproduce this bug on (the more the merrier): Firefox and Chrome * Does the problem persist after removing "assets/node_modules" and trying again? Yes/no: Yes ### Actual behavior If you have a live component that receives a `FormField` as an attribute and you restart the phoenix server, when the connection is reestablished, the live component `update/2` function will be called twice. The first time, the form field will come with the `value` field as `nil`, the second time it will arrive with the correct value in the `value` field. For most cases, this is not a problem, since the second `update/2` call will restore the form input value correctly. The problem arrives when your component expects to just receive the `update/2` call once and then all the other calls will be ignored, like this: ```elixir def update(_assigns, %{assigns: %{initialized?: true}} = socket), do: {:ok, socket} def update(assigns, socket), do: {:ok, socket |> assign(assigns) |> assign(initialized?: true)} ``` In this case, the form will never be restored correctly because the first `update/2` call after a server restart will come with `FormField` `value` as `nil`. In case you are wondering why I would like to do something like that, I do it for a custom select component I created to handle high latency scenarios, feel free to ask more information about it if needed and I will post the full code for it as-well. ### Expected behavior After a server restart, I expect that LiveView will try to restore the form and call components `update/2` function that has this form/form_field as attribute only once with the correct `value` instead of calling twice with the first one being with incorrect data. If that is not possible for some reason, can we at least pass some information or flag that indicates that this second `update/2` call is coming from a `form` restore procedure? If I had some way to differentiate a normal `update/2` call from one that is triggered during the form restoration, I would be able to pattern match it in my component and handle it correctly. ### Example Here is a full code that will trigger the above issue: ```elixir Application.put_env(:sample, Example.Endpoint, http: [ip: {127, 0, 0, 1}, port: 5001], server: true, live_view: [signing_salt: "aaaaaaaa"], secret_key_base: String.duplicate("a", 64) ) Mix.install([ {:plug_cowboy, "~> 2.5"}, {:jason, "~> 1.0"}, {:phoenix, "~> 1.7"}, {:phoenix_live_view, "~> 0.20.11"} ]) defmodule Example.ErrorView do def render(template, _), do: Phoenix.Controller.status_message_from_template(template) end defmodule CoreComponents do use Phoenix.Component alias Phoenix.LiveView.JS attr :id, :any, default: nil attr :name, :any attr :label, :string, default: nil attr :value, :any attr :type, :string, default: "text", values: ~w(checkbox color date datetime-local email file hidden month number password range radio search select tel text textarea time url week) attr :field, Phoenix.HTML.FormField, doc: "a form field struct retrieved from the form, for example: @form[:email]" attr :errors, :list, default: [] attr :checked, :boolean, doc: "the checked flag for checkbox inputs" attr :prompt, :string, default: nil, doc: "the prompt for select inputs" attr :options, :list, doc: "the options to pass to Phoenix.HTML.Form.options_for_select/2" attr :multiple, :boolean, default: false, doc: "the multiple flag for select inputs" attr :rest, :global, include: ~w(autocomplete cols disabled form max maxlength min minlength pattern placeholder readonly required rows size step) slot :inner_block def input(%{field: %Phoenix.HTML.FormField{} = field} = assigns) do assigns |> assign(field: nil, id: assigns.id || field.id) |> assign_new(:name, fn -> if assigns.multiple, do: field.name <> "[]", else: field.name end) |> assign_new(:value, fn -> field.value end) |> input() end def input(assigns) do ~H""" <div phx-feedback-for={@name}> <input type={@type} name={@name} id={@id || @name} value={Phoenix.HTML.Form.normalize_value(@type, @value)} class={[ "mt-2 block w-full rounded-lg border-zinc-300 py-[7px] px-[11px]", "text-zinc-900 focus:outline-none focus:ring-4 sm:text-sm sm:leading-6", "phx-no-feedback:border-zinc-300 phx-no-feedback:focus:border-zinc-400 phx-no-feedback:focus:ring-zinc-800/5", "border-zinc-300 focus:border-zinc-400 focus:ring-zinc-800/5", @errors != [] && "border-rose-400 focus:border-rose-400 focus:ring-rose-400/10" ]} {@rest} /> </div> """ end end defmodule Example.Component do use Phoenix.LiveComponent import CoreComponents def update(assigns, socket) do dbg(__ENV__.function) dbg(connected?(socket)) dbg(assigns.field.value) {:ok, assign(socket, assigns)} end def render(assigns) do ~H""" <div> <.input type="text" field={@field} /> </div> """ end end defmodule Example.HomeLive do use Phoenix.LiveView, layout: {__MODULE__, :live} import CoreComponents def mount(_params, _session, socket) do {:ok, socket |> assign(edit: false) |> assign(form: to_form(%{"blibs" => nil}))} end def handle_event("validate", params, socket) do dbg(__ENV__.function) {:noreply, assign(socket, form: to_form(params))} end def render("live.html", assigns) do ~H""" <script src={"https://cdn.jsdelivr.net/npm/phoenix@#{phx_vsn()}/priv/static/phoenix.min.js"}></script> <script src={"https://cdn.jsdelivr.net/npm/phoenix_live_view@#{lv_vsn()}/priv/static/phoenix_live_view.min.js"}></script> <script> let liveSocket = new window.LiveView.LiveSocket("/live", window.Phoenix.Socket) liveSocket.connect() </script> <style> * { font-size: 1.1em; } </style> <%= @inner_content %> """ end def render(assigns) do alias Phoenix.LiveView.JS ~H""" <.form id="form" for={@form} phx-change="validate" phx-submit="save"> <.live_component module={Example.Component} id="input" field={@form[:blibs]} /> </.form> """ end defp phx_vsn, do: Application.spec(:phoenix, :vsn) defp lv_vsn, do: Application.spec(:phoenix_live_view, :vsn) end defmodule Example.Router do use Phoenix.Router import Phoenix.LiveView.Router pipeline :browser do plug(:accepts, ["html"]) end scope "/", Example do pipe_through(:browser) live("/", HomeLive, :index) end end defmodule Example.Endpoint do use Phoenix.Endpoint, otp_app: :sample socket("/live", Phoenix.LiveView.Socket) plug(Example.Router) end {:ok, _} = Supervisor.start_link([Example.Endpoint], strategy: :one_for_one) Process.sleep(:infinity) ``` To reproduce it, just run this on iex, go to `localhost:5001`, type something in the text input element, kill iex, run iex again with the above code and wait for the browser to reconnect the socket, you will see something like this in the terminal: ```elixir 13:12:46.142 [debug] Replied in 2ms [iex:15: Example.Component.update/2] __ENV__.function #=> {:update, 2} [iex:16: Example.Component.update/2] connected?(socket) #=> true [iex:17: Example.Component.update/2] assigns.field.value #=> nil 13:12:46.156 [debug] HANDLE EVENT "validate" in Example.HomeLive Parameters: %{"_target" => ["blibs"], "blibs" => "fewfwefe"} [iex:21: Example.HomeLive.handle_event/3] __ENV__.function #=> {:handle_event, 3} 13:12:46.156 [debug] Replied in 279µs [iex:15: Example.Component.update/2] __ENV__.function #=> {:update, 2} [iex:16: Example.Component.update/2] connected?(socket) #=> true [iex:17: Example.Component.update/2] assigns.field.value #=> "fewfwefe" ``` Which shows the 2 `update/2` calls after server is restarted.

RomanKotov · March 2, 2024, 5:24pm

Have looked into the thread.

It seems, that you have a race condition. You edit one form field, and it triggers a phx-change event. User starts editing another field. Server responds and resets the user inputs.

If latency is an issue, then possibly it is better not to emit phx-change events at all? Just allow user to edit form and send the whole data with phx-submit. You can disable the fields with phx-disable-with during server works on phx-submit event. Of course, you will lose out-of-the-box validation mechanism with this approach, but you will get consistent UX for all users.
This kind of race-conditions are not LiveView-specific. You can get the same results with other frameworks too.

You can look into other options, if you want to have a real-time validation:

Validate purely client-side. This one will work even without network connection.
Assign nothing in your phx-change function. If you assign something - it will trigger a re-render and erase newer edits. You can push_event with validation results instead and process it in the client-side hooks (show appropriate error messages). By the way, you can use this trick to edit contents of any part of your page.
Use different assigns for form data and form errors. Change assigns only for form errors. This way only errors will be re-rendered. User edits will remain.
Possibly something else

By the way, here are some posts about restoring state for Phoenix LiveView forms:

Also I like the idea of using URL params to store the state of the form (if it is tiny), or filters. It works nice with browser API, and enables “back” and “refresh” buttons work right.

cmo · March 4, 2024, 2:32am

I push an event to the front end to update the url params without triggering handle_params. Pretty sure I took the JavaScript from liveview internals. No claims that this is a good idea but I needed to do this in a couple of spots and it hasn’t bit me yet.

// update the URL with the given params
// see update_and_assign_url_query_params/2
window.addEventListener("phx:set-search-params", ({ detail }) => {
  if (!canPushState()) {
    return
  }

  let searchParams = new URLSearchParams(window.location.search)

  Object.entries(detail).forEach(([key, value]) => {
    searchParams.set(key, value)
  })

  let currentState = history.state || {}

  const origin = window.location.origin
  const pathname = window.location.pathname
  searchParams = searchParams.toString()
  const url = `${origin}${pathname}?${searchParams}`

  history.replaceState(currentState, "", url)
})

And here is what I use in a liveview.

  defp update_and_push_url_query_params(socket, new_params) do
    new_params = encode_params(new_params)

    socket
    |> push_event("set-search-params", new_params)
    |> update(:params, &Map.merge(&1, new_params))
  end

  defp encode_params(%{} = params) do
    for {key, value} <- params, reduce: %{} do
      acc ->
        Map.put(acc, key, encode_param(value))
    end
  end

  defp encode_param(param) when is_list(param) do
    Enum.map(param, &encode_param/1)
  end

  defp encode_param(%Date{} = date) do
    Date.to_iso8601(date)
  end

  defp encode_param(%DateTime{} = datetime) do
    Ensure.utc_string(datetime)
  end

  defp encode_param(value)
       when is_boolean(value)
       when is_integer(value)
       when is_binary(value)
       when is_number(value) do
    value
  end

  defp encode_param(param) when is_map(param) and not is_struct(param) do
    encode_params(param)
  end

sezaru · March 5, 2024, 2:27am

Here is a quick trick that I found to leverage .phx-submit-loading to change the internal element of a button (ex. change the button icon to a loading spinner):

<.button with_icon type="submit" color="success" class="group/button">
  <Loading.spinner class="hidden group-[.phx-submit-loading]/button:block w-5 h-5" />
  <Icons.create class="block group-[.phx-submit-loading]/button:hidden w-5 h-5" /> Create
</.button>

This probably is obvious for frontend users, but since I’m normally working more in backend stuff, I was not aware of the tailwind group feature that allows you to set classes in child elements based on a class from a parent element.

ollien · March 11, 2024, 3:47am

This doesn’t precisely answer your question, but I found this blog post from fly.io which sheds some light on techniques to handle this latency