Replace Selectize with a web component

[nickcharlton]

We've always used selectize for combo boxes, especially when it comes to multiple selection. It's a nice project with a lot of functionality, but I've always wondered if it would be possible to replace it with something driven by web components.

Today, I saw that Web Awesome — a UI component kit by the folks behind Font Awesome — have added a combo box: https://webawesome.com/docs/components/combobox

I'm not sure yet what the path to doing this would look like, but if we can cover all of the functionality using a custom web component, I think that'd be really cool.

The required functionality for a drop-in replacement looks like this, I think:

• Type to filter
• Drop down
• Placeholder
• Clear button
• Filtering when typing
• Multiple values/pills

Is there anything else?

(I think it's potentially worth linking new functionality here as well, if not just to group them together, as when working on a new solution it might be nice to keep going with new features.)

[goosys]

@nickcharlton
This might be a bit of a presumptuous opinion, but I personally think this kind of functionality should be provided as a plugin.

In this repository, I’d prefer to see only a simple Field::Select based on plain HTML5 select and radio inputs.
Then, users could choose whether to add a plugin for Selectize, a plugin for Web Components, or something else, depending on their needs.

To make that possible, wouldn’t we first need some underlying infrastructure to support this kind of extensibility?

For example, if this were provided as a plugin like Field::SelectWithSelectize, replacing every Field::Select across all Dashboard files would be quite cumbersome.
In such cases, it would be nice to have a mechanism where you could, for example, alias Field::Select to Field::SelectWithSelectize in an initializer, or inject some global default options for Field::Select.

[goosys]

Also, once Looks is merged, developing this kind of plugin will become much easier.

We won’t need to create a new Field class for each plugin like we used to. Instead, a plugin would only need to provide something like:

views/fields/select/looks/selectize/_form.html.erb

(There’s no need to add index or show templates, since they would fall back to the existing select templates.)

If we want to support plugins like this, we’d also need a base feature that allows setting looks: :selectize as the default for Field::Select via an initializer.

Wouldn’t it make sense to introduce that kind of mechanism first?

[nickcharlton]

This might be a bit of a presumptuous opinion, but I personally think this kind of functionality should be provided as a plugin.

Yeah, I'm kind of with you there. I think if I were starting from scratch, I'd not include it. But to remove it would take away a significant part of Administrate's user interface for all but the simplest situations. It also begs the question of if were to remove this, why are we trying to add in a lot of other features, etc?

I’d prefer to see only a simple Field::Select based on plain HTML5 select and radio inputs.
Then, users could choose whether to add a plugin for Selectize, a plugin for Web Components, or something else, depending on their needs.

For example, if this were provided as a plugin like Field::SelectWithSelectize

This is more compelling though! Hmm!

Perhaps Looks is indeed the right solution here. We should revist this then, I think.

[goosys]

But to remove it would take away a significant part of Administrate's user interface for all but the simplest situations.

From my experience using this in my own applications, I don’t actually need a single, all-powerful Select that does everything. What I usually want is a Select that’s customized per attribute field.

For example: grouped selects, multiple selects, a theme switcher with thumbnails, different appearances per BelongsTo, and so on.

Because of that, I think a generic, feature-rich Select is better suited as a plugin (and the same applies to a Web Component–based version).

Perhaps Looks is indeed the right solution here. We should revist this then, I think.

I think Looks is very useful.
Are there any remaining concerns that are preventing it from being merged?