[FEATURE] Perspective Column Container rearrangement bugs

v8.0.15

After having just tried to use the column container, I’ve found it quite frustrating to rearrange items around with the mouse. It seems anything I try to move will permanently move every other component that I touch in the process.
Entering positions isn’t so bad via editing the properties, however it’s painful having to expand the properties each time you select another component.

It would be great if this container could be revisited and its workflow made easier to use.

There are three notable idiosyncrasies when it comes to moving the components, so I’d curious if you’re perhaps encountering one of them.

  1. When using the Column container, each component has a starting column and span. As components are drawn left-to-right, components with lower starting indexes need to be honored first. So if you have two components with starting indexes of 0 and 2 and both components have a span of 2, but you drag a third component column 1 and release, then the component which had originally been at column 2 must re-calculate its starting index. As we have to honor values left-to-right, the new starting index for the “third” component must be 2 (because the first component is at column 0 with a span of 2) PLUS the span of the third" component.

  2. Secondly, you’re dealing with different breakpoints, which can be done by either clicking the breakpoint in the property editor or actually resizing the container such that it falls within a breakpoints limits. When you move form one breakpoint to another, we re-draw the container with the layout of the selected (or implied) breakpoint. When we do this, it might look like components are shifting, but it’s because we’re moving them to where they have been defined for this breakpoint.

  3. There is another behavior to be aware of: we can’t limit the length of a row to have a combined span of twelve or less, nor can we limit individual spans based on current column index. This means that you could have one component span 11 columns, then place a second component in the same row and modify the second component’s span to be some value greater than 1. When this occurs, it looks like the container has actually moved components onto a second row, but if you look at the dashed lines you’ll see that you’re actually in the same row. As the row is technically in an incorrect state, you’ll see undesirable behaviors when adding removing components because we still need to honor the left-to-right precedence.

If either of these behaviors describe what you’re seeing, there’s only so much we can do to improve the process. I don’t think we can modify the logic used to draw the rows (left-to-right precedence) because the runtime calculations also have to factor in that the row number could change based on the breakpoint in use at a given time. We might be able to provide a warning when a row enters an undesirable state, but we can’t prevent users from binding those values (columnIndex, span), and so the undesirable state might not even occur until a session is running.

Recommendations:
Never set up a layout for a breakpoint until you’ve placed EVERY component the container will hold. This is because when a component is dropped onto the container while deep-selected it will apply that drop location across ALL breakpoints as much as it is able. Depending on the columnIndex/span values of other components, this could cause some shifting due to the left-to-right precedence rule. I always recommend you just throw every component in that you’re going to use, and once you have everything, then you can move from breakpoint to breakpoint and lay everything out how you’d like.

2 Likes