-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Fix content loss when ungrouping template parts or reusable blocks #37280
Conversation
Size Change: +463 B (0%) Total Size: 1.11 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, Riad. It works like a charm.
CleanShot.2021-12-10.at.15.48.03.mp4
Is this a reason why my example fix was failing? We also have another issue with controlled inner blocks and now I'm curious if this might be related - #36937. |
It's interesting that with this PR, if we group and then ungroup, we don't have the disappearing issue(#36937) |
@ntsekouras Do you mean if we group/ungroup before accessing focus mode or inside the focus mode? |
Before the isolated editing view |
@ntsekouras potential fix for the related issue here #37283 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Maybe we should add e2e tests that cover the grouping/ungrouping of inner block controllers. I've to call it a day soon, but happy to create a new test on Monday. What do you think? |
Co-authored-by: George Mamadashvili <[email protected]>
Works for me. Thanks @Mamaduka |
…37280) Co-authored-by: George Mamadashvili <[email protected]> Co-authored-by: ntsekouras <[email protected]>
Closes #36788
Alternative to #37274
There are two low level bugs that create this issue:
onChange
handler fromuseBlockSync
is called. Ideally it shouldn't be because that component will be unmounted a few milliseconds later. This is hard to solve because the store subscriptions run from the deepest component to the top level ones. Basically, it's another kind of redux zombie bug. I'm not sure we can solve that part of the bug.blocks
shouldn't be emptied in the first place when "moving" the block to another position, this happens because controlled blocks are supposed to retrieve their block again from the "core" store when they remount again but since onChange is called (first bug above) the value in "core" store is wrong (empty blocks). I'm fixing this part of the bug in this PR: I'm making sure if a controlled block moves to a new position, it retains its inner blocks from the previous position.