Improved item selection for associative fields

[sedubois]

What would you like to be able to do? Can you provide some examples?

It would be great for associative select fields in edit forms to have broader capabilities:

• loading items asynchronously and/or with pagination to support choosing from thousands of items. The current solution can overwhelm both the server and the browser if not careful as all objects are loaded in memory. E.g consider a dashboard auto-generated by Administrate with a user BelongsTo field, it will load the entire user table in memory. The workaround is to replace user with user_id, but then we lose the benefit of searching through and previewing users.
• customizing the data shown for each item as well as how they are styled
• Responsiveness: adapt to screen size and be able to use all the real estate on bigger screens, e.g. full-screen modal popup with columns (e.g a picker to pick items from a media gallery). This would be particularly helpful for more visual items such as ActiveStorage blobs (mentioned here and here).

How could we go about implementing that?

The idea I currently like the most would be to directly use Administrate's own capabilities to list, search, filter, order and paginate records. Clicking the select field on the edit page would open a popup where the index view of the associated field could be listed and searched. The user would be able select the relevant item(s), then validate their choice and close the popup, which would populate the form's select field with the selected record(s).

It would allow to benefit from all of Administrate's current and future features such as configuring what the listing should look like (through the dashboard config), search, filtering, ordering, pagination, etc. It would avoid relying on external libraries and make for a coherent UX.

One drawback I can think of is that currently I think Administrate doesn't have real-time filtering, i.e. the search box only performs the search when submitting. It would be great to be able to update the filter on every keystroke like Selectize does (more on that below). We could try adding that feature in the future, which would automatically bring the enhancement at two levels: when searching the association field as well as when searching in the regular index views.

Can you think of other approaches to the problem?

Administrate already uses Selectize.js drop-down menus for its BelongsTo and HasMany fields, which provides helpful keyboard auto-completion and navigation. We could add a way to pass options to Selectize in order to customize the HTML of each item as well as to load data async. This is probably the easiest solution to answer some of the aspects described here in the short term. However Selectize appears unmaintained and based on jQuery so I'm not sure if building more features on top of it is preferred in the longer term. @pablobm also mentioned that we want to be able to easily move away from it, which might become more difficult if we hook into more of its features/config.

I also came across Select2 which appears well maintained but is also jQuery based so this might be a better alternative.

Choices.js is "similar to Select2 and Selectize but without the jQuery dependency". Unclear how flexible it is in terms of displaying the items.

There is Algolia InstantSearch but I suppose whatever free version there is is probably limited, and we probably want something that works out of the box.

Tippy.js describes itself as "the complete tooltip, popover, dropdown, and menu solution for the web, powered by Popper.js" but despite mentioning dropdowns, it doesn't actually seem to offer features related to that (e.g search and filtering etc).

None of these other approaches appear to offer responsiveness or displaying in a bigger gallery format and they would make the UX for listing/searching/filtering/ordering different from what it is on the index views. As they all rely on third-party libraries with different mechanisms than what is done in the index views, it would also decrease the library's maintainability.

[nickcharlton]

To expand on the jQuery/Selectize point: We're been discussing a plan to remove jQuery currently in #1469, which is also bought in for the datetime picker.

If we were to add a dependency, ideally it wouldn't involve pulling in any other JavaScript if possible and be standalone (i.e.: not rely on an external service).

[pablobm]

My initial thoughts as to how this could work:

1. Administrate to provide an API endpoint that returns a list of potential associated records, probably as JSON. It would need securing with authorization.
2. The template for the select field would include a data attribute or similar, indicating where the API endpoint can be found for the given association.
3. Some JavaScript would put together the two elements above.

I think this should decouple the chosen JS library and presentation from the functionality. Users can change the JS to present things differently while reusing 1 and 2.