You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following the conversation on #13892 and to extend a bit further on the issue, what I am essentially trying to accomplish is to develop a layout system in the likes of Elementor and Beaver Builder for Gutenberg.
Common Use Case:
As you know, draggin n' dropping rows and columns around is an essential part of such an editor but trying to accomplish it using Gutenberg gives me the impression that I have hit a wall.
For example, let's assume that a column has been dragged inside a row (any Gutenberg user migrating from an exisitng page builder would expect this behavior). This operation typically consists of more than one sub-operations in order to be considered complete. At the least, the row's column count must be incremented by one and the row's layout must be updated in order to apply the new layout structure. Let's say we only need those two updates. Now, when the user hits the "Undo" button after an operation like that, he expects the column to be removed from the row and put back to wherever it was, but instead what he gets is the row's layout attribute getting it's old value back which could probably invalidate the layout system since there would be a mismatch regarding the layout being applied for the current number of columns.
Example Using Qubely Blocks
Take a look here, the simple act of removing (or duplicating for that matter) a column, when being reverted, invalidates the layout system, cause using the current history model this operation is not treated as a whole (reverting all sub-operations it depends upon), creating a mismatch between columns count and layout.
You can easily see that any operation that requires a number of sub-operations in order to be considered whole, suffers from the same problem.
It's possible that I am missing something obvious here but please let me know if you think the scenario I mentioned above can be supported, maybe using another approach, as it is a crucial part of any modern page builder and I can't see how Gutenberg could not support a use case like that.
The text was updated successfully, but these errors were encountered:
I haven't been following Gutenberg for more than a year now so I wouldn't really know. Although, this issue would need a change in the system's core architecture so I doubt it would ever be implemented.
Following the conversation on #13892 and to extend a bit further on the issue, what I am essentially trying to accomplish is to develop a layout system in the likes of Elementor and Beaver Builder for Gutenberg.
Common Use Case:
As you know, draggin n' dropping rows and columns around is an essential part of such an editor but trying to accomplish it using Gutenberg gives me the impression that I have hit a wall.
For example, let's assume that a column has been dragged inside a row (any Gutenberg user migrating from an exisitng page builder would expect this behavior). This operation typically consists of more than one sub-operations in order to be considered complete. At the least, the row's column count must be incremented by one and the row's layout must be updated in order to apply the new layout structure. Let's say we only need those two updates. Now, when the user hits the "Undo" button after an operation like that, he expects the column to be removed from the row and put back to wherever it was, but instead what he gets is the row's layout attribute getting it's old value back which could probably invalidate the layout system since there would be a mismatch regarding the layout being applied for the current number of columns.
Example Using Qubely Blocks
Take a look here, the simple act of removing (or duplicating for that matter) a column, when being reverted, invalidates the layout system, cause using the current history model this operation is not treated as a whole (reverting all sub-operations it depends upon), creating a mismatch between columns count and layout.
You can easily see that any operation that requires a number of sub-operations in order to be considered whole, suffers from the same problem.
It's possible that I am missing something obvious here but please let me know if you think the scenario I mentioned above can be supported, maybe using another approach, as it is a crucial part of any modern page builder and I can't see how Gutenberg could not support a use case like that.
The text was updated successfully, but these errors were encountered: