Select component with data source - allow custom input?

[z47co]

Hi,

We are evaluating Form.io as a solution for mobile/offline data collection. One of the scenarios I haven't been able to map cleanly is pre-populating a select component with a Data Source while also allowing custom input.

For example, this select component has three options. A user may need to provide custom input, but the field automatically clears when the input does not match an existing option.

Is this possible to implement without adding a conditional text field to allow "other" input?

Keep up the great work!

[z47co]

Dug a little deeper - looks like the Choices.js lib is close to adding support!

Choices-js/Choices#525

[randallknutson]

We currently don't have support for this. One of the primary reasons why is that the underlying data behind a select option is often an object. Users can only enter strings so it doesn't work correctly to map the string to an object. For now the best solution is to use a conditional field as you describe.

[z47co]

@randallknutson Thank you for your expeditious reply.

One of the primary reasons why is that the underlying data behind a select option is often an object. Users can only enter strings so it doesn't work correctly to map the string to an object.

Forgive my naivety, but I don't quite follow your reasoning. Handling a custom input seems like it could be implemented by simply replacing the default "No results found" with an href that invokes a custom function to apply the inputted string, perhaps with dynamic text such as "Add %input."

After all, isn't the value of an HTML option element a string at the end of the day?

Anyway, I super appreciate your team's vision and effort!

[randallknutson]

These aren't HTML option elements but choices.js rendered selects. There is an item template that renders the object down to a string. Thus the actual value stored in the database quite often is the object with lots of extra data in it, not just the value string.

We are definitely open to adding some functionality like this but the reason we haven't yet is that it is actually remarkably tricky to implement in a way that supports all the ways our select can be configured. If the select was just a simple key/value pair that stored as a string it would be easy.

[z47co]

Thank you for the information!

[franke-mc]

@randallknutson : This is currently being discussed in Choices PR#594. Also relevant: alternative Choices PR#525 / Choices issue #39.