LiveSelect - Dynamic selection input component for LiveView

[trisolaran]

@egeersoz

n the short term, is there a way to inspect the HTML markup of the dropdown menu? It automatically closes when using the Inspect tool in Chrome!

There’s tricks on how to inspect content that disappear automatically when focus is lost. The easiest I know of is this one.

@egeersoz

Specifically, I’d like to write a test with the following steps:

1. Click on the input and type “Ala”
2. Assert that the dropdown field contains states with the text, e.g. “Alabama”
3. Click “Alabama”
4. Assert that “Alabama” got added to the selected_states assign
5. Click the X on the “Alabama” tag
6. Assert that “Alabama” got removed from the assign

Most of this test has little value because it’s not testing your code but a library that’s already tested. There’s already tests in the live select test suite that check that the dropdown is correctly filled with elements, that clicking on “x” removes tags, etc.

Your tests should test your own code

@egeersoz

Speaking of testing, what is the testing strategy for a component that uses LiveSelect?

You test it like any other input element: send the form’s data using render_submit or render_change and test that your view (or component) is reacting as you expect.

The only caveat is that the input value is sent with an hidden input, so you can’t use form to set the value, you have to do it in the render_submit call.

[renews]

Awesome work!

[trisolaran]

Version 1.4.0 released with support for associations/embeds

This latest release includes support for displaying and selecting associations and embeds using LiveSelect.

This is something quite a few folks were trying to do, and were experiencing considerable frustration in the process. Not surprisingly! LiveSelect was designed to work well with simple values like strings and numbers, and although it was able to encode arbitrary values in its options, it wasn’t able to deal with complex values or changesets from a form.

Now this has changed, and users should be able to deal with associations/embeds with only minimal hassle. This section in the docs explains how to do it with the help of an example.

As usual, feedback is very welcome! Please do open an issue if anything is weird/doesn’t work/could be improved

Thanks again to everyone who used this component!

[devilray]

I’ve just stumbled onto live_select and am trying to use it instead of a select control in situations where there are many linked entities in a LiveView app.

I was wondering: when there is an entity selected, and the control is subsequently focused again, the input field goes blank. Is this by design, or is something wrong happening in my instance?

It isn’t a show-stopping issue in the create view, as loss of focus (the blur event) returns the value/id, but in the update view, the value (and id) are removed, but not reinstated.

The chain of messages in the console in the first instance is:

[debug] HANDLE EVENT "focus" in KlepsidraWeb.JournalEntryLive.Index
  Component: LiveSelect.Component
  Parameters: %{"value" => "London, England - United Kingdom"}
[debug] HANDLE EVENT "blur" in KlepsidraWeb.JournalEntryLive.Index
  Component: LiveSelect.Component
  Parameters: %{"value" => ""}

Whereas, in the second instance, clicking on the edit button and opening the same form_component with existing data, returns:

[debug] HANDLE EVENT "focus" in KlepsidraWeb.JournalEntryLive.Index
  Component: LiveSelect.Component
  Parameters: %{"value" => "Pavlodar, Pavlodar Region - Kazakhstan"}
[debug] HANDLE EVENT "change" in KlepsidraWeb.JournalEntryLive.Index
  Component: LiveSelect.Component
  Parameters: %{"_target" => ["journal_entry", "location_id_text_input"], "journal_entry" => %{"location_id_text_input" => ""}}
[debug] HANDLE EVENT "blur" in KlepsidraWeb.JournalEntryLive.Index
  Component: LiveSelect.Component
  Parameters: %{"value" => ""}

Is this expected behaviour? I am using the latest live_select, 1.4.2, and have had to update to phoenix_html 4.1.0 to be able to update live_select.

[trisolaran]

@devilray

I was wondering: when there is an entity selected, and the control is subsequently focused again, the input field goes blank. Is this by design, or is something wrong happening in my instance?

It’s by design. It gives you the ability to change the selection.

@devilray

It isn’t a show-stopping issue in the create view, as loss of focus (the blur event) returns the value/id, but in the update view, the value (and id) are removed, but not reinstated.

@devilray

Whereas, in the second instance, clicking on the edit button and opening the same form_component with existing data, returns:

Hard for me to follow cause I don’t know what these “create” or “update” views are, or what the “edit” button is. You’re talking about code I cannot see. Please create a bug report and describe the example in detail. The best thing to do is to add a small example repo so I can reproduce the issue, that will greatly reduce the time to a bugfix, if one is required. Thanks

[devilray]

Thank you for the quick reply.

I apologise for the misunderstanding I caused: when referring to “create” and “update” views, I was referring to CRUD terminology, or the view presented by the form_component.ex live component, as a form for creating new entities, or for editing/updating existing entities, as created by default LiveView generators.

You’re right in your suggestion, and I’m now creating a small repository to demonstrate the problem I’ve been having. I’ll open a detailed bug report with a link to this, as suggested.

Thanks again @trisolaran

[devilray]

@trisolaran, I have now opened a bug report (LiveSelect wipes out the underlying value when focus is received · Issue #86 · maxmarcon/live_select · GitHub), with a quick GIF and a minimal repository, describing this issue in detail.

By the way, I really love live_select, and can’t wait to start using it as a serious select element replacement! Is there any way to modify this behaviour of clearing the input field, while showing the dropdown with the current choice highlighted? I’m thinking of how not to surprise users by clearing the choice, however brief this interruption may be.

Thanks for the fantastic work.

[trisolaran]

Hey @devilray, thanks for the repo and the bug report - while running your repo, I realized that this bug had already been reported and fixed. I just hadn’t released a new version, which I did just now.

Sorry for wasting your time, I had forgotten about that bugfix. Next time it’s a good idea to check the changelog, as it contains all the changes, even unrelased ones, and also try against the latest main.

Is there any way to modify this behaviour of clearing the input field, while showing the dropdown with the current choice highlighted?

How do you picture that exactly? the user has to be able to change the selection, and to do that, they have to be able to type in the input field. Hard to imagine how they can do that if the text of the selection stays in the input field.

[devilray]

@trisolaran, I saw you closing the issue, and have already updated to live_select 1.4.3, and it works beautifully! Thank you very much for that, and yes, I will look into past issues in the future, sorry.

How do you picture that exactly? the user has to be able to change the selection, and to do that, they have to be able to type in the input field. Hard to imagine how they can do that if the text of the selection stays in the input field.

I realise what you’re saying, and part of me agrees with your design decision.

However, I feel that—and this is subjective, I know—to follow the principle of least astonishment, it would be better to keep the current input intact, and use the fact that you have already provided the allow_clear option to deal with exactly the problem you describe above—clicking the ‘x’ icon will clear the input. This also seems to me to follow the standards set by comboboxes since Mac OS and Windows development environments established in the 90s: clicking the ‘expand’ arrow opened the options, with the current result left in place, and it and its neighbouring options shown in the dropdown selections.

Another reason to do this is that the suddenness of the change may result in making the user apprehensive to touch the field, hurting UX. Finally, it feels like it could also be an accessibility problem.

I provide a few compelling examples of exactly this in action (to varying degrees of user-friendliness), taken from popular sites on the internet:

And another, a jQuery select component, which takes a completely different approach, but does the same thing effectively:

Sorry I uploaded so many examples, but I feel that each is subtly different, promoting a different way of doing the same thing. One thing that is very good is that some of them, when clicked/focused for a second time, automatically highlight the currently selected option—in addition to keeping it in the search box—which, it seems would be very easy to do in live_select.

[trisolaran]

Hi @devilray and thank you for the very elaborate message and all the examples.

@devilray

it would be better to keep the current input intact, and use the fact that you have already provided the allow_clear option to deal with exactly the problem you describe above—clicking the ‘x’ icon will clear the input.

The allow_clear option gives you a way to clear the selection - when you click on the x icon, your selected option is lost - whereas what I was talking about is giving the user a way to change the selection while not forgetting the current one (even though, as you pointed out, the selection is not visible anymore, and this might not be what most users expect) so that if the user decides to “abort the search”, the current selection is restored. This is how LiveSelect behaves by default.

@devilray

Another reason to do this is that the suddenness of the change may result in making the user apprehensive to touch the field, hurting UX. Finally, it feels like it could also be an accessibility problem.

100% point taken, there are certainly better/different ways of implementing this functionality.
The select2 approach seems particularly compelling to me, and they can do that because they have an additional text input field appearing below the selection.

I’m very open to include this approach (or another one that offers similar functionality/UX) as an additional input mode to LiveSelect, so if you’re interested in contributing, feel free to.

[devilray]

Hi @trisolaran, thank you for the detailed clarification.

I will look into this more deeply over the coming couple of weeks, first I’m trying to completely understand the code in live_select before I do anything further.

As soon as I’m on top of it, I would like to contribute to this and would like to discuss one approach which seems extremely functional to me, taken from the Frappe framework which underpins ERPNext, an open-source ERP:

What’s the best way to discuss some of these choices, here, on GitHub, or another channel?

[trisolaran]

@devilray

What’s the best way to discuss some of these choices, here, on GitHub, or another channel?

GitHub please

[trisolaran]

Version 1.5.0 is out

Thanks to @ringvold’s great work, this version introduces a new mode called quick_tags. In this mode, the dropdown stays open after selection, allowing the user to select additional elements in quick succession. Also, elements can be deselected via the dropdown, too. Here it goes:

As an extra bonus, @ringvold also added a toggle to the showcase app that styles the options in the dropdown as checkboxes using slots. Nice.

Thanks again @ringvold!

[pau-riosa]

I would like to ask how does selection_recovery works in version 1.3.0 (2023-12-05) because when I updated to liveview 1.0 it seems that there is something broken

[darraghenright]

As you point out, you’re using a very old version.

Version 1.4.4 which was released on 2024-12-07 added support for LiveView 1.0. I am not sure of the details but I would start by upgrading to that version or higher and see if your issues are resolved.

Here’s the changelog which might be useful for reference if you’re curious about what’s changed in the last while.

If you’re still experiencing issues after upgrading you can open a bug report and give a detailed description of the issue you’ve encountered. But I’d advise that you try to upgrade before that.

[pau-riosa]

Thank you. Will keep you posted.

[pau-riosa]

Related to what I’m experiencing lately, does anybody tried to use live_select inside an async_result? It seems that the reconnection() binding is not working when <.live_select> component is inside an async_result and then experience a view crashed.