Build an async combobox based on react-select #1163
-
Hello Paste team! I've tried building an async combobox using the Combobox in paste to mimic the existing Async Subuser Select in SendGrid (based on react-select) but the logic is complicated and it seems like reinventing the wheel. The select we need should do a fetch whenever the input changes as we want a prefix search. As the input changes if the input matches any existing options it will filter for those options while still fetching in the background. If the input clears it shows the initial default options. The issues I'm running into with Combobox are timing issues (i.e. as user types in inputs and blanks it out quickly, it shows default options which then get overwritten by new options after the fetch completes). It gets a little tricky trying to only show "Loading..." as the only option if the input does not have a prefix match with any existing options too. We've also noticed a fetch still happens after selecting an option, and when we tried adding a check for whether or not the dropdown is open before fetching, we ran into more unexpected behavior. We've decided to dial back on matching the same behavior as react-select with Combobox for now. However I was wondering if we've considered making an async select component in paste based on react-select. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
Hey @productdana , we're having a bit of trouble nailing down exactly which blockers you're having with the current combobox. Can you share a CodeSandbox example of how far you were able to get (if at all) with the Paste Combobox in achieving the things you're trying to do with Combobox? A list of the issues and what you tried so far would help, too! |
Beta Was this translation helpful? Give feedback.
-
Hi @productdana We don't have have access I'm afraid. We did choose Downshift over all other combobox alternative specifically because it was much more closely aligned to the W3C ARIA spec, and much more flexible to our consuming teams. Via inversion of control, it allows us to support more teams, without creating a bottle neck on our team for additional specific data requirements or interactions. What that does mean though, is there is an emphasis on the consuming team when they upgrade or switch, to do much more of the lifting. We're happy with this trade off for now as we're in no position to know how each business unit or product we support (All Console teams, Flex, SG etc) needs to handle their data and we're a super small team. The downshift docs and community are pretty great too. We don't really do much to it apart from wrap it and rename somethings. Otherwise we expose the useCombobox hook "as is" for you to work with to meet your data requirements. It just means that for your team, moving from react-select is going to be some extra work because the APIs are totally different. We'd be happy to support and learn from you during that process, especially around specific blockers, or bugs you encounter We've had a number of teams adopt it so far and we're always learning. |
Beta Was this translation helpful? Give feedback.
Hi @productdana
We don't have have access I'm afraid.
We did choose Downshift over all other combobox alternative specifically because it was much more closely aligned to the W3C ARIA spec, and much more flexible to our consuming teams. Via inversion of control, it allows us to support more teams, without creating a bottle neck on our team for additional specific data requirements or interactions.
What that does mean though, is there is an emphasis on the consuming team when they upgrade or switch, to do much more of the lifting. We're happy with this trade off for now as we're in no position to know how each business unit or product we support (All Console teams, Flex, SG etc) needs to h…