Stability of nodes and edges levels

Describe the Bug

A node can be displayed at the max z-index level when selected, but when it is deselected, its level will be reset to the initial level (which is defined by the render order I think). Therefore, a user cannot rearrange the level order of the nodes. This behavior is a little unconventional and may cause some problems in applications.

Your Example Website or App

https://reactflow.dev/docs/examples/overview/

Steps to Reproduce the Bug or Issue

1. Drag one of the upper nodes over some of the lower nodes. The upper node will cover the lower ones.
2. Click the blanket to deselect the upper node.
3. The upper node is covered by the lower ones.

Expected behavior

The levels of the nodes shouldn’t be affected by deselection.

Screenshots or Videos

https://user-images.githubusercontent.com/10386119/158810010-91d4d5d4-1406-45ac-9728-8ee819b2d7c4.mp4

Platform

• OS: [Windows]
• Browser: [Edge]
• Version: [v10]

Additional context

No response

[chrtze]

Thanks for your thoughts on the updated zIndex logic. We have designed the default behavior of the nodes and edges in React Flow v10 like this:

• nodes are being rendered above the edges according to their order in the nodes array
• edges are being rendered behind the nodes according to their order in the edges array
• edges inherit the zIndex of their source or target with the highest zIndex (default will be 0)
• once a node is selected or dragged, it gets zIndex 1000 (we should probably make this value configurable in the future) to lift the node and their connected edges above everything else

This behavior can be customized:

• to control the initial stacking order, simply change the order of the nodes and edges in their arrays
• to disable the elevation of nodes on select/drag, you can apply a zIndex option to the nodes, this value will take precedence over the default value (1000)
• to disable the elevation of edges on node select/drag, you can apply a zIndex option to the edges or set defaultEdgeOptions={{ zIndex: 0 }}

I agree that this seems to be too complicated, if you want to have the v9 behavior out of the box. Maybe we can add a property that allows to control this behavior, but for now I think the easiest way is to use defaultEdgeOptions={{ zIndex: 0 }}.

[AustinGilliam]

@AustinGilliam Hi, do you mean that you do not want the edges to be risen up by selecting the nodes? I personally like this behavior. And I believe this is introduced because of the sub flows feature. The levels of edges are determined by their connected nodes, so if the problem stated in this issue is resolved, I believe all the edges will be good too. Actually there’s a another problem caused by the introduction of z-index into edges, for which I opened an issue here: #1966

I personally don’t like it if you’re using edge labels, because you can drag a node such that the label of its edge completely occludes another node label beneath it. Github seems to be having some issues, as I can’t currently upload a screenshot. You can replicate in the Overview Example by dragging “This is a default node” such that the edge label occludes “Node id: 5”.

This also causes issues with custom nodes that have “badges” attached to them, e.g. some architecture styles have visual elements that extend beyond the border of the base node (see below). In this case, the edge will show above the badges on the left, which isn’t functionally breaking anything, but is not visually pleasing.

However, I get the rationale from a grouping perspective, so it’s tricky. I would expect that if I had Group Node A with children Nodes B and C, and an Edge E between B-C, that the z-index of E would be higher than A. Maybe it could be a togglable option? I understand that the use case I described above is a probably a little niche, so I’d be happy to manually set the z-index in my case.

Edit: Added pictures now that Github Issues is stable again.