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.

[samueljseay]

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.

Yeah I think this is fair. In the end I found I didn't need to use it on the frontend so from my perspective it was probably a mistake I was using it there. It's sometimes a little difficult to determine which API to use front-end to access WP data.

[gziolo]

I opened #67687 to better illustrate the idea shared in #64604 (comment). CI is fine with the refactoring. I would appreciate feedback if that direction is promising enough to take it to the finish line.

[jsnajdr]

maybe a direct usage of api-fetch could be enough for WooCommerce's use-case.

I've been recently looking at Woo's Cart and mini-Cart blocks and I came to a similar conclusion. wp-data is adding a really big amount of abstraction to something that could mostly be a simple fetch. Especially in the mini-Cart case. Also using React Query and its useQuery and useMutation hooks could be very convenient an enjoyable for this kind of code.

But there is one big caveat: the wc/store/cart store is a shared "source of truth" not only for the two built-in blocks, but also for any other extender who needs to access the Cart data and state. In other words, select( 'wc/store/cart' ).getCartData() or dispatch( 'wc/store/cart' ).setShippingAddress() is also a public API. We'd need to replace that with something else. It shouldn't be terribly hard, it could be a window.wc.cart object with methods, but needs to be considered. Using hardcoded and bundled apiFetch calls somewhere inside Cart components is not accessible and reusable by other parts of the frontend.

[gziolo]

Based on the feedback from @jsnajdr shared in #67687 (comment), I closed #67687. The path forward is to move all necessary code from @wordpress/block-editor to @wordpress/blocks and consume it from the new home in @wordpress/core-data. @jsnajdr, do you plan to work on the implementation?

[jsnajdr]

do you plan to work on the implementation?

Yes, I see that my proposal is universally liked, nobody says it's a bad idea, so I'm ready to implement it 🙂

[jsnajdr]

I implemented the separation of core-data from block-editor in this PR: #67870.