[Tree View] Label editing

[noraleonte]

trafficstars

• [x] I have followed (at least) the PR section of the contributing guide.

This PR is still WIP

Preview:

https://deploy-preview-13388--material-ui-x.netlify.app/x/react-tree-view/rich-tree-view/editing/

To do:

• [x] Finetune the behavior on double click
• [x] add callback method
• [x] finetune api for controlling the editing state (and limiting it to icon buttons as opposed to keyboard interactions)
• [ ] create docs
• [ ] styling of the editing state

[mui-bot]

Deploy preview: https://deploy-preview-13388--material-ui-x.netlify.app/

Updated pages:

• docs/data/tree-view/rich-tree-view/editing/editing.md

Generated by :no_entry_sign: dangerJS against 1107002a2146556ed62f5144e481967cff2d243b

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[flaviendelangle]

I think all the internals are pretty solid. We can discuss the exact shape of the methods returned by useTreeItem2Utils, but other than that the main remaining topic is the design :ok_hand:

[noraleonte]

@flaviendelangle Nice 🎉 Design is WIP, after it's done I'll add tests and open this up for review 🔥 Thanks for the help through this process 💙

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[noraleonte]

@alexfauquette

Do you know why the editing modifies the tree view size?

Nice catch! I couldn't reproduce it in Chrome but Firefox seems to be twitching as well. It might have to do with the default widths of the input in different browsers but I'll look into it 👀 Thanks!

[kenanyusuf]

Really great work on this!

One question on the behaviour here:

https://github.com/user-attachments/assets/8765df0d-d25f-4483-af03-09ed397c72d7

I wondered whether the input should inherit the width of the label so that when you're typing a long label it grows? It would also reduce the layout shift from non-edit mode -> edit mode.

If that's not the desired behaviour, perhaps it would make sense to make the tree view a fixed width on the demos and truncate the labels when not in edit mode?

[noraleonte]

@KenanYusuf That's a good point 🤔 I am not sure the input should grow with the value -> it could potentially lead to weird overflow issues depending on the amount of characters you write 🤔

As for truncating the text I think it makes sense but I'm not sure if it could break existing UIs or not. Right now the width of the tree view is equal to the width of its container. On the demos, the container does not have an absolute width, so it grows when the content grows -> layout shift 🙈

However, we do have a weird behavior when the label is longer than the container: By default, the text wraps to the second line (which might be a behavior some users want), but when there is a word that is actually longer than the container, we have an overflow in which case I think truncating is justified

WDYT @flaviendelangle ?

[flaviendelangle]

@noraleonte good question... Truncation is probably justified in your last example indeed

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.