Packages: Extract edit post package

[gziolo]

Description

Partially addresses #8421.

There are no breaking changes so far even though this PR has some refactorings:

• Rename PluginsBlockSettingsMenuGroup and move to editor package - PluginBlockSettingsMenuItem was an internal component in edit-post so couldn't be really used.
• Update PluginBlockSettingsMenuItem to align with docs - we need to decide whether we should fix docs instead.

Testing

Example plugins for the following components can be found inside e2e tests folder:

• PluginPostPublishPanel
• PluginPrePublishPanel
• PluginPostStatusInfo (it is covered by actual e2e test case)

The easiest way to test it is to use docker image for e2e tests and activate manually the following plugin: Gutenberg Test Plugin, Plugins API and ensure that they work as expected.

TODO

• Extract plugin components into @wordpress/edit-post package.
  • PluginBlockSettingsMenuItem
  • PluginPostPublishPanel
  • PluginPostStatusInfo
  • PluginPrePublishPanel
  • PluginSidebarMoreMenuItem - this should be its own PR
  • PluginsMoreMenuGroup - this should be its own PR
  • PluginSidebar - this should be its own PR
  • PinnedPlugins - moved to @wordpress/plugins (Plugins: Move PinnedPlugins component #9312)
• Rename PluginsBlockSettingsMenuGroup and move to editor package.
• Update PluginBlockSettingsMenuItem to align with docs.
• Extract parts of the store into @wordpress/edit-post package.
  • activeGeneralSidebar - this should be its own PR
  • pinnedPluginItems - moved to @wordpress/plugins (Plugins: Move PinnedPlugins component #9312)
• Update documentation
  • package README
  • store reference - this should be its own PR

[youknowriad]

So let's think about what each package is and see how this PR fits:

1- The editor package is the package exposing Components you can compose together to "implement" a block editor.

2- The edit-post package is the implementation of the editor in the WPAdmin's editor page.

In the current PR, we're exposing some parts of edit-post as an external API and If I understand properly, these APIs are meant to be used to "implement" other editor layouts. It's kind of weird to use an implementation to build another implementation. So What I think is:

• If these components are usefull to build alternative implementations, maybe they can be moved to editor? unless we're just trying to gain some time and ultimately, these components will have specific implementations in the long run in which case, it's wrong to expose them entirely.
• The only public API the edit-post module should have is initializeEditor( config ) which intializes the WPAdmin specific editor layout given some config.

I think it's probably too soon to make such a decision (whether these components are implementation details or should be reused across implementations). I'd be in favor of waiting for alternative implementations to emerge and see if they really need these components or it's just a gain of time.

[gziolo]

The only public API the edit-post module should have is initializeEditor( config ) which intializes the WPAdmin specific editor layout given some config.

Let me disagree with this statement. All those components listed are part of the public API, too. They are already exposed as part of wp.editPost.* because there are essential for plugin developers to register their own plugin implementations. See:

BTW, I'm surprised reinitializeEditor is exposed, too.

[tyxla]

I tend to agree with @gziolo here. As plugin developers, we should have full access to edit-post and its innerworkings, so I'd expect they're part of the public API.

To be honest, I was surprised to see that there's no edit-post package back when I was working on Automattic/wp-calypso#26603 - in this one we had to still rely on the global wp variable.

I understand this is already an implementation of the editor, meant to be used in wp-admin, but I think this shouldn't be a strict limitation - we can always make edit-post work in a synthetic environment emulates wp-admin but is different than it - I recall working on custom dashboards before, and if I wanted to embed Gutenberg there, I'd definitely start from implementing it in a similar way to how it's done in wp-admin.

[tyxla]

It feels a little odd to have PluginsBlockSettingsMenuGroup and PluginBlockSettingsMenuItem being parts of different packages - could you please clarify the rationale behind that decision?

[gziolo]

PluginBlockSettingsMenuItem is just one of the implementation of the PluginsBlockSettingsMenuGroup fill. In fact, it is a wrapper which enforces consistency across all menu items added in edit-post. My reasoning is that this slot is general purpose for all editor implementations. The same applies for other slots like InspectorControls and BlockControls - they only define the place where plugins can put they fills, they don't have any opinions. You could use them directly as it happens with blocks and their definitions, but using an abstraction will help us to apply those block settings only in edit-post context. It is still possible to use PluginsBlockSettingsMenuGroup fill directly, but this is going to be a bit more complex.

I'm happy to discuss it further, this is something that needs some more thought as this is something that might have implications in the future if we don't limit its usage by scoping it.

For the better context, we already did some exploration for edit-template page which would allow you to use blocks to build your own page template. This is why I'm not sold on the idea of having specialized implementations inside editor package as they might show up in the context some plugin developers didn't intend to. It's safer to assume all plugins are applied to edit-post as of today and move it up to editor in the future than the other way around.

[tyxla]

Gotcha, thanks for clarifying 👍

[gziolo]

PluginSidebar depends on shared state with DocumentSidebar and BlockSidebar - to move forward we would probably have to decouple it or convert those 2 components to plugins to make it possible to use general-purpose state. That's why removed them from this PR with 9b859a8.

[gziolo]

@youknowriad took a different approach in #10429 which moves all code from edit-post to its own package. Closing this one as it is no longer relevant.