Select2 opening behaviour

How Do I...
#1

Hey,

I’ve been using Select2 in a number of ways and it’s been pretty great, but I’m a bit stuck on this particular issue.

I’m using Select2 as a main website search box - so you click on the search box, the search field/menu opens and as the user types a search, you get live results populated by ajax, and it works great (basically like the search box on this site). However, as Select2 is really a menu replacement, you have to click on it once to open it to get the text search box.

When Select2 is in pillbox (multiple selection mode), the search box is permanently available, which is my preferred behaviour for a website search box - the text field is “open”, you can just type into it to get live search results.

Is there a way I can use this “multi” mode display behaviour to leave the text search always available, without having the multi/tag behaviour, which isn’t applicable in this context?

Thanks - in the meantime, I’ll continue to search around tor tips…

#2

I don’t understand this statement: “you have to click on it once to open it to get the text search box”. It’s true that in its “closed” state the Select2 widget does not display a text field, but its display looks like a text field (or can be made to with a bit of CSS). Even if it were a real text field, the user would have to click on it before they could type into it, so the user interaction seems to be the same either way.

However, the basic answer to your question is “no”, there is no way to suppress the “pillbox” behavior with a multi-select Select2.

One alternative you might consider is to programmatically open the (single-select) Select2, configure it not to close automatically when a selection is made, and then use some CSS and/or JavaScript to hide the dropdown until the AJAX call returns some results (and to hide it again when the user focuses elsewhere on the page).

#3

Hi - thanks for the reply - much appreciated.

Even if it were a real text field, the user would have to click on it before they could type into it, so the user interaction seems to be the same either way.

No, the interaction is unfortunately not the same. It’s bit more clunky than just a straight open text box, and the main problem is that on mobile (iOS) the experience is very different - you have to click once on the search field to open the search box, then you have to click again on the now open text field before the text cursor will become available and you can type your search query.

If the search field was a normal text box (like in pillbox mode), then on mobile, you’d just click once to target the search box and can start typing, and it’s a much better experience.

Having to click twice before being able to search is a poor experience I’m trying to improve.

When I looked at this before, I’m not sure if I tried to automatically focus the text box when select2 opens, but if I can do this it might be a workaround for the time being.

I’m not sure I quite get/understand what you describe as the alternative option…

#4

Ah, you didn’t mention you were focused on the mobile experience. In any case, I made a demo on jsfiddle.net to demonstrate my suggested alternative: https://jsfiddle.net/jpisello/zngw8dx9/150/. It needs some more CSS work (to remove the border around the text field container and the whitespace above it), but it shows the basic concept. (My demo searches GitHub repository names, so you can type almost any word and get a bunch of hits.)

#5

Ah - I get what you mean now.

Yes, that looks like it’s worth investigating - thanks for the suggestion (and for rigging up a demo)…

#6

You’re very welcome.

1 Like
#7

I’ve been playing with this today, and I don’t think I’m going to be able to get it to behave in the way I’d like (ie, with a display like pillbox mode, but a behaviour like single mode).

You demo was useful John, thank you. Forcing select2 to be open at the start places the text cursor and steals key focus, which doesn’t work for me - I do want to be able to click once into the search box to then take focus. There might be a way around that, but it eluded me for now. Also, there are problems with initialised parts of select2 being drawn then hidden, which then repositions the search box while initialising which is ugly.

I’m also using the select2 plugin to maximise the results height, and this also forces some ugly redraws and movements when you use this method with bits of select2 hidden, so I had to remove that.

It may be possible to find workarounds for all these things, and restyle the text box so it’s less ugly, and add placeholder text etc… but it’s starting to require so many workarounds that the whole thing feels… well, not very elegant.

I’ll play around and see if I can come up with anything better than what I have now.

So thanks, it was a good idea that was worth exploring. Shame. Select2 is really nice in pillbox mode… :frowning:

1 Like
#8

I agree with you that lots of hacks probably means you should try a different soluiton.

The “right” solution is to provide your own Adapter implementations (probably the SelectionAdapter and DropdownAdapter). Unfortunately there isn’t much documentation on how to write Adapters. If you google “select2 adapter tutorial” you might find some helpful results. I found one a couple of years ago, I think, but I didn’t bookmark it.

Absent that, you’re probably better off rolling your own or finding another UI widget library that provides something closer to what you need.

Good luck with your project!

1 Like
#9

Thanks John - yes, ultimately I think I’ll find a different solution, or roll my own, as Select2, great as it is, really is meant to be a menu replacement, rather than a search box.

Really appreciate the help though, thank you!