dropdown: enable mutliple selection by default

[jrcastro2]

• Adds support and default implementation for multiple selection
• closes 1 - Enhance e-mail notifications CERNDocumentServer/cds-rdm#628

[kpsherva]

not sure I understand why we need to add state management for this component, could you explain me?

[jrcastro2]

Sure! We need to add the options to the state because now they are not static only. On a traditional SelectField you would pass the options before (such as vocabularies) but now for the emails for example we want to allow to add new values on the SelectField, to display these values we need to add them to the options as well alongside to the already default static ones passed, otherwise they will not show in the field itself. And also we need it to update the options as we add new items to it manually.

[kpsherva]

we were already able to add new options in the keyword field (deposit form), can't we use the same component, instead of changing the select? I think Select is specifically done so you can select from an existing list, not to add new ones
It would be better to avoid complex component, and have them handle a single responsibility

[jrcastro2]

Hmmm, the keyword field in the deposit form that you refer to uses a more the RemoteSelectField, which performs async searches against an API endpoint to fetch predefined options. What we need here is the ability to add arbitrary values (like email addresses) that don't exist in any backend list. allowAdditions is a standard SUI feature. I agree that the implementation of this feature looks a bit complex, at the same time I believe is a feature that belongs to the SelectField and that enhances the usability of this field, while keeping it backwards compatible.

Happy to discuss further about this if needed.

[zzacharo]

@jrcastro2 as you said the allowAdditions is already a SUI feature, why do we need all this logic for the static selectfield? Also, in case we indeed need it can we reuse some of the logic in the RemoteSelectField so we dont maintain separate in-component logic?

[jrcastro2]

The need for this feature in the selectField relies on being able to have the selectField and add new values to the dropdown. When we want to add a new email we need to write it and add it, so this is a new value. The emails are not pre loaded as options in the selectField but aded dinamically as the user inputs them. Once saved in the DB they will be loaded as options in hte field, so that they are displayed. The RemoteSelectField expects to perform api calls on every input change so that it searches for the values and fills in the options. The use case is slightly different, anyway I will have a look to see if we can reuse some logic.

[zzacharo]

I understand the difference but I would expect that after the API response, all the option handling to be somewhat similar no? Maybe a quick check and if it is not easy we can maybe just add some comments and move some code blocks in functions to improve readability at least?