Grid: Swap the position of grid items when they are re-arranged in the List View?

[noisysocks]

When using a Grid block set to Manual mode, you can drag and drop grid items to arbitrary cells which updates the columnStart and rowStart of that block. When this happens we also change the block's position in the block list (grid.innerBlocks) so that the DOM order of the blocks roughly matches the visual order.

We don't currently do this the other way around though. If you change the order of the Grid block's children using List View, only the markup order will change (useful for stacking!) and the blocks won't visually move around. This could be confusing.

I have three ideas:

1) We could do nothing.

List View would be for solely changing the DOM order of the grid's children, which is how you'd control which grid items are stacked on top of other grid items.

2) We could disable List View.

If we did not allow drag-and-drop-to-reorder in List View then this confusing interaction would go away. We'd need a new way of controlling which grid items are stacked on top of other grid items, though. Potentially we could add "Bring to front" and "Send to back" controls which are popular in lots of other editors. Related to #63971.

3) We could write logic that swaps the visual position of blocks when their order changes.

Say you had a block tree like this:

• Grid
  • A
  • B
  • C
  • D

If the user re-orders D to be in between A and B then we could write logic that swaps the columnStart and rowStart attributes like so:

• D takes B's position attributes
• B takes C's position attributes
• C takes D's position attributes

[talldan]

Throwing ideas around, another option is that you could have some kind of virtual grouping of the blocks in List View into cells.

E.g.

• Grid
  • Cell (1,1)
    • Block A
    • Block B
  • Cell (1,4)
    • Block C

I'm not sure how this would be achievable without an inner block, but from a UI perspective it allows the user to drag between other (occupied) cells, change the z-index, and the blocks would also naturally have a DOM order matching the visual order.

I imagine it would only show the occupied cells in List View, otherwise it'd be very noisy.

[noisysocks]

That's a cool idea!

I think it will be clearer which of these options we should explore once we get a bit more usage and feedback. Right now I don't know what folks are expecting when it comes to the List View.

[talldan]

Maybe I'm thinking too much about blocks as being neat things that fit into cells, whereas in reality the blocks can be arranged and overlap in interesting ways which will be harder to represent in List View the way I presented above. I'll keep thinking about it though.