Reusing SearchSelect for string fields limited to specific values

[TrevorHinesley]

I'm going to be rolling something like this on my own by overriding the form component and either reusing or abstracting the SearchSelect component, but it might be nice to -- out of the box -- allow a definable options attribute for specific fields (or something similar), which, if used, leverages the SearchSelect functionality to act like a select box with autocomplete.

[tfwright]

For LiveAdmin form components, the guiding philosophy has been that their behavior is 100% determined by field type in the Ecto schema. So if something has a set number of options the expectation is that in most cases this should be an Ecto.Enum field which is controlled by a non-search select. I'd like to continue that policy so as to keep things as simple as possible, with overrides for anything custom.

That said I recognize that overriding the entire form component is a pretty heavy handed solution. For similar reasons we introduced the render_with option to make customizing how fields are displayed on the list view possible without overriding the entire component. It might be possible to do something similar for forms using something like input_with. The main problem with that approach is that the form fields are a lot more coupled to the parent form component than the table cells are to the list component.

Can you explain a bit more about your use case, specifically why using an enum/select field isn't a good fit?

[TrevorHinesley]

I completely understand your position.

To answer your question about enum/select: I have a few string columns that don't work well as enums for a few reasons.

1. The future selectable options might change. While I could create an enum with gaps between the numbers to account for this, that's not ideal and is hard to maintain. Keeping it a string allows me to maintain older values, but validate new ones if the allowed options change.
2. Some of these fields have a lot of options (hence the autocomplete functionality being beneficial). That's hard to maintain as an enum.
3. At least one of these fields, in the consumer-facing application, is more of a typeahead with possible autocomplete options, but the result is still a free-form string. It's more of a "here's a bunch of potential options based on what you're typing" field, such that you can click one if it matches what you need, but it's still a free-form text input such that that's not required.

So for those reasons, a string field with hardcoded options (whether or not option 3 above is possible to be supported or not) would fit my use case better.

[TrevorHinesley]

I realized the title of this was confusing too, so I just updated it. My enum verbiage in the title was more so about having multiple pre-defined options rather than the enum type itself. Based on your response, you picked up on what I meant anyway :)

[TrevorHinesley]

Another example: I have a field that's an array of strings from a pre-defined list of options (basically a multi-select), but adding a new value to the array in the edit form doesn't offer the SearchSelect functionality for autocomplete or a select dropdown.