Size Change: -21 B (0%)

Total Size: 1.74 MB

_{compressed-size-action}

state.controlledInnerBlocks is preserved, and we continue to know that a block with certain clientId should be controlled.

What guarantees that the clientIDs of the new blocks are still "controlled"?

What guarantees that the clientIDs of the new blocks are still "controlled"?

First I assume that the clientId uniquely identifies a certain block. RESET_BLOCKS with a clientId that already exists in the tree is assumed to be a hard reset to a different version of the same block, not a replacement with a completely different block, possibly of a different type.

If the new version of the block doesn't want to be controlled, it will signal that by not mounting useBlockSync when it renders. Then the old useBlockSync that is currently mounted will unmount, and in its cleanup effects it will reset the block to uncontrolled. If RESET_BLOCKS specified a block with explicit uncontrolled innerBlocks, these will become active after useBlockSync resets the controlledInnerBlocks state for it.

In short, the controlled state is now controlled solely by useBlockSync. On mount, it will set the controlledInnerBlocks state and set the controlled inner blocks. During its lifetime it will sync the controlled blocks. And on unmount it will reset the controlledInnerBlocks state, which makes the old uncontrolled inner blocks active again.

Until now not everything was under useBlockSync control. There was the RESET_BLOCKS action that could clear the controlledInnerBlocks state on its own.

In short, the controlled state is now controlled solely by useBlockSync. On mount, it will set the controlledInnerBlocks state and set the controlled inner blocks. During its lifetime it will sync the controlled blocks. And on unmount it will reset the controlledInnerBlocks state, which makes the old uncontrolled inner blocks active again.
Until now not everything was under useBlockSync control. There was the RESET_BLOCKS action that could clear the controlledInnerBlocks state on its own.

That makes sense, in my understanding this PR was removing the "cleanup" from useBlockSync while useBlockSync is the only place that knows for sure whether a block is controlled or not.

As for the clientId, for me we can't really assume that a clientId refers to the same block after you call RESET_BLOCKS but this is fine as long as useBlockSync is responsible for cleaning things up.

As for the clientId, for me we can't really assume that a clientId refers to the same block after you call RESET_BLOCKS but this is fine

Yes: even if RESET_BLOCKS replaces the clientId with an arbitrary block, the course of events is:

• after RESET_BLOCKS, state.controlledInnerBlocks[ clientId ] is still true, state.tree[ 'controlled||' + clientId ] contains the old controlled inner blocks, and state.tree[ clientId ] contains the new uncontrolled inner blocks (but they are overshadowed).
• at this moment, getBlocks( clientId ) would return the old controlled blocks, although the new block might be incompatible with that. I'm not 100% sure if this is fine, but hopefully it is.
• if the new block has a different type, or doesn't want to be controlled, the old useBlockSync will start unmounting. Only at this moment the state.controlledInnerBlocks[ clientId ] will be set to false, the controlled|| state will be removed.
• at this moment, after React unmounts the old edit UI, getBlocks( clientId ) finally returns the right result.

The old implementation didn't have this inconsistent "new block with old controlled children" state. Instead, if both the old and new block were of the same type and both wanted to be controlled (canonical example of such a reset is an undo that changes only other blocks), the block became briefly uncontrolled, with uncontrolled inner blocks. useBlockSync had to recover the controlled state in a React effect.

Just noting that #75458 was merged into trunk.

Let's close this, if there's anything missing from what landed in @jsnajdr let us know.