Is there a way to use tom-select.js with LiveView?

Phoenix Forum Questions / Help
,
1

Is there a way to use https://tom-select.js.org with LiveView?
I tried it out, but the <select> element that I tried to affect is not modified at all… nothing seems to happen. Am I missing anything?

Thanks!

2

Yea, you can setup a hook. See JavaScript interoperability — Phoenix LiveView v0.18.3

3

do you mean I should figure out something like:

  dom: {
    onBeforeElUpdated(from, to){
      if(from._x_dataStack){ window.Alpine.clone(from, to) }
    }
  }

for the tom-select lib?

4

They mean a hook, which is this part of the page.

https://hexdocs.pm/phoenix_live_view/js-interop.html#client-hooks-via-phx-hook

5

Here are a bunch of examples. They use Alpine but you can just forget about that part and look at the hook examples

6

YAY!

The hook works and the multi-select is being rendered correctly. I added phx-update="ignore" to the .input element, otherwise the multi-select would disappear altogether when the form is validated.

Unfortunately, I still haven’t got it right: the form validation turns the multi-select back to its default - plain html - look. I could switch off the form validation, but it does not seem the right thing to do… I’m now trying to use onBeforeElUpdated in this way:

onBeforeElUpdated(from, to) {
  if (from.multiple == true) {
    to = from.cloneNode(true)
  }
}

but the multiselect still gets reset to the plain html version when the form is validated. Any suggestion?

Update:

By checking the generated HTML, it looks like I should rather use this:

to.parentNode = from.parentNode.cloneNode(true)

but it’s still not working.

7

I solved it by adding phx-update="ignore" in the <div> that wraps the <select> in the CoreComponents’ function def input(%{type: "select"} = assigns) do…

Thank you for the help!

8

I’ve noticed the same. Not sure why the ignore needs to go 1 higher than the actual tag.

9

If you want a LiveView-native alternative that doesn’t require tinkering with 3rd-party JS libraries, you could try LiveSelect.

If you do, I’d be interested in your feedback.

4 Likes
10

I’ve been trying to figure out what I’d like to do for my search/select in my application and this is exactly what I was looking for!

The only thing that has me wondering if I’d rather use TomSelect is that I notice that the keyboard selection seems to do a round trip to the server, which makes it feel a little slower compared to a typical select widget. I’m not great at writing components yet, but maybe I’ll start with this and maybe contribute back at some point if I figure out how to make selection local.

1 Like
11

LiveView is server-side rendered, so every update requires a round-trip to the server. Using code on the client will - other things being equal - always be faster and more reactive.

For live_select, I tried to remove some unnecessary round-trips: for example the live_select_change event is now generated directly on the client (it used to be generated on the server, then sent to the client, then forwarded to the parent from the client).

I’m sure one could take it further: for example arrow-key navigation of the items in the dropdown could probably be implemented on the client (it’s just a matter of applying the right class to the currently active item).

Thought experiment: you could take it to the extreme by annotating the component with phx-update="ignore" and have the hook do all the work :smiley: At that point you’d have the best of both worlds: quick response times + easy integration with LiveView. Don’t know if it would be so much fun to write though :roll_eyes: One could also take an existing JS library and try to wrap it into a Phoenix component… also probably not much fun!

Anyway, I’m digressing. If you want to contribute, I’d love to hear from you!

1 Like