You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The search input bar does not follow best practices for user input. The search bar is impermanent and displays at the bottom of the tree, which is not guaranteed to be in view when the user begins typing. Because it is impermanent the user is not aware of the existence of search functionality without being explicitly told so and this can create bad experiences.
Describe the solution you'd like
I'd like to be able to make the search input permanently displaying (i.e. you don't have to start typing for it to show up, it just always is visible to the user) and I'd like to be able to position it at the top of tree, rather than the bottom.
Describe alternatives you've considered
I could use the renderSearchInput for this, but when you do so you lose all in-built search functionality and have to program it yourself. Feels like alot of work when All I really want is to change the display settings of the existing input. At least, that's my perspective as of now, please inform if there's a better option for my use case.
Additional context
N/a
The text was updated successfully, but these errors were encountered:
The reason why I built the search how I did, is mostly motivated by how tree searches work in some IDEs like IntelliJ:
They fulfill the accessibility requirement that, when starting to enter a key, the focus should jump to the visible item that starts with that key, and ideally continuing to enter keys should refine the focus. The input is not shown by default, because it's not always desired in all use cases and the primary use case is really just a "quickly jump to item x".
I want the search to behave completely different
It's actually not that complicated to build a custom search on top of RCT. The built-in search only searches visible items, so childs of opened folders, here is an example for a custom implementation for a searching hidden items with a seperate search input:
I just want to reposition the input
Technically the input is already displayed at the top of the tree. It's inserted in the DOM below, but visually overlayed at the top left of the tree, similar to how IntelliJ does it. If you use custom CSS, you may have to add this part yourself. If you want to change the location in DOM where it is rendered, there is no easy way to do this manually, but you could use a React Portal to render the search input somewhere else.
I want the search input to always be visible
Again, there is no easy option for this, but this should be doable with some hacks. The search input is rendered whenever the search value is not null, which it is by default. You can set the search value to an empty string instead of null with treeRef.setSearch(""). Remove the keyboard bindings for "abortSearch". In your renderSearchInput implementation, overwrite the onBlur handler with something new after what ...inputProps provides to the input. I believe that should suffice.
Is your feature request related to a problem? Please describe.
The search input bar does not follow best practices for user input. The search bar is impermanent and displays at the bottom of the tree, which is not guaranteed to be in view when the user begins typing. Because it is impermanent the user is not aware of the existence of search functionality without being explicitly told so and this can create bad experiences.
Describe the solution you'd like
I'd like to be able to make the search input permanently displaying (i.e. you don't have to start typing for it to show up, it just always is visible to the user) and I'd like to be able to position it at the top of tree, rather than the bottom.
Describe alternatives you've considered
I could use the renderSearchInput for this, but when you do so you lose all in-built search functionality and have to program it yourself. Feels like alot of work when All I really want is to change the display settings of the existing input. At least, that's my perspective as of now, please inform if there's a better option for my use case.
Additional context
N/a
The text was updated successfully, but these errors were encountered: