Shared Blocks: Refactor fetching/saving/updating to avoid cycle dependency#7080
Shared Blocks: Refactor fetching/saving/updating to avoid cycle dependency#7080youknowriad wants to merge 1 commit intomasterfrom
Conversation
|
This is working well for my simple shared block but not my nested one (see #7075 for screencasts). The window freezes when attempting to add that block, or edit in a post that contains it. |
|
This looks similar to how shared blocks were originally implemented in #3017 and #3377. We moved towards the If we're convinced that |
|
This does also fix #5754, though! 🙂 |
|
I see, it's a complex problem :) caused by the fact that we rely too much on the context to access the blocks (unique store), we don't have a component that renders a list of block given this list per prop :(. I think we can't fix this quickly. I do think there's a conceptual problem with the cycle dependency we have right now because, updating an existing reusable block shouldn't rerender it or regenerate the attached block. |
Related #7075 alternative to #7077
This PR refactors saving/editing/creating shared blocks by removing the
uidkey we were setting in the state of the shared blocks. This ends up being a big simplification.This cycle dependency was causing the blocks relying on shared blocks to remount when the associated shared block is refetched from the server.
Testing instructions