Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible history model limitation for common use cases. #16210

Closed
amyriounis opened this issue Jun 18, 2019 · 3 comments
Closed

Possible history model limitation for common use cases. #16210

amyriounis opened this issue Jun 18, 2019 · 3 comments
Labels
[Feature] History History, undo, redo, revisions, autosave.

Comments

@amyriounis
Copy link

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.

ezgif-3-ac2dcf84bb9a

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.

@ellatrix ellatrix added the [Feature] History History, undo, redo, revisions, autosave. label Jun 18, 2019
@paaljoachim
Copy link
Contributor

Hey @amyriounis

Thanks for creating the issue!
I see a lot of time has passed.
Is this issue still relevant?

@amyriounis
Copy link
Author

Hi @paaljoachim

Is this issue still relevant?

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.

@paaljoachim
Copy link
Contributor

Understand.

I will go ahead and close this issue. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] History History, undo, redo, revisions, autosave.
Projects
None yet
Development

No branches or pull requests

3 participants