feat: static Components panel layout

[hoxyq]

Summary

Follow-up to #33517.

With #33517, we now preserve at least some minimal indent. This actually doesn't work with the current setup, because we don't allow the container to overflow, so basically deeply nested elements will go off the screen.

With these changes, we completely change the approach:

• The layout will be static and it will have a constant indentation that will always be preserved.
• The container will allow overflows, so users will be able to scroll horizontally and vertically.
• We will implement automatic horizontal and vertical scrolls, if selected element is not in a viewport.
• New: added vertical delimiter that can be used for simpler visual navigation.

Demo

Current public release

Screen.Recording.2025-07-04.at.09.23.24.mov

With #33517

Screen.Recording.2025-07-04.at.09.22.12.mov

This PR

Screen.Recording.2025-07-04.at.09.19.47.mov

[vzaidman]

maybe clarify somehow this is not the "lowest" as in "deepest" but the bottom-most branch (if I understood it correctly)

[hoxyq]

Yeah, lowest in a sense of the bottom-most "branch", if you look at it from UI perspective. I do agree that "deepest" is probably not the right word here.

[gaearon]

FWIW I think a significant motivation of the previous approach was to be able to scroll the tree and have idea of where you're going. In either direction. I don't think it's obvious to the user that moving the selection alone would do that. Not saying I strictly oppose it but I wonder if there's a significant usability loss for deep trees like on Comet. Especially in the everything-is-expanded default mode.

[hoxyq]

FWIW I think a significant motivation of the previous approach was to be able to scroll the tree and have idea of where you're going. In either direction. I don't think it's obvious to the user that moving the selection alone would do that. Not saying I strictly oppose it but I wonder if there's a significant usability loss for deep trees like on Comet. Especially in the everything-is-expanded default mode.

Previous approach doesn't scale well exactly for the apps like the ones with Comet. When I was thinking about it, I always end up with 2 choices:

1. Displaying the nodes relative to each other in the current viewport, based on their depth.
2. Static layout, or what you call everything-is-expanded.

If we do 1, how do we determine the offset of the node?

• Option 1. Previous approach. We do it as a function of depth. This doesn't scale for Comet, because you could have nodes in the viewport, where min(depth) would be <10, and max(depth) > 100. The "deepest" node would be skewed to the right and would go off the screen or we would calculate the indentation in a way that this node is still displayed, but at the cost of loosing the indentation at all. This is what was happening before [devtools] Added minimum indent size to Component Tree #33517, all elements would just be displayed in a single line.
• Option 2. We still determine it based on depth, but only on the order of depth. The UI would become really jumpy and dynamic, but more importantly, we would loose the ability to signal a significant difference in depth between different nodes. If node at index i has depth = 100, and the node at index i + 1 has a depth = 10, we would probably just display the latter one with an offset to the right, but in reality, these are located in completely different subtrees.

For large trees, yeah, I do agree with you, but I think we traded this "see while scrolling" benefit for persistent offset and simpler UI navigation. I don't think there is a significant usability loss for wide / deep trees with Comet or react-strict-dom. The tree representation is so huge that looking at the full representation rarely would generate any valuable insights. What users usually do is select an element on the screen and then work with a subtree.