Add keepOpen prop to <Typeahead>

[Huulivoide]

The keepOpen property can be used to prevent default behaviour of closing the menu and resetting the components internal state when selecting an item in multi mode.

This can be for example be used to implement "select multiple when ctrl is pressed down" -functionality. For example when your users often have the need to select every item with a specific prefix.

What issue does this pull request resolve? Currently it is not possible to select multiple options, or reuse the search filtering, simultaneously in the multi-node. It is possible to keep the menu open with the open prop the component still resets the search input. For example as need in the image, getting all 3: 90024-R, 90024-T, and 90026-T selected, would require quite a lot of typing if the search resets and menu closes each time one of them is selected.

What changes did you make? Added an prop to circumvent the automatic closing and input reset on select.

Is there anything that requires more attention while reviewing?

1. Should the prop be named differently? keepOpenOnSelect perhaps :thinking:
2. Are there any potential edge cases and conflicts with other props.

[LankyMoose]

I need this! bump

[ericgio]

Hey @Huulivoide, thanks for your work putting together this PR. That said, I want to note that keeping the menu open while selecting multiple options is already pretty trivial to implement, as demonstrated in this example.

const typeaheadRef = useRef(null);

return (
  <Typeahead
    ...
    multiple
    onChange={(selected) => {
      // Keep the menu open when making multiple selections.
      typeaheadRef.current.toggleMenu();
    }}
    ref={typeaheadRef}
  />
);

[Huulivoide]

Yes, keeping the menu open is possible as per that example. But that still has the side effect of clearing the search when selecting an item.

For example in the given example to select all states beginning with 'Mi' one has to:

1. type mi
2. select Michigan
3. type mi
4. select Minnesota
5. type mi
6. select Mississippi
7. type mi
8. select Missouri

But with this change the process would be:

1. type mi
2. select Michigan
3. select Minnesota
4. select Mississippi
5. select Missouri

[ericgio]

That's true, though I think you have a specific use case in mind where someone would be selecting several similarly named options. If that's not the case, then keeping the search string/filtering is actually detrimental. I think your use case is valid, I just wonder if there's a way to make the component's API flexible enough for you to achieve the behavior you want while allowing another developer to similarly tailor their experience.

[Huulivoide]

I guess there could be a prop doNotResetStateWhenHiding that would prevent the component from resetting it's internal state when the item selection triggers the hideMenu() function. And then that combined with the toggleMenu() trick could be an alternative.

Tough I do think that my initial keepOpen is a cleaner option :thinking: .

My use case currently is such that I have a multitude of complex search pages for medical records with up to 2 dozen different typeaheads in each pulling values from "codesets" with tens of thousands of values, many with similar names.

For example one case could be that insurance company FooBar Insurance's headquarters rings in to tell that they suspect there to be some discrepancies related to how knee joint replacement surgeries have been invoiced from them in the past quarter. Thus a customer service person must pull out all relevant records for inspection. Now whilst it would be nice if there was only a single code relating to kind of procedures in question the truth is there are multiple variations each with their own code that needs to be selected. And to filter out all non relevant codes from the typeahead such as: knee joint surgery, knee joint replacement assesment or hip joint replacement surgery . One has type in all the relevant keywords of knee joint replacement surgery to get proper results. Then repeat a similar selection for all of the different offices of insurance company the invoices might have been addressed to initially.

Rinse and repeat for next case, 8h a day, 5 days per week.

So the users really need some way, to have the typeahead input stay open when a option is selected and also keep its state the same for further selection with the same search input, pagination and scroll position.

[ericgio]

@Huulivoide your use case makes sense and I acknowledge that this library doesn't support your optimal solution at the moment. As noted previously, I don't think it's a good idea to add use-case-specific props; it's not scalable and I don't think it reflects good API design. Longer-term, inversion of control is probably the right way to address your issue, but it would take some work and I don't see it happening soon. I understand that's not helpful for your immediate needs, and I'm sorry about that. I appreciate you taking the time to submit this PR and push on this issue.

[mbafford]

The other problem with the workaround is that the control also scrolls back to the top after selecting an entry. (on re-reading, I see @Huulivoide did mention that)

This example (from another issue on this project, I think) demonstrates that problem: https://codesandbox.io/s/rbt-keep-menu-open-during-multi-select-nr2y4

We're encountering both use-cases described - the desire to keep the filter and keep the scroll position as our common use-case would involve people selecting multiple items in proximity.