Phoenix Live View Debounce

Tiziano on May 26, 2019

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 bo... [Read Full]
markdown guide
 

Beautiful!

Wouldn't the

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

make the debounce do its job better?

Argument being that expensive searches might last 1-200ms and in the meantime a new keystroke would appear

 

Thank you!

Actually the two implementation are the same because the assign function does not change socket in place, but build a new copy. The new socket is sent to the live view only when handle_info function completes.

Search_results in my implementation is a synchronous call and blocks the process until it returns. If search_results takes a very long time what happens is that the updated query terms queue in the mailbox of the process until the search_results function returns. You can see it very well if you put something like Process.sleep(10_000) inside the search_function.

 

:facepalm:

I'm a 12-year ruby veteran - and still breaking in my elixir-shoes

:$

 

Very nice!

I was looking into similar approach, but yours is much more elegant with Process.send_after.

However, it does not solve all problems. For example, I have a case where there is a text area and server does calculations on word count and few additional metrics. Even with this approach, whole text is being sent down the wire with every key stroke. So I hope we'll see proper debounce on frontend side soon ;)

 

Thank you,

indeed the whole text is send down the wire. This depends on the implementation of phoenix live view js side (phx-change in particular). Let's see how the 'official' debounce will be implemented :)

code of conduct - report abuse