Added isFocused to several components

[dkniffin]

Several components were not receiving the isFocused prop, because it had to be passed in individually to each one. I've refactored it so that isFocused is part of the commonProps object which gets passed into all the right places already. I also moved isDisabled up into that group, to remove duplication.

[dkniffin]

@JedWatson Would you mind taking a look at this?

[dkniffin]

Also, it looks there are a lot of other PRs that need some attention. Have you thought about adding a maintainer to the repo? I'm less familiar with this library, but I'd be willing to help take a first pass at some of the PRs and issues.

[karlingen]

Would you mind fixing the conflicts? :) I'm assuming it'll be prioritized if all other variables are in place

[dkniffin]

Conflicts resolved. @JedWatson or @gwyneplaine can you review this?

[dkniffin]

@JedWatson @gwyneplaine bump

[noslouch]

bump

[ebonow]

I'll take a look at this tonight or this weekend. Seems pretty straight forward and will add this as a candidate for next release pending no issues.

[ebonow]

Overall, the code seems sound. I also realize that not having these props makes the Indicators much more difficult to know when to hide/show.

I guess the one concern I have is the existing naming as isDisabled and isFocused both can be relative to the Select or the Component now that it is added to the commonProps.

I guess the question is, would the user know, for example, that isFocused refers to the Input and not the custom Menu component?

It seems that Option is the single exception of a Component that has these props but they represent something else. I did check that that the Option overrides the values isFocused and isDisabled but I fear that this might be confusing for other things like potentially a GroupHeading or MultiValueRemove.

I'll bring this to conversation this week and see what others think.

[kylemh]

Are you saying that <Select isFocused /> would lead to isFocused being true for all of the components or just you're unsure of the naming being the same across all?

I'm not worried about the naming since the distinction between:

<Select
  isFocued
  components={{
    Option: (props: OptionProps<{ value: string; label: string; }>) => <Option {...props} isFocused />
    ...reactSelectComponents
  }}
/>

is pretty obvious.

---

If it IS that the value propogates, I still don't think it's a big deal. I think it's already a bit confusing that we can check on whether or not the placeholder is focused... It seems that isFocused is meant to be a prop that any of the custom components can read from, making it obvious that it's for the <Select> itself.

[Methuselah96]

@kylemh I think @ebonow is saying it's situations like this where the isFocused prop on MultiValue is actually referring to whether that specific option is focused, not whether the entire Select component is focused (which is what it means in commonProps). This could cause confusion because isFocused could be mistaken to mean the same thing across all components (and there would be no way in MultiValue to reference the isFocused that comes from commonProps).

[Methuselah96]

I think ideally we would come up with a different prop name for either the general case or the differing specific cases. Unfortunately that would be a breaking change.

[kylemh]

Understood. As a non-breaking change we could document the confusing behavior of isFocused, deprecate the prop with JSDoc @deprecated, and then add a new focusStates prop which is an object type and the key matches each component name.

[ebonow]

I think ideally we would come up with a different prop name for either the general case or the differing specific cases. Unfortunately that would be a breaking change.

Here's the rub. For the default behavior, it is dependent on the input, for when isSearchable=false, it is the dummyInput, but in reality, it can be any element inside the SelectContainer. From there, any element inside it then propagates the keyDown handler to the SelectContainer used to control the Menu with arrow keys.

So technically only one thing ever can be focused and that focus determines a lot of things including the onFocus and onBlur callbacks. In fact as somewhat of a tangent, I'd like to consider replacing the dummyInput with some other focusable element to address this: #3526

Since none of the other elements ever receive focus, it's fair to say that isFocused is accurate and correlates specifically to the Select state, but of course that might change. I would say it's probably accurate as is, but again might not be clear, and from this, would we perhaps want to instead address the Option prop/state as maybe pseudoFocused or 'menuFocused` or something more clever.

isDisabled is another prop though that could potentially have an ambiguous context.

I'm trying to also balance the impact of #4195 as adding a disabled attribute to disabled options would be following best practices, but this would also remove any interactivity which means we may want to consider what it means to be disabled. It's also fair to consider that it should be implied that a disabled Select would not allow a Menu to be open unless the user specifies otherwise, and if it was, it should mark all options as disabled.

All that to say, yes this would incur breaking changes if we wanted to do any prop name changes, nor do I know what we would want to change or even if we should change. I simply want to err on the side of caution though it is already implied in many areas that this refers to the Select state (with the single exception of Option).

[Methuselah96]

Just to clarify, MultiValue also overrides isFocused (not just Option).

[ebonow]

Looks good.