Feature Request: Ability to add a caret icon

[sodapopcan]

Hey Max!

Would you be amenable to adding an optional right-ride icon, like in select boxes? It's nice in scenarios where you want to indicate that some default options will be shown (or even potentially all of them). I'm currently having to hack it in by wrapping live select, absolutely positioning the icon overtop of the input, and adding an additional hook to send a focus event to the input when the user clicks on the icon itself:

I'm happy to take on this work but I wanted to ask first.

Thank you for your work on this library!

Andrew

[maxmarcon]

Hi Andrew, nice to meet you here!

So basically, when you click the button, it will be just like clicking on the text input field (i.e. the dropdown will open and show the default options) ?

Yes, I'm definitely open to this. I think an open question would be how this button would work together with the clear button (see the "allow_clear" option here). However, I suppose this caret button will be shown only if nothing is selected, right? In which case it will never have to be displayed together with the clear button, so no problem there. Otherwise, we'll have to think of something.

My only general suggestion/request would be to render the button as caret by default, but to make it configurable via a slot, so people can render whatever button they want there if they want a different one. That's also how the clear button works (it's an "x" by default but you can override it with the clear_button slot).

Let me know

[sodapopcan]

Hey hey! Thanks for the response and sorry for the delay in getting back. For now I've been working on a fork that I am trying to do in a way that I can hopefully contribute back, but I'm worried it will get a little hairy.

Yes, I'm definitely open to this. I think an open question would be how this button would work together with the clear button (see the "allow_clear" option here). However, I suppose this caret button will be shown only if nothing is selected, right? In which case it will never have to be displayed together with the clear button, so no problem there. Otherwise, we'll have to think of something.

In our design system, it actually shows both the caret and the clear button! So then it becomes an issue of perhaps needing to provide too many options. I could be over-thinking what this library should provide vs what the user should take care of on their own.

There are three more issues. I can create dedicated issues if you would like to discuss further but I figure I would just mention here first:

• First isn't a huge deal but I would like to be able to provide a slot for tags. I would like to use the tag component from our design system directly instead of having to rejig the CSS to match live_select's markup.

• I'm not sure how you would feel about this one but it would be nice if live_select could also act as a, uhhh, "dead" select. I assume this was probably an explicit decision by you (and apologies if I have missed this in the docs) but we have several multi-selects with a finite number of options that would be much simpler to just pass options={@options}. Saving a round-trip is a nice bonus.

• We need keyboard navigation.

I'm than happy to work on all of this stuff. I have to do it anyway with or without LiveSelect, but would much rather contribute back!

What do you think??

[sodapopcan]

PS, to clarify I know there is options already but I mean an option not to trigger the events to the server on change. Although again perhaps I'm overthinking this and what I'm looking for is possible on this point as is. I've been a little overwhelmed the past week.

[sodapopcan]

OMG, I see there are already slots for tags 🤦

[maxmarcon]

In our design system, it actually shows both the caret and the clear button! So then it becomes an issue of perhaps needing to provide too many options. I could be over-thinking what this library should provide vs what the user should take care of on their own.

I'm fine with showing both caret and clear button, even if it means adding another option

To your issues:

First isn't a huge deal but I would like to be able to provide a slot for tags. I would like to use the tag component from our design system directly instead of having to rejig the CSS to match live_select's markup.

You found out that this is already a thing :)

We need keyboard navigation.

That is already implemented. You can navigate the options with the arrow keys and select with the enter key. Doesn't that work for you out of the box? If it doesn't, please open an issue

I'm not sure how you would feel about this one but it would be nice if live_select could also act as a, uhhh, "dead" select. I assume this was probably an explicit decision by you (and apologies if I have missed this in the docs) but we have several multi-selects with a finite number of options that would be much simpler to just pass options={@options}. Saving a round-trip is a nice bonus.

Wouldn't this "dead select" be just like a standard HTML select element or something in between? What would be the difference between a static HTML select and the dead select?

[maxmarcon]

For now I've been working on a fork that I am trying to do in a way that I can hopefully contribute back, but I'm worried it will get a little hairy.

That interests me. When people work on a fork it means that something important is missing. Was it only the caret button or some other missing feature that made you decide to fork you own version?

Btw: I'd be very happy if you'd like to contribute to the project. This and next week are kind of crazy for me (I'm moving to a new place) so apologies if I won't always respond swiftly.

[sodapopcan]

Max,

So sorry for my poor RTFM'ing abilities 😮‍💨 I've had a pretty bad couple of weeks and a bit overwhelmed and was in "just get this done however I can" mode. So yes, keyboard navigation works great (I had broken it on my fork 🤦 ) and adding in the caret is simpler than I had made it.

I've simplified my fork and will add the caret in a compatible way and PR it when it's solid.

As for the "dead select," the reason would be to get the multi-select without having to make a whole different component. Also, I think we're going to use the same style for regular selects (even if I don't think it's the best idea, we'll see). In any event, it's not the worst to re-create or maybe there is a better way I am not thinking of.

Thanks for your detailed responses and apologies for not lack of attention to detail!

[maxmarcon]

Andrew,

no worries at all! I'm also going through a couple of very intense weeks.

I've simplified my fork and will add the caret in a compatible way and PR it when it's solid.

That sounds great, looking forward to your PR 👍 If you have any questions or need help, don't hesitate to ask here.

Thanks

[maxmarcon]

As for the "dead select," the reason would be to get the multi-select without having to make a whole different component. Also, I think we're going to use the same style for regular selects (even if I don't think it's the best idea, we'll see). In any event, it's not the worst to re-create or maybe there is a better way I am not thinking of.

The styling aspect makes sense, you could copy and paste an already styled live_select and set the "dead" flag whenever you need an ordinary HTML select with same styles. Doesn't sound hard to do and potentially useful. Will give it some thought as soon as I find some time

[sodapopcan]

It's not just styling it's re-implementing the tags as well. Again, not that this is a huge deal or anything, but it's helpful to have them using the same code.