Awesome work!
renews
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! 
11
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.
0
trisolaran
It’s by design. It gives you the ability to change the selection.
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
0
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
1
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.
1
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.
0
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.
1
trisolaran
Hi @devilray and thank you for the very elaborate message and all the examples.
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.
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.
1
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?
2