search

mynamesleon / aria-autocomplete

Accessible, extensible, dependency-free autocomplete with multi-select
GNU General Public License v3.0
20 stars 6 forks source link

Why empty the field on blur ? #8

Closed botmaster closed 4 years ago

botmaster commented 4 years ago

Hello Leon,

aria-autocomplete is really useful. Thank you for this very good job. I have an issue with it. Why empty the input field on blur ? User should be able to submit the text field even if the autocompletion has no results. Why did you make this choice? Is there a way to keep the contents of the input even if there are no results? Thanks.

Pascal.

mynamesleon commented 4 years ago

Thank you. Any and all feedback is much appreciated.

In this case, I'm treating the autocomplete as a <select> or checkbox list replacement, with selections for specific items. Having a mode that retains whatever the user types, without needing to make a selection is definitely a worthwhile enhancement. The difficulty with it is how this behaves with the multiple selection mode.

mynamesleon commented 4 years ago

My initial thinking for this was to maintain having to do an explicit selection from the list, but where the current value in the input gets prepended to the list as well. So if you typed "tomatoes", and that wasn't in the list of options, it would add an option for it (e.g. "Add tomatoes...") that the user could then select. (so pretty much the same as I remember Selectize working)

That way the UX of the control remains the same, and it would be more readily compatible with both single and multi select modes, without ever making accidental automatic selections.

I've been resisting doing this though for a number of reasons:

  1. it's technically possible already using the onResponse callback option.
  2. this adds more complexity to when the original element is an input, and the confirmOnBlur option is used. E.g. should it just keep the value in the generated input, but not update the original hidden input, if confirmOnBlur is false?
  3. this also becomes more complex with the progressive enhancement approach when initialising the autocomplete on a <select> element, or a checkbox list, where the available elements are used as the options. In that case, the library would have to prepend additional <option> or checkbox elements into pre-existing lists.

@botmaster I appreciate that you and @mh-nichts have already raised and merged a PR in your own fork to handle this scenario. But the adjustment you've made of course only applies to when the original element was an input, and only in single select cases. For this feature to be handled fully, it will need to also handle the scenarios I've mentioned above.

mynamesleon commented 4 years ago

@botmaster @mh-nichts I've made an adjustment based on my original thought for how this should work, which will synergise with the confirmOnBlur option.

I'm going to go ahead and merge this and publish the latest version to npm. But if you notice any issues, or would like to review the PR (even after the merge), please let me know and I'll try to make any further updates as soon as possible.

mh-nichts commented 3 years ago

Thanks for the change !

We handled our option keepUserInput with a particular scenario in mind : when using a text input, that means that the user is free to input whatever text they want, which is different from select/checkboxes where the list of options is constrained. Let's say for example a search form : the autocomplete system might offer some suggestions, but probably not all the words available in the final results. That's why we'd have to let the user input any string. As a result, we didn't go as far as to create custom new options, which is indeed a completely new (and complex) functionality.

We don't need this functionality for the moment, but when we do, we'll test it further and let you know if we see any issue.

mynamesleon commented 3 years ago

Yes I've definitely gone for a more complex approach! It seemed like the most appropriate across all of the possible option combinations though.

I believe (or at least hope) that when using a text input in single-select mode, my approach is functionally equivalent to yours. Your change is ultimately persisting the custom value and setting it on the original input within the handleComponentBlur method. Whereas my approach adds the custom value to the generated list to be matched against when the confirmOnBlur behaviour is active.

The extra complexity I didn't mention above is handling the kept input value (e.g. for a form where you can save your edits and return to them later). So the option needs to also allow a custom value in the original input to be retained. I didn't actually cater for that in the PR linked to this issue, which is why I then had to do an additional bug fix release after 1.2.0!