Format library: Allow explicit registration when using npm packages

[gziolo]

Description

At the moment we register all core format types right away when @wordpress/format-library is executed as discussed here #10209 (comment):

@gziolo: 'm wondering if we should register core formats right away instead. In effect, don't offer this method at all.

@aduth: 💯 registerCoreBlocks is a necessary hack, and certainly shouldn't serve as an ideal precedent.

Related code:
https://github.com/WordPress/gutenberg/blob/master/packages/format-library/src/index.js#L18-L25

This is not ideal when consuming npm package. This PR was opened to discuss alternative approaches. The idea is to offer more granular integration points for the usage outside of WordPress.

This PR explores the following items:

• getCoreFormatTypes returns an array with all core format types in case someone would want to filter out some of the formats. The shape it returns would have to be defined, I opted for the simplicity of refactoring :)
• registerCoreFormatTypes method registers all core formats as it happens today.
• in WordPress registerCoreFormatTypes is executed right after wp-format-library is enqueued which basically mirrors what happens today.

Whatever we decide here, should be also applied to @wordpress/block-library for consistency.

[youknowriad]

How can we make sure someone use the edit-post module (via npm) get the formats by default?

Can we remove the wp_enqueue_script (and style) in favor of an explicit dependency towards wp-format-library in wp-edit-post?

[gziolo]

Does it mean, we would call registerCoreFormatTypes in edit-post instead?

[youknowriad]

Maybe, It's not perfect because people that want to unregister these styles would need edit-post as a dependency. I'd love other opinions.

[ellatrix]

Thanks for taking care of this.

[aduth]

Why did we land on an array return value here.

[gziolo]

The shape it returns would have to be defined, I opted for the simplicity of refactoring :)

We can make it { name, settings } or reduce everything to { [ name ]: settings, ... }. I'm fine with all of them.

[aduth]

JSDoc.

[gziolo]

Does it mean we are good with the proposal?

[aduth]

#7718 is relevant to consider here, as it includes a new "core" format registered immediately in the @wordpress/annotations package.

I'm on the fence with these functions for registering as it's unclear whether we should consider the idea of registration in tandem with activation, vs. the mere availability of a thing. In practice, we don't make the distinction, which is maybe why we've needed to consider making it an explicit step to trigger the registration.

Could we have more context to this:

This is not ideal when consuming npm package.

?

[gziolo]

This is not ideal when consuming npm package.

I can see the following issue. You can have more than one version of the same package installed from npm, so the issue boils down to using pure functions rather than the global registry to avoid potential conflicts. We had such reports in the past with Calypso loading 2 different versions of @wordpress/data at the same time. More future related question is what if you would want to have 2 instances of the editor with a different set of controls? How can you pass some context during registration of those format controls?

I'm on the fence with these functions for registering as it's unclear whether we should consider the idea of registration in tandem with activation, vs. the mere availability of a thing. In practice, we don't make the distinction, which is maybe why we've needed to consider making it an explicit step to trigger the registration.

For WordPress plugins, it's convenient to register them right away as site owners can opt-in for their usage. In WordPress core we need to provide some way to make it customizable. The same applies to npm where I would expect even more control because you assume it's for very advanced usage.

[gziolo]

I don't think we reached an agreement on this one. I'm closing it as won't fix. I don't see this as a big issue. We can revisit later as soon as we figure out how to deal with server-side registration for blocks.