Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What: Closes #9511
Investigating different approaches overall but throwing this up for now to start a discussion. The 'boiler plate' code like the arrow handling is trickier than I initially thought it would be to extract because its stateful and specific to the example use case. In the typeahead example the function really is there to calculate which index to put the visual focus on, and not the actual arrow key handler which is running internally in Menu.
How does everyone feel about an approach like this where we effectively turn a demo into a wrapper component that we export for use? This way means a user can use a very simple component that internalizes almost all logic if their use case matches the example, and still has the wrapper code to work from if anything needs to be customized.
Right now the new example code shown in the docs is only importing the wrapper, but we could copy that into the same file to show everything in the one place. I initially had everything in the example file, but was running into an issue with exporting the wrapper directly from the examples folder (still looking into that).