-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add keepOpen prop to <Typeahead> #751
base: main
Are you sure you want to change the base?
Conversation
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.
I need this! bump |
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}
/>
); |
Yes, keeping the menu open is possible as per that example. For example in the given example to select all states beginning with 'Mi' one has to:
But with this change the process would be:
|
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. |
I guess there could be a prop Tough I do think that my initial keepOpen is a cleaner option 🤔 . 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. 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. |
@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. |
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: 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. |
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?
keepOpenOnSelect
perhaps 🤔