Rethink the separation between editor and blocks module

[youknowriad]

Originally, these two modules were separated because we thought that it was possible to create blocks without the need for an editor concept. This led us to:

• Define the library of blocks inside the editor module
• The block registration API lives in the blocks module
• We added a bunch of components to be used by block authors to build blocks into the blocks module.

But this proved to have several drawbacks:

• We need to introduce "editorSettings" using context because some of the components in the blocks module change their behavior depending on editor settings which means the blocks can't be totally independent from the surrounding editor.

• The "shared blocks" are saved into the editor's state but the block itself is declared in the blocks library. This indicates that shared blocks are a concept not independent from an editor's store.

• The image block needs to attach uploaded images to the post used in the editor

• Blocks need access to the list of available blocks (for autocompleters for instance) and we need the editor store and the editor settings to know exactly what blocks are available.

• InnerBlocks used internally by nested blocks uses BlockList from the editor.

Proposal

1- Extract the block library to a blocks-library module depending on Editor and Blocks
2- Introduce a JS action blocks.register for block authors to register their blocks as a response to this action. This action needs to trigger after all the JavaScript files are loaded (domReady?) to avoid issues with loading order. Still allow direct registration for backwards compatibility for some releases.
3- Move the components defined in the blocks module to the editor's module while providing backwards compatibility for some time (wp.blocks.* = wp.editor.*)
4- Keep only the block registration and api in the blocks module.

Thoughts? @WordPress/gutenberg-core

• - Extract the core blocks from the blocks module Try extracting the block library into a separate module #6351
• - Move components to editor. Framework: Move components from the blocks to the editor module #6521
• - Refactor editor settings to use the editor store instead of context Move the editor settings into the editor's store #6500
• - Move editorMediaUpload to the editor module Move editorMediaUpload to the editor module #6682
• - Show saved blocks in autocompleters
• - Audit the usage of context in the editor module and check if we can't replace with data store.
• - Rename some hooks blocks.*

[mikka23]

This sounds like the opposite direction from what I was hoping for. As a developer for a third party builder having the blocks tied to the editor creates a major long term problem because it limits what I can do with blocks outside of the Gutenberg editor.

[aristath]

Ideally blocks would be separate entities that would be reusable in contexts other than the editor too... There's a whole industry of page-builders and site-builders out there. Everyone would benefit if it was possible to reuse blocks outside the editor

[maximus80]

If blocks served as data structure plus API to re-use and manipulate data, which would be the most versatile setup, it seems to make most sense to implement them agnostic of the editor. In that case the editor could use the same API as other, alternative editors and builders to display and manipulate blocks. Post contents would be open to a variety of UIs and page building services instead of being locked to just one core component.

[youknowriad]

@mikka23 @aristath @maximus80 I think you're misunderstanding the purpose of the editor module as it exists today. The editor module is not a concept tied to the WordPress post editor. It's a generic module to build any kind of block editor, not only the post editor of WordPress which corresponds to the edit-post module.

Blocks can't be rendered without a surrounding editor, whether this editor is a post editor, a frontend editor, a customizer editor, that's another question, and the editor module already allows to build different kind of editors.

[aristath]

@youknowriad tbh I haven't checked the code in a while... Last time an attempt was made to do what we needed, this had to be applied before: #5691
Perhaps now it's possible without it, haven't checked yet

[gziolo]

To echo what @youknowriad said. blocks module should contain only all API methods required to register, parse, save or operate in a general on block types. This is something that could be shared between frontend and admin interfaces. To give you an example EditBlock doesn't make much sense in the context of the frontend, because you rather want a different logic when serving blocks to the end users rather than when configuring them by users with more privileges. FrontendBlock is not planned for the initial release, but it is something which in my opinion will happen at some point.

[gziolo]

1- Extract the block library to a blocks-library module depending on Editor and Blocks
2- Introduce a JS action blocks.register for block authors to register their blocks as a response to this action. This action needs to trigger after all the JavaScript files are loaded (domReady?) to avoid issues with loading order. Still allow direct registration for backwards compatibility for some releases.
3- Move the components defined in the blocks module to the editor's module while providing backwards compatibility for some time (wp.blocks.* = wp.editor.*)
4- Keep only the block registration and api in the blocks module.

Totally agree on (1), (3), (4). I didn't consider (2) earlier, but given that we had so many issues with the order of blocks registration so far it makes a lot of sense. Hopefully, we can hide those hooks as an implementation detail, so you could still call wp.blocks.registerBlockType, but core would ensure it is deferred until the mythical domReady happens :)

Nit: blocks-library - maybe core-blocks to align with core-data? 😄

[youknowriad]

I'm going to close this as the big updates already landed.