Closed bryanwalthall closed 2 days ago
Hey @bryanwalthall 👋 Thanks for opening this. Would you be able to provide a use case for what you are trying to achieve? We have a label editing feature that allows you to have an input inside the tree view to edit the label. You can read more about it in the docs here . Also, you can create a custom DOM structure for your tree items - you can read about doing that with the recently introduced customization API on the dedicated documentation page.
If I'm getting this wrong, and you are trying to achieve something else and prevent the default behavior of onKeyDown
, you should be able to write your own handler similar to how the onClick
handler is recreated here
LMK if this helps 😄
Hi @noraleonte - thank you for the prompt reply and helpful links! The recent addition to allow editable labels is neat and I will investigate if this feature can be used to accomplish what I need. The intended use case for this is hierarchical editable data. We have different categories of data that are displayed in a tree form. Here is an example:
I can definitely see how we could use a custom editable label for this. Do you anticipate more features like this to be added to the TreeView components? Or would it be more future-proof to use customized Accordion components instead? Thanks for the input!
Hey @bryanwalthall ... from your screenshot there is no hierarchy visible ... Just a suggestion that maybe make your life easier: Would an accordion be a good solution for your use case?
Do you anticipate more features like this to be added to the TreeView components? Or would it be more future-proof to use customized Accordion components instead? Thanks for the input!
Reminder to myself: Always read to the bottom of each comment! 🤦🏼
Thanks @bryanwalthall for the context. I'd say if you don't have very deeply nested data, the Accordion might prove more useful. The Tree View is designed to serve for hierarchical data structures, and is the most useful for that. You can do something like this with a highly customized Tree Item too, if you override some of the handlers, but I'm not sure if it's the best way to go 🤔
That answers my question then haha. It seems that my "bug" reported is actually due to using TreeView outside of its intended use case. I'll go ahead and close this issue.
This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue. Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
[!NOTE] @bryanwalthall How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.
Steps to reproduce
Steps:
Current behavior
When typing "Hello World" the space is missing. When typing "tree" (lowercase is required) the input loses focus and the next tree item gains focus. The input is blank.
Expected behavior
Focus should stay on the input when changing the value. The final input value should be exactly what the user typed.
Context
Suspect handler: useTreeViewKeyboardNavigation -> handleItemKeyDown
Suspect original PR: #11452
Your environment
``` System: OS: Linux 6.1 Ubuntu 20.04.6 LTS (Focal Fossa) Binaries: Node: 20.12.1 - /home/codespace/nvm/current/bin/node npm: 10.5.0 - /home/codespace/nvm/current/bin/npm pnpm: 8.15.6 - /home/codespace/nvm/current/bin/pnpm Browsers: Chrome: Not Found npmPackages: @emotion/react: 11.13.5 @emotion/styled: 11.13.5 @mui/core-downloads-tracker: 6.1.8 @mui/icons-material: 6.1.8 => 6.1.8 @mui/material: 6.1.8 => 6.1.8 @mui/private-theming: 6.1.8 @mui/styled-engine: 6.1.8 @mui/system: 6.1.8 @mui/types: 7.2.19 @mui/utils: 6.1.8 @mui/x-internals: 7.21.0 @mui/x-tree-view: 7.22.1 => 7.22.1 @types/react: 18.3.12 => 18.3.12 react: 18.3.1 => 18.3.1 react-dom: 18.3.1 => 18.3.1 ```npx @mui/envinfo
Search keywords: tree view treeitem focus input textfield keyboard navigation