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.

• [X] Yes

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

• [X] Yes

[Mamaduka]

The same concern has been raised in the original PR - https://github.com/WordPress/gutenberg/pull/51201#discussion_r1234153951.

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:

https://github.com/WordPress/gutenberg/blob/3b89e826bf23523dcbfa5e3525fafe4852143b41/packages/core-data/src/entity-provider.js#L199-L200

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 https://github.com/WordPress/gutenberg/pull/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:

https://github.com/WordPress/gutenberg/blob/3b89e826bf23523dcbfa5e3525fafe4852143b41/packages/core-data/src/entity-provider.js#L248-L249

https://github.com/WordPress/gutenberg/blob/3b89e826bf23523dcbfa5e3525fafe4852143b41/packages/core-data/src/entity-provider.js#L272-L273

and the same usage of the callback:

https://github.com/WordPress/gutenberg/blob/3b89e826bf23523dcbfa5e3525fafe4852143b41/packages/core-data/src/entity-provider.js#L265

https://github.com/WordPress/gutenberg/blob/3b89e826bf23523dcbfa5e3525fafe4852143b41/packages/core-data/src/entity-provider.js#L277

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.