Multi select support

[j-manu]

Tom-select has a good multi-select behaviour which can be replicated

1. Popover stays open after selection
2. Pills in the select input for each selection.
3. Pill will have option name on the left with an x on the right to remove it.

Nice to have

1. Free text option.

[fractaledmind]

These are great posts on multi-select behaviors with some user testing results:

• https://www.24a11y.com/2019/select-your-poison/
• https://www.24a11y.com/2019/select-your-poison-part-2/
• https://adrianroselli.com/2022/05/under-engineered-multi-selects.html

[josefarias]

Definitely do want to support multi-select. But to me it's one of those things where I'll have to see it first and then make the call.

There's tons of ways we can go about this. @fractaledmind's links above are a great reference (thanks for those!), so we might start there. But I really want whatever solution we land on to not feel like a library within a library. That is, I'd love if we could reuse most of what's already implemented in order to avoid maintaining two separate mechanisms, with two separate markups. Even if that means sacrificing some fidelity, although ideally we wouldn't sacrifice anything at all.

If someone wants to attempt implementing this, I think writing up a proposal here first would be good. This is a decision I'll most likely make based on the implementation.

Of course I might take a stab at it at some point, too. But not prioritizing it right this moment.

[josefarias]

Coming in the next release! #106

[josefarias]

Anyone using this yet? @jlw perhaps? How's it working out?

[jlw]

It will be about a month before I integrate this into my app (juggling other business priorities and I'm taking a week off with my youth robotics team to compete in world championships).

[josefarias]

Nice! Best of luck in the championship! 👏

All good. Hopefully you can let me know how the integration goes but no worries if you don't get to it.

[dylandamsma]

Trying to - but it;s not documented anywhere, how can we use it? :D

[josefarias]

Sorry to say you'll have to go spelunking in the codebase for now. I think the feature is mostly stable but I haven't finalized some aspects of it (see #13 (reply in thread)). I'll probably wait to document until a decision's been made on that front.

[pinzonjulian]

Hey @josefarias!

I'm experimenting with multiselect and I'm wondering if you could explain the reasoning behind multiselect_chip_src. Why do a roundtrip to the server instead of doing it in the browser? On slower connections or with slower responses it adds quite a bit of lag to the experience to something that feels like a front-end only interaction.

[josefarias]

Hey @pinzonjulian!

Of course! It's specifically to allow for custom html chips. I knew I wanted the flexibility there so that each app can design their own chips. So that's where I started.

I'm not 100% happy with it though, which is one of the reasons this is not yet documented.

I don't think the current implementation will go away. But I have been passively thinking about ways to do this clientside without sacrificing the ergonomics.

The default chip markup is super simple. So obviously we could just duplicate that in JS. But then we'd have to remember to keep them in sync. And that won't work for custom chips.

Ideally we'd come up with a way to support default and custom chip pre-rendering. I have a few ideas but hit me up if you do too and would like to discuss.