Phoenix Live View Debounce

Tiziano — Sun, 26 May 2019 12:53:21 +0000

Phoenix Live View is still in beta but a lot of people are building interesting stuff with it. At Simplificator we are also trying to use it for both external clients and internal projects.

Search form

One nice use case of the phoenix live view is to build a dynamic search form that performs some searches while typing.

As showed by Chris McChord in his examples this is easy to achieve with a live view:



def mount(_session, socket) do
  {:ok, assign(socket, query: nil, results: nil, loading: false)}
end

def handle_event("search", %{"query" => query}, socket) do
  send(self(), {:search, query})
  socket = socket
  |> assign(:query, query)
  |> assign(:loading, true)

  {:noreply, socket}
end

def handle_info({:search, query}, socket) do
  socket = socket
  |> assign(:loading, false)
  |> assign(results: search_results(query))
  {:noreply, socket}
end

The idea is to react on every key stroke by sending a message to the same process. This message is of the form {:search, query} and asynchronously performs the necessary query (for example on the database).

This is a pragmatic approach, but usually we want to avoid to perform too many unnecessary queries while typing. The possibility to set a minimum amount of time between two successive queries is called debounce and it is a very common feature in most javascript framework.

The debounce feature is not available at the moment in phoenix live view but will be implemented in the near future, as you can see from this discussion. Luckily this feature is very easy to implement.

Debounce

The biggest difference from the previous code snippet is that instead of sending a message to the current process, the message to perform the query is sent after a certain "debounce time" and the query term is stored in the state of the process (the socket in case of the phoenix live view).

This is achieved using Process.send_after/3 function which returns a timer reference. Then the timer reference is stored in the state (socket) of the live view along with a loading flag and the search term.

In case a new query term arrives within the "debounce time", the new query term is stored in the state. Once the "debounce time" is reached, the :search message is triggered, and the query performed.

Here you can see the full code snippet:



# new query term arrives within the debounce time
def handle_event("search", %{"query" => q}, %{assigns: %{loading: true}} = socket) do
  socket = socket
  |> assign(:query, q)

  {:noreply, socket}
end

def handle_event("search", %{"query" => q}, %{assigns: %{loading: false}} = socket) do
  # debounce time of 300 ms
  timer_ref = Process.send_after(self(), :search, 300)
  socket = socket
  |> assign(:query, q)
  |> assign(:timer_ref, timer_ref)
  |> assign(:loading, true)

  {:noreply, socket}
end

def handle_event("search-final", %{"query" => q}, socket)  do
  Process.cancel_timer(socket.assigns.timer_ref)
  socket = socket
  |> assign(:query, q)

  send(self(), :search)
  {:noreply, socket}
end

def handle_info(:search, socket) do
  socket = socket
  |> assign(:loading, false)
  |> assign(:results, search_results(socket.assigns.query))

  {:noreply, socket}
end

As you see the timer reference is used to cancel the future search request when the user will click on the search button and "commits" to a search; any future request is canceled (if any) and an immediate search performed.

Password input in Elixir

Tiziano — Sun, 12 May 2019 19:12:42 +0000

I was looking for a function to get user input without echoing on the screen, for example to get a password from the command line interface. I didn't find any function in the IO Elixir library and the erlang :io.password does not work while running a Mix Task. As suggested in this Stackoverflow answer I went to look how the hex tasks implements this feature.

Processes on the rescue

The approach seems a bit hacky at first, but quite effective. The idea is to spawn a process while the user is typing and clearing the row every millisecond. After the user has typed, the process is stopped by sending an appropriate message.

Here you can see the full code snippet, extracted from the hex repository See this pull request.

defmodule Get do
  # Password prompt that hides input by every 1ms
  # clearing the line with stderr
  def password(prompt) do
    pid = spawn_link(fn -> loop(prompt) end)
    ref = make_ref()
    value = IO.gets("#{prompt} ")

    send(pid, {:done, self(), ref})
    receive do: ({:done, ^pid, ^ref} -> :ok)

    value
  end

  defp loop(prompt) do
    receive do
      {:done, parent, ref} ->
        send(parent, {:done, self(), ref})
        IO.write(:standard_error, "\e[2K\r")
    after
      1 ->
        IO.write(:standard_error, "\e[2K\r#{prompt} ")
        loop(prompt)
    end
  end
end

First a process is spawned and the newly created process enters in a loop. Every millisecond, the following string is printed on the screen: "\e[2K\r". This is an XTerm control sequence that erases all the line (ESC [ 2K) and then brings back the cursor at the beginning of the row (\r).

After the value is read from the command line, a message is sent to the spawned process to signal the end of input. The process then ends the loop and signal back to the parent that he has been closed.

I think that in this code snippet there are some interesting tips:

the clear of the row happens by writing on the :standard_error and not on the :standard_input. I think this is because the :standard_input is blocking on receiving what the user is typing
a couple of messages are exchanged between the parent and the child process: in particular the parent waits for the child to acknowledge that he has finished. Likely this is to protect from the corner case where the last character(s) are not cleared up (the last IO.write in the :done block) and from the case where the child process clears the next prompt line (receive block in parent process).
make_ref is used to create a unique reference and used as a "uniqueness" flag when sending messages.

DEV Community: Tiziano

Phoenix Live View Debounce

Search form

Debounce

Password input in Elixir

Processes on the rescue