Add isOpen Prop

This has been discussed across a number of issues and PR so let’s collect ideas here.

Replaces #817 #962 #1015 #1950

I’m not a fan of the idea of an isOpen / alwaysOpen / forceOpen prop from a UX perspective, and don’t want to complicate react-select more than absolutely necessary. However, it’s been such a popular request that I’d like to hear out the arguments and solutions for it.

My concerns are:

UI / UX Consistency and intention

Much of the control’s design assumes it’s opened in response to user interaction, temporarily; this impacts the styling (e.g. pointer over options), keyboard navigation that expects the input to have focus which would be inconsistent, and the behaviours like closing the menu on esc would have to be rethought if the menu didn’t respond to them.

Accessability

A screen-reader would go through the entire list of options in the form, even when the select isn’t being interacted with (this is the problem that leads to “skip nav” links being added to sites). I don’t have a huge amount of experience with this though, so if anyone knows a way around it let me know.

Unpredictable height

@kajmagnus mentioned a use-case where the select opens over a save button. Having it always open should really inline the control so it takes up space in the layout, otherwise it’ll always obscure anything underneath it. Guessing at how much height to leave could be incorrect based on the number of options currently displayed (keep in mind as well that the number of items shrinks as the user types, which would create a really weird UX effect). If this is an issue, just wrap the whole thing in a fixed-height container.

Not how select controls work

All the native select / autocomplete controls I’ve seen are always only open when they’re focused, and they pop over other content. Boxes of things that are selectable have totally different designs and ux rules.

Dev mode is not a valid reason

This was discussed extensively in #927 - just use react dev tools to override the state.

---

There’s really a lot to rethink and redesign for this use-case that no PR yet has worked through.

A valid reason for supporting this prop might be needing to control the open state based on some other state… but at this point we have different options:

• If you want to trigger the select to be open (and then respond to focus / blur / select events as expected) then just set the focus
• If you want the control to always be open (and never close), it needs some nontrivial design updates for that to make sense, and I’d argue should be a different type of component (not a select)
• If you want to control the open / close state of the control based on external state (e.g. redux store) you’d need to also handle a whole bunch of events for when to close it, which would (I think) require a whole lot of additional handlers (maybe a new onClose function prop?) - I just can’t understand why this would be necessary but am open to learning why it is

So with all this in mind, I’m going to close the other issues and PRs related to this to reduce noise in the repo. If this is an important and valid feature for react-select, make your case here and if it makes sense then we can work out how it should be designed. Please don’t just reply with “this is really important to me” - I need to understand why it is.

Thanks

[wamujlb]

isOpen or alwaysOpen is really important property. Sometimes we need it. We all can make a fork to add this prop, but I think it should be there.

[andyford]

After spending 20 minutes trying to figure out why state.menuIsOpen wasn’t working as expected, I realized it’s accessible via state.selectProps.menuIsOpen … hope this helps someone else.