[Improvement] UI: Introduce "Autocomplete" for UI > Input > Field > Text

[mBeym]

This pr adds autocomplete similar to the already existing autocomplete for tag inputs or legacy ilTextInputGUI.

Why this is needed

Some views in ILIAS currently still use the legacy ilTexInputGUI. Since they need a text input with autocomplete, using ks inputs is not possible since there currently is no text input with autocomplete.

[kergomard]

Hi all

Why can't we not use the Tag-Input in these cases? I'm against using this for anything related to a user (as shown in the screen shots above). We should use consistent inputs for this. I would postulate that all inputs linked to user information MUST use the Tag-Input (or come up with a new User-input).

Best,
@kergomard

[mBeym]

Hi @kergomard,

Thanks for your reply. We (think we) understand your thoughts and concerns.

First, the screenshot was just a quick example of how the autocomplete dropdown would look.

The actual use case is selecting exactly one local role in the global authentication administration. An administrator needs to search through all local roles in the entire ILIAS installation to select one.

Why Text-Input with Autocomplete?
We believe a Text-input element with autocomplete is particularly useful when:

• The range of possible entities is large, and
• The user must find exactly one element

Examples: searching for a local role name, a repository object, a location, etc.

We do not expect that all consumers will use the Text-input element directly. However, we think developers from different domains can benefit from this general concept and build domain-specific wrappers around it—similar to how you built the "User" component using the Tag-input element.

We think a Tag-input element is not suitable when the user must select exactly one entity. As a user, I would not expect to use a Tag-input (designed for multiple selections) when I need a Text-input (for a single selection) just because it's the only one with autocomplete functionality.

This could also be relevant for plugin development (though plugins are not our primary focus in UI framework development), and we believe the community would appreciate this flexibility.

I initially attempted to make the existing Tag-input usable for selecting exactly one value. However, this didn't work well with the Tagify package. Instead of forcing this functionality into a Tag-input, I considered it cleaner to add autocomplete functionality to the Text-input element.

Best regards,
Marvin

[kergomard]

Thank you very much for the explanation @mBeym

I still think this is a bad idea as there is a Tag::withMaxTags() that is the right way to achieve what you want. Text inputs do not clearly show limits of their input, they have no structure, so I think it is a bad idea to use autocomplete on them, as it is hard to really visualize what has been autocompleted.

I clearly leave the general concept to the UI-Coordinators, but as the Authority for AccessControl I kindly ask you to also never use this for anything related to AccessControl and to have this as well as the restriction on use with the User clearly stated in the Usage-Rules.

Thanks and best,
@kergomard

[mBeym]

Tag::withMaxTags does not prevent the user from adding more than one tag to the input, it just returns an error in the form validation.

[kergomard]

That is perfectly fine behavior and does not change anything on what I say above. What I said above stands: I will not support any usage in AccessControl and User related contexts.

[thibsy]

Hi @mBeym,

Thx a lot for your contribution to the UI framework!

I don't think the Field\Text input is the right choice either. I believe what you really need is one of the Field\HasOptionFilter components – maybe extended in some way.

It feels like your proposal is forcing the text input to serve a purpose it wasn't designed for. A text input accepts arbitrary strings, so supplying it with pre-assembled values to identify roles on the backend later on feels very unstructured. Results would be easily manipulated and additional JavaScript logic would be required to prevent (accidental) tampering.

Inputs like Field\Select or Field\Radio on the other hand provide a much more structured way to achieve this, since newly added data can be rendered as similar HTML elements, which cannot be easily tampered with. It also allows you to separate display-value and actual value to i.e. solve translation issues, which your proposal cannot.

Nonetheless, please answer the following questions:

• Async: I am unfamiliar with the use-case, but is it really necessary to load options async, or is filtering them enough? IMO if we are not talking about thousands of roles being loaded, I would simply send them synchronously.

Kind regards,
@thibsy (as UI coordinator)

[mBeym]

@thibsy,

In the example I made, selecting for a Local Role loading the options synchronously would mean showing/loading the roles for every object ILIAS has. I do think this should be done async.

Edit:
From our own customers we know that the number of local roles may reach more than 100.000 easily.

[thibsy]

Hi @mBeym,

Thx for the feedback.

I can see how loading this asynchronously makes sense then. Could you have a look at this PR #8802, or the according examples inside the (latest) Kitchensink documentation, and tell me if this behaviour might fit your needs?

From a technical standpoint, I feel very strongly that this kind of data-flow, with using string values from a text field, is just too brittle. If the look and feel of these HasOptionFilter components fit you, we may introduce a very similar implementation, but for e.g. HasAsyncOptions components, so that we do not filter but search for options instead.

Feel free to contact me here or on Discord to discuss this idea.

Kind regards,
@thibsy (as UI coordinator)

[mjansenDatabay]

Hi @thibsy,

Thanks for pointing to the HasOptionFilter PR.

From our (I mean the community, not Databay :-)) users' perspective, this element would indeed fit their needs.
And as you already anticipated, from a technical point of view, a HasAsyncOptions interface for asynchronous data loading is essential for scenarios where the number of searchable records is huge, as loading all options upfront would not be feasible.

@mBeym will have a look at the implementation of HasOptionFilter to evaluate how we can proceed. Don't worry, we won't move forward without coordination. As we currently have no funding for this (we were just asked to estimate the costs for migrating the form to KS/UI), we'll make sure to align on the approach before any implementation work begins.

Best regards,
Michael