Delay block hydration to allow interactive block stores to initialize

[westonruter]

Fixes #66691.

When scheduler.yield() is available, the splitTask() function is implemented to use it. When a task is split with scheduler.yield() it results in the tail being added to the front of the task queue. In contrast, when splitTask() is implemented with setTimeout() (when scheduler.yield() is not available), then the tail of the split task is added to the end of the task queue. It appears there is a race condition between the call to init.

In particular, given this init function:

gutenberg/packages/interactivity/src/init.ts

Lines 30 to 46 in 7f49b39

	// Initialize the router with the initial DOM.
	export const init = async () => {
	const nodes = document.querySelectorAll(
	`[data-${ directivePrefix }-interactive]`
	);
	for ( const node of nodes ) {
	if ( ! hydratedIslands.has( node ) ) {
	await splitTask();
	const fragment = getRegionRootFragment( node );
	const vdom = toVdom( node );
	initialVdom.set( node, vdom );
	await splitTask();
	hydrate( vdom, fragment );
	}
	}
	};

It is getting invoked before the code in a block's view.js is invoked, for example:

gutenberg/packages/block-library/src/image/view.js

Line 22 in 7f49b39

const { state, actions, callbacks } = store(

When splitTask() is was using setTimeout() then the calls to await splitTask() had the effect of delaying the hydration until after the blocks' view modules execute. But when splitTask() is implemented with scheduler.yield() the hydration logic is executing before the interactive blocks' view module (i.e. the store initialization) executes.

Of note, the error also occurs if await splitTask() is eliminated from init function as well, indicating that it was not correctly accounting for delaying the Interactivity API's init until after the interactive blocks have all initialized. There seems to be a dependency problem here, where hydration of an interactive block should be blocked until its corresponding view script module has loaded. This seems to be related to:

• Block and Component Lazy Loading #2768
• Support for lazy hydration techniques: idle and view #52723
• Blocks: Introduce a way to enqueue view scripts only when needed for interactivity

In the mean time, adding a setTimeout() to handle the delay seems to do the trick.

Code execution with splitTask implemented with setTimeout

gutenberg/packages/interactivity/src/init.ts

Lines 31 to 38 in 7f49b39

	export const init = async () => {
	const nodes = document.querySelectorAll(
	`[data-${ directivePrefix }-interactive]`
	);
	for ( const node of nodes ) {
	if ( ! hydratedIslands.has( node ) ) {
	await splitTask();

gutenberg/packages/block-library/src/image/view.js

Line 22 in 7f49b39

const { state, actions, callbacks } = store(

gutenberg/packages/interactivity/src/init.ts

Lines 39 to 46 in 7f49b39

	const fragment = getRegionRootFragment( node );
	const vdom = toVdom( node );
	initialVdom.set( node, vdom );
	await splitTask();
	hydrate( vdom, fragment );
	}
	}
	};

Code execution with splitTask implemented with scheduler.yield

gutenberg/packages/interactivity/src/init.ts

Lines 30 to 46 in 7f49b39

	// Initialize the router with the initial DOM.
	export const init = async () => {
	const nodes = document.querySelectorAll(
	`[data-${ directivePrefix }-interactive]`
	);
	for ( const node of nodes ) {
	if ( ! hydratedIslands.has( node ) ) {
	await splitTask();
	const fragment = getRegionRootFragment( node );
	const vdom = toVdom( node );
	initialVdom.set( node, vdom );
	await splitTask();
	hydrate( vdom, fragment );
	}
	}
	};

gutenberg/packages/block-library/src/image/view.js

Line 22 in 7f49b39

const { state, actions, callbacks } = store(

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: westonruter <[email protected]>
Co-authored-by: annezazu <[email protected]>
Co-authored-by: artemiomorales <[email protected]>
Co-authored-by: cbravobernal <[email protected]>
Co-authored-by: t-hamano <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.