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

useBlockSync: just testing without isControlled effect #61114

Merged
merged 1 commit into from
Apr 29, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
* WordPress dependencies
*/
import { useEffect, useRef } from '@wordpress/element';
import { useRegistry, useSelect } from '@wordpress/data';
import { useRegistry } from '@wordpress/data';
import { cloneBlock } from '@wordpress/blocks';

/**
Expand Down Expand Up @@ -82,15 +82,6 @@ export default function useBlockSync( {
} = registry.dispatch( blockEditorStore );
const { getBlockName, getBlocks, getSelectionStart, getSelectionEnd } =
registry.select( blockEditorStore );
const isControlled = useSelect(
( select ) => {
return (
! clientId ||
select( blockEditorStore ).areInnerBlocksControlled( clientId )
);
},
[ clientId ]
);

const pendingChanges = useRef( { incoming: null, outgoing: [] } );
const subscribed = useRef( false );
Expand Down Expand Up @@ -186,23 +177,6 @@ export default function useBlockSync( {
}
}, [ controlledBlocks, clientId ] );

const isMounted = useRef( false );

useEffect( () => {
// On mount, controlled blocks are already set in the effect above.
if ( ! isMounted.current ) {
isMounted.current = true;
return;
}

// When the block becomes uncontrolled, it means its inner state has been reset
// we need to take the blocks again from the external value property.
if ( ! isControlled ) {
pendingChanges.current.outgoing = [];
setControlledBlocks();
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So now, I have a vague memory of the Navigation block switching between "not controlled" into "controlled" to support some legacy mode of that block. @draganescu might know more. I guess the testing instructions is to try to load that old navigation block markup in the editor and ensure that everything works as expected.

Copy link
Contributor

@draganescu draganescu Apr 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The navigation block can start as uncontrolled, when there are navigation inner blocks specified in the markup. When this uncontrolled state is updated by say adding a new navigation link, the content is saved to a CPT and the block switches to controlled.
EDIT:
I tested this PR and the functionality described above seems unaffected.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the potentialy buggy part is when you hit Undo after this switch from uncontrolled to controlled. Then probably the navigation block should switch back to uncontrolled? And revert to the uncontrolled inner blocks specified in the markup?

That's what the title of #37484 (the PR that claims to fix #37361) says: "avoid undo issues"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the navigation block should switch back to uncontrolled?

I can't tell if that was ever the case? I don't even know if we want that, the uncontrolled version is just a way for themes to include default navigation content for style reasons.

}, [ isControlled ] );

useEffect( () => {
const {
getSelectedBlocksInitialCaretPosition,
Expand Down
Loading