Keep selected option index after selecting value in multiselect

[5ebastianMeier]

Use Case

We have a multiselect control that is designed to select multiple users in succession. Currently this can be tedious because after selecting an option, the former selected position gets reset to start at the first option.

Example

• We have 10 entries (called 1 to 10)
• We move the selection to option 5 and press enter
• Option 5 gets selected and gets hidden from the options
• Now the selection is automatically moved to option 1, but I'd like to have the ability to let it automatically move to option 6 instead

Let's say you wanted to add option 6, 7 and 8.

With this new feature you could just navigate to 6 using the arrow keys and the press tab or enter thrice.
Without the feature you would have to navigate back to the next option after each individuell tab or enter press.

I couldn't find a working example in the wild, but I think the intention is pretty straight forward. If not, I'll gladly provide more insight.

[ebonow]

Greetings @5ebastianMeier ,

I could probably come up with a rough way of doing this by modifying the onMouseDown/onTouchStart events to identify the next option before calling onChange, saving the ref, scrolling the ref into view onMenuOpen.

I think your suggestion presents some problems as the index could change especially as user types or if selection in any way disables or changes the list of options which is why you may want to save a ref instead.

But for your use-case, setting closeMenuOnSelect=false seems like a much easier option if the intention is to allow the user to quickly add multiple items.

What are your thoughts about this?

[5ebastianMeier]

@ebonow thanks for mentioning the closeMenuOnSelect=false option - I'm already using that and it helped indeed. It still feels like it could be more comfortable when the user doesn't have to start at the top of the list after selecting an option.

The proposed solution via refs seems like the way to go - I'm not very deep into the internals of react-select yet though, just had a quick glance to make sure there's no such feature implemented yet.

I think you're right that other actions like typing a search term should have precedence over the "sticky selected option" I proposed above.

When applying the example on this use case, this seems like the appropriate behavior to me:

• We have 10 entries (called 1 to 10)
• User moves the selection to option 5 and presses enter
• Option 5 gets selected and is hidden from the options
• The selection is automatically moved to option 6 (when a new option like preserveSelectedIndex=true is set)
• User types in a search term
• The selection is automatically moved to option 1 and the former preserved selected index (option 6) is cleared
• User clears the search term
• The selection still resides at option 1 because the preserved selected index still has no value

Slightly more advanced use case where the preserved selected index could be maintained during a search:

• We have 10 entries (called 1 to 10)
• User types in a search term
• There are still 7 entries visible (1 to 7)
• User moves the selection to option 2 and presses enter
• The selection is automatically moved to option 3 (when a new option like preserveSelectedIndex=true is set)
• User types additional characters into the search
• There are still 4 entries visible (1, 3, 4, 5)
• The selection still resides at option 3
• User types additional characters into the search
• There are still 3 entries visible (1, 4, 5)
• Now
  • either the selection is automatically moved to the next visible entry after the preserved selected index (results in option 4)
  • or the selection is automatically moved to the start of the list because the preserved selected index is cleared when the referenced item disappears (probably easier to implement - results in option 1)

In a nutshell, these are the open questions:

What happens when a preserved selected index is present, but the associated entry gets hidden (e.g. by search or by being disabled)

• The next best option is selected (like described above)
• The preserved selected index is cleared and the first option is selected

What happens when the menu is closed

The preserved selected index should be cleared because the feature is only relevant as long as the menu stays open.

I don't want this feature to be too prominent and interfere with existing features. It should just close the gap where appropriate so that the selected index is not lost if not necessary.

Sorry for the rather unstructured wall of text 🤪 - looking forward to your thoughts

[ebonow]

@5ebastianMeier

My thoughts are that the behavior you are describing is too narrow of a use-case to be considered as a built-in feature request given the complexity of criteria, so this would be a pass from me and likely the other collaborators.

Perhaps better are some discussions being had in regards to #4080 to better define what the default focused option should be when the menu opens giving the user more control to define what should be selected.

Given your use-case and wanting to preserve the focus option, I would err on the side of simplicity and consider an existing implementation of Select that would better fit what you are trying to achieve. Since you are already using closeMenuOnSelect, have you also looked at hideSelectedOptions?

From a UX perspective, it sounds like the use-case is that the user is very likely to want to select consecutive items. Keeping the selected options maintains the context of the last selection as opposed to focusing an option that may appear arbitrary.

This would allow the selected option to remain focused which benefits the user by giving them more context as to what is focused. Generally this approach is better clarified by providing providing checkboxes in front of each option and seems more in line with achieving what the UX you are looking for. This approach also takes into account what happens if a user does open/close the menu or decides to type more filter text.

<Select 
  isMulti={true} 
  closeMenuOnSelect={false}
  hideSelectedOptions={false}
  {...otherProps}
/>

https://codesandbox.io/s/codesandboxer-example-forked-wdq8n?file=/example.js

If you are steadfast on your approach, then it could be complex to obtain with the existing api. For starters, it won't be as responsive as it would have to rely on onMenuOpen and as of now, the menuListRef isn't immediately accessible so a timeout is required to query it and find/set the option you'd like to focus on.

I'm believer that this library is not meant to be everything for everyone, but rather anything for anyone, so while I don't think the proposal fits as a feature request, I could try to assist with such an implementation for your own use-case if you create a sandbox.

[Kadrian]

Hey @5ebastianMeier and @ebonow thank you for your effort on this! I'm experiencing the issue in a similar way

• about 50 options in a multi select
• a user scrolls down, finds an item, selects it.
• the list scrolls back up, leaving the user confused, having to scroll again

Something like preserveSelectedIndex sound good, but in my case, simply "preserving the scroll position" would be enough, regardless of the next focussed option.

Would that make a difference in how complex it is to implement?

[Methuselah96]

Related to (or a duplicate of) #2813. There's a possibility that this is a bug because there is code that is trying to do something like this already.

[polakowski]

I'm having the same issue. I worked it around by saving ReactSelect instance to a variable by ref, and after changing option I select previously focused option manually. See below:

const onChangeOption = (selectedOptions, data) => {
  handleSelectedOptions(selectedOptions);
  
  window.requestAnimationFrame(() => {
    selectRef.setState.call(selectRef, {
      focusedOption: data.option,
    });
  });
};

I know it's not very elegant but works.

[drakyone]

I'm having the same issue. I worked it around by saving ReactSelect instance to a variable by ref, and after changing option I select previously focused option manually. See below:

const onChangeOption = (selectedOptions, data) => {
  handleSelectedOptions(selectedOptions);
  
  window.requestAnimationFrame(() => {
    selectRef.setState.call(selectRef, {
      focusedOption: data.option,
    });
  });
};

I know it's not very elegant but works.

could you provide an example please, I couldn't make it work using this

[drakyone]

mb it'll help someone
wrap your options in useMemo
const memoizedOptions = useMemo(() => options, [JSON.stringify(options)]);

[frankalbenesius]

mb it'll help someone wrap your options in useMemo const memoizedOptions = useMemo(() => options, [JSON.stringify(options)]);

This worked for me. But it does make me curious if this will inadvertently break something else.

[dan-j]

Awakening an old thread, but it looks like a simple change to getNextFocusedOption to compare options with getOptionValue instead of by the option object literally would resolve this issue?

Something like:

function getNextFocusedOption<
  Option,
  IsMulti extends boolean,
  Group extends GroupBase<Option>
>(props: Props<Option, IsMulti, Group>, state: State<Option, IsMulti, Group>, options: Options<Option>) {
  const { focusedOption: lastFocusedOption } = state;
  return lastFocusedOption && options.map(props.getOptionValue).indexOf(props.getOptionValue(lastFocusedOption)) > -1
    ? lastFocusedOption
    : options[0];

Thoughts?

[LucasGandara]

Hey! I'm having this issue with a MultiSelect, the thing is, I set attribute closeMenuOnSelect to false. If someone tries to select options 3rd, 4th and 5th, when selected the 3rd option, the select is not going to close but the focus goes to the first option once he selects the 3rd.
I already tried @frankalbenesius approach but didn't work.
Have anyone come up with a workaround already?

[torkelo]

Any update to this? Seems to be caused by this line in setValue

    this.setState({ clearFocusValueOnUpdate: true });

Which cause the next call to getDerivedStateFromProps to reset the focus index. This makes multi select with closeMenuOnSelect={false} really bad from a keyboard usage perspective as the focus index keeps resetting to the top.

Does this logic of clearing focus index make sense when closeMenuOnSelect false? Maybe we can skip that?