Allow users to add additional options to the select widget directly

[josh-unwin]

As per the react-select module, it would be great if Netlify CMS could allow users to add additional options to the select widget directly from itself.

The difficulty here is whether this added option can be plugged into the options list in the config.yml file.

[kwyoung11]

@erezrokah @erquhart Interested in tackling this issue. Does this ticket cover adding new options to the relation widget as well, or should a new ticket be created for that?

My first thoughts for an implementation would be:
Display a modal to add a new option to the select. The modal would contain the relations fields for the user to fill out. The modal would have Publish and Cancel buttons (you won't be able to save a draft of the relation you want to add). Once the relation you want to add is Published, it's added to the relation widget. Side note: If this option is taken, might need to resolve #1571 first before working on this, as I assume only collections that do not have editorial workflow enabled will be supported here.

Motivation/Use Case

The simplest use case where I see this being extremely useful is with tags, where you may have a tags folder collection with just a single title field.

For example, imagine you have tags and posts collections, and tags is implemented as a folder collection in config.yml. I want to be able to create new tags from a relation widget inside a post entry without having to leave the post entry. From a UX perspective, it's quite tiresome to have to click back to the dashboard, click on the tags collection, create new tag, add the tag, save, set ready status, publish, go back to dashboard, find original post entry, then finally be able to add the tag to your entry. Would be very nice to be able to just create it inline on the post entry.

Thoughts?

[erezrokah]

Thanks @kwyoung11, I think this would only cover the select widget for now.

Instead of changing the config.yml (which will probably trigger an unwanted CI build) the widget could support an additional allow_add flag and then save the additional options under the entry data, e.g.

options:
 selected: string | string[]
 additional: string[]

That would mean the widget would need to support persisting an object instead of the current list or string.

WDYT?

[erquhart]

Note: this issue ties into #192, which calls for making related changes in one entry from another entry - in this case adding a tag to a centralized tags data file from an entry that will reference the tag. That part of the request is a duplicate.

To echo @erezrokah, the core ability to add arbitrary values to a select, without persisting that value to any centralized, reusable set of values, should be really simple. I would even suggest that the selected/additional dichotomy may not be necessary - allow_add could just allow any value to be added.

Also wondering if we can serve the tags use case with the relation widget as it currently works, with added logic for reducing the related values list to unique values only, and allowing relation widgets to reference the current collection if that isn't already possible. That might serve the majority of tags requirements quite well.

[AbdallahAbis]

@kwyoung11 @erezrokah Any plans for adding this? or a workaround to implement this to my project?

[erezrokah]

Hi @AbdallahAbis, the best way to move this forward is through a contribution.

[AbdallahAbis]

@erezrokah any guidelines for someone who wants isn't a contributor and wants to contribute? Any help.

[erezrokah]

Hi @AbdallahAbis you can see our guide here.

The select widget code is here.

Please let me know if you have any other questions.

[AbdallahAbis]

@erezrokah Could you tell me where should those newly created options be stored?

[erezrokah]

@erezrokah Could you tell me where should those newly created options be stored?

Hi @AbdallahAbis, well I'm not sure. See #3821 (comment) and #3821 (comment).

The additional options can be saved as a part of the entry. That however means they will only be available per entry and not globally.

[AbdallahAbis]

@erezrokah Why can't we extend the widget options and pass it the additional options by updating config.yaml?
What do you mean by unwanted CI build

[erezrokah]

@erezrokah Why can't we extend the widget options and pass it the additional options by updating config.yaml?

Hi @AbdallahAbis, updating the config.yml means committing it back to GitHub (either directly to the default branch or via a PR). That means a build will be triggered due to the code change and also the CMS would need to wait for the build to complete to reload the config.yml file.

[AbdallahAbis]

@erezrokah So I've thought about it and I have an idea but I don't know if it will work or not as I haven't yet tried it.

• Let's say we have a collection of articles
• We have a field of tags on that article which is a list widget and can be either single or multiple.

We can change the list widget to be a Creatable component when the allow_add flag is true.

The new values added will be stored in the data entry (e.g. article.tags), the issue here is that they will not be available globally to other articles.

We can mimic the way Relation widget queries for fields, and we can query for the tags field and filter those tags to be unique then show them in the tags options in different articles.

My questions is:

• can we extend the list options when the user clicks on the field to choose an option so they can see all the queried and filtered tags? Just the way Relation widget works.

WDYT?

[erezrokah]

• Let's say we have a collection of articles
• We have a field of tags on that article which is a list widget and can be either single or multiple.

We can change the list widget to be a Creatable component when the allow_add flag is true.

Hi @AbdallahAbis, do you mean a select widget here?

I'm not sure we need the relation widget. Having an allow_add field will allow users to add any value which we will save on the entry. Next time the entry is loaded any custom values saved with the entry will be available for selection.

Please let me know if that works