wp-core-data should not depend on wp-block-editor

[picocodes]

Description

This is because wp-block-editor depends on lots of other scripts:- react, react-dom, react-jsx-runtime, wp-a11y, wp-api-fetch, wp-blob, wp-blocks, wp-commands, wp-components, wp-compose, wp-data, wp-date, wp-deprecated, wp-dom, wp-element, wp-hooks, wp-html-entities, wp-i18n, wp-is-shallow-equal, wp-keyboard-shortcuts, wp-keycodes, wp-notices, wp-preferences, wp-primitives, wp-private-apis, wp-rich-text, wp-style-engine, wp-token-list, wp-url, wp-warning, wp-wordcount

Leading to loading dozens of scripts just to use wp-core-data.

Step-by-step reproduction instructions

Add wp-core-data as a script dependancy

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[Mamaduka]

The same concern has been raised in the original PR - #51201 (comment).

cc @ellatrix

[Mamaduka]

The behavior was reported again in #67334.

cc @jsnajdr, @youknowriad

[youknowriad]

Indeed, it seems like an arguable decision. If I'm reading the code properly, it seems the only reason we access it in "core-data" is because of the InnerBlocks.Content component? maybe some of this can be part of "blocks" package since this seems intrinsic to parsing/serializing blocks. cc @ellatrix

[gziolo]

Re-sharing the comment from @samueljseay left in #67334 for visibility:

Recently on WooCommerce we decided to explore using entities to share some data between blocks. The data is some editable block headings we want to share between blocks.

To access this data in front-end we use the core data store, specifically we use getEditedEntityRecord. The issue with doing this, is that @wordpress/core-data depends on @wordpress/block-editor so when we do this basic query of some entity records front-end we're forced to load the entirety of the block editor.

It seems this dependency is only for unlocking a private API. The only other usage is in a test file.

I'm not sure what a good fix to this would be, but it would be hugely helpful if we could avoid depending on @wordpress/block-editor for this package.

[youknowriad]

I think using @wordpress/core-data in the frontend is arguable though. I get that it's handy but I don't expect a huge need to handle entities / caching / edits in the frontend (maybe I'm wrong) and in that case, maybe a direct usage of api-fetch could be enough for WooCommerce's use-case.

[gziolo]

I checked the codebase, and the only place where @wordpres/core-data depends on @wordpress/block editor is the following two lines:

gutenberg/packages/core-data/src/entity-provider.js

Lines 199 to 200 in 3b89e82

	const { getRichTextValues } = unlock( blockEditorPrivateApis );
	const _content = getRichTextValues( _blocks ).join( '' ) || '';

If I'm reading the code properly, it seems the only reason we access it in "core-data" is because of the InnerBlocks.Content component? maybe some of this can be part of "blocks" package since this seems intrinsic to parsing/serializing blocks.

There is some processing of the content that collects the metadata required to update post meta for the Footnotes block. Since #43204 @wordpress/blocks depends on @wordpress/rich-text as it consumes RichTextData object when handling attribute types. That might be one of the paths forward.

More broadly, it would be great to understand why the general purpose React hook useEntityBlockEditor needs to know about footnotes in the first place? Can this handler be somehow injected? Looking at code:

gutenberg/packages/core-data/src/entity-provider.js

Lines 248 to 249 in 3b89e82

	const onChange = useCallback(
	( newBlocks, options ) => {

gutenberg/packages/core-data/src/entity-provider.js

Lines 272 to 273 in 3b89e82

	const onInput = useCallback(
	( newBlocks, options ) => {

and the same usage of the callback:

gutenberg/packages/core-data/src/entity-provider.js

Line 265 in 3b89e82

updateFootnotes( edits.blocks );

gutenberg/packages/core-data/src/entity-provider.js

Line 277 in 3b89e82

updateFootnotes( edits.blocks );

I'm wondering if the solution would be extending the options object with an optional callback, example for onInput:

const onInput = useCallback(
	( newBlocks, options ) => {
		const { onEdit, selection } = options;
		const edits = { blocks: newBlocks, selection };
		registry.batch( () => {
			onEdit?( newBlocks );
			editEntityRecord( kind, name, id, edits );
		} );
	},
	[ kind, name, id ]
);

where onEdit in the most simplistic case would look like:

function onEdit( blocks ) {
	updateFootnotes( blocks );
}

onInput could look very similar.