Block API: Add parse options to specify custom source handling

[aduth]

Related: #16282, #5077
Fixes #4989

This pull request seeks to explore a small part of proper handling of custom sources as part of the parse stage of editor initialization. Specifically, the changes here are alone sufficient to resolve the issue described in #4989. With these changes, a new options object can be passed with wp.blocks.parse to control behavior of the attributes derivation. Unlike #5077, this is exposed as part of the top-level API rather than as a hooks filtering. Hooks could still serve this purpose, but as of latest consideration are being discouraged, and could work unpredictably in nested editor environments.

In-Progress Notes:

• Needs unit tests
• There is another direct parse which occurs in the code editor (source) which should be consolidated

Effectively, I'm not too committed to the direction here, and am opening to solicit some early feedback in considering whether to continue as a solution.

[jorgefilipecosta]

While we are on early stages I guess this API could be a basis for a more high-level set of sources e.g: a WP REST API source (that retrieves attributes from a rest API) a post source that retrieves attributes from the post itself etc.

I'm curious to see how we can expand this basis to support async attribute fetching. It would also be important to check how the attribute saving will work. Here we are dealing with how we retrieve a given attribute but that attribute may be changed by the block. The custom attribute sources also need to define a storing mechanism, I guess we want the way to defined how the attribute is read to be similar to the way we defined how the attribute is stored so ultimately the custom source storing API may impact this API.

[jorgefilipecosta]

Hi @aduth,

the value a function receiving an attribute schema and expected to return the desired value.

Would it make sense for the function to also receive the innerHTML plus the commentAttributes?

Imagining the following scenarios:
- an attribute that is derived from the text in a given HTML element.
- A product block that contains the id of the product as a comment, and we want to query some attributes of that product using an external REST API.

[jorgefilipecosta]

Is there any plan to allow, plugin developers to create custom sources and use them in their blocks?

[jorgefilipecosta]

Would it make sense to allow an async retrieval of the value? Imagining cases where external requests are required to retrieve the value. I guess it would increase the overall complexity of the module.

[aduth]

Thanks for taking a look @jorgefilipecosta !

It would also be important to check how the attribute saving will work. Here we are dealing with how we retrieve a given attribute but that attribute may be changed by the block.

Yeah, in reflecting on this after the initial publication, I think a major downside to this approach is it breaks down the "cycle" or idempotency of block parsing vs. serialization.

The mechanisms around how a custom source might save are being explored further in #16402, although admittedly meta are one of the simpler examples since they can leverage existing editor functionality around updating post properties.

I don't know that I'm likely to pursue this approach much further. With #16402, we might instead be able to do something where we "defer" the validation to occur only after meta values have been applied. I expect it might look similar to what we have here so far as an options object for parse, and basically changing this line:

gutenberg/packages/editor/src/store/actions.js

Line 62 in 707336c

let blocks = parse( content );

...to:

let blocks = parse( content, { validate: false } );

(The default would be true to maintain backwards compatibility)

Then, we can expose a function to manually run validation over a set of blocks.

[aduth]

Closing in favor of #16569