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...
For further actions, you may consider blocking this person and/or reporting abuse
Beautiful!
Wouldn't the
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 :)
Just for future reference, if someone lands here like me, it is now fully supported out of the box :)
hexdocs.pm/phoenix_live_view/bindi...