Building a dynamic select component (in Phoenix LiveView?)

You don’t need React for this. Just build the datalist server side, with the few letters typed by the user as the search criteria to filter down the list to a manageable size. This is one of the cases where Liveview’s live form validation really shines.

Ah yes, that is clever. I just checked out the phoenix live view demo.

Maybe I’m too picky I think it looks a bit too much like the standard Chrome autofill thing. Can’t seem to style it either.

Schermafbeelding 2022-03-01 om 22.55.131618×558 18.2 KB

I also need an ID to be set (in a hidden input) for form submission, rather than just the text. I suppose that’s doable though.

Like selects, datalists have fewer styling options available. You cannot style suggestions list.

One alternative to using dynamic selects is allowing user to select players from bigger list is -
popup with input search panel with table below and allowing users to search and select from there.

One alternative to using dynamic selects is allowing user to select players from bigger list is -
popup with input search panel with table below and allowing users to search and select from there.

Yes that is indeed an option. Although you would somehow need to connect the selected item in the modal back to the form / hidden input.

By the way, I just came across this post which is a bit more what I’m looking for:

My concern though is that there are certain frontend behaviours (such as clicking outside the dropdown to close it) that are not included in this blog post.

And I am not convinced the server should be contacted for such behaviour

^ I just realized you can solve this client-side via phx-click-away and LiveView.JS

Do note that a major upside here is that precisely because it’s standard it will interact better with screen readers, mobile devices, and other accessibility tools.

For screen readers sure Although on mobile it does not seem to work so well for the regular user.

That blog post is a little outdated (I’m the author) and today you could fully rely on LiveView.JS for handling the client side part. (I’m gonna revise this post at some time).

Do you add the serialised JSON into every instance of the autocomplete field? One approach how you could decrease the payload would be to save it in a simple script tag and store the reference inside the data attribute. Something like this:

<script>
  const __fantasyLeague = {
    players: '<%= Jason.decode!(players) %>',
  };
</script>

<div id="your-picker-1" data-players-ref="players" />
<div id="your-picker-2" data-players-ref="players" />

And then you can create your react component like this.

const players = JSON.parse(__fantasyLeague.players)
ReactDOM.render(<YourSelectComponent players={players} />)

This way you only send the list once and do not end up with gigantic data attributes. You have to load the data once eventually (if you don’t filter it on the server)

I ended up solving it via an async react-select, the react component from Mantine that I was using before just didn’t work well with async data. So that removes the issue of having to load the payload in the DOM initially.

But yes initially it would add the entire payload to every select.

Here is the react-select implementation that I ended up using in case anyone is interested:

<.remote_select form={f} field={:player1_id} url={player_options_url(@conn)} options={Map.fetch!(@player_options, :player1)} placeholder={select_player_placeholder()} />
... etc ...

  def remote_select(assigns) do
    ~H"""
    <.form_field {form_field_assigns(assigns)} ><.remote_select_tag {remote_select_assigns(assigns)} /></.form_field>
    """
  end

  def remote_select_tag(assigns) do
    assigns =
      assigns
      |> assign(:error, error?(assigns.form, assigns.field))

    ~H"""
    <.react controller="remote-select" props={extra_attributes(assigns)}>
      <%= Phoenix.HTML.Form.hidden_input(@form, @field, data: [remote_select_target: "input"]) %>
      <div data-remote-select-target="component"></div>
    </.react>
    """
  end

react/1 is a simple functional component that adds a div with display: contents, adds a Stimulus data-controller attribute and serializes props (converting underscore to camelcase, and so on.)

The remote-select Stimulus controller:

import { Controller } from '@hotwired/stimulus';

export default class extends Controller {
    static values = { props: Object };
    static targets = ['input', 'component'];

    connect() {
      ReactDOM.render(
        <RemoteSelect {...this.propsValue} defaultValue={this.defaultValue} onChange={this.handleChange} />,
        this.componentTarget
      );
    }

    disconnect() {
      ReactDOM.unmountComponentAtNode(this.componentTarget);
    }

    handleChange = (option) => {
      // prettier-ignore
      this.inputTarget.value = option === null ? '' : [].concat(option).map(o => o.value).join(',');
    };

    get defaultValue() {
      return this.propsValue.options.find((option) => option.value == this.inputTarget.value);
    }
  };

Notice how it concatenates values via ‘,’ in a single hidden input (in case multiple options are selected).

And finally the react component:

import React from 'react';
import AsyncSelect from 'react-select/async';
import { withTheme, withDefaults } from './react_select';

function RemoteSelect({ url, options, ...restProps }) {
  const loadOptions = (query) => {
    const remoteUrl = new URL(url);
    remoteUrl.searchParams.set('query', query);
    return fetch(remoteUrl.toString()).then((response) => response.json());
  };

  return (
    <AsyncSelect
      {...restProps}
      defaultOptions={options}
      noOptionsMessage={({ inputValue }) => (inputValue ? `Geen resultaten voor "${inputValue}"` : 'Type om te zoeken')}
      loadOptions={loadOptions}
    />
  );
}

export default withTheme(withDefaults(RemoteSelect));

Not much special going on here either except that it uses the url property to perform the async request