"block score"? "blocks core"? Let's call it block-api instead.

There’s no real reason to keep this module [the library of blocks] separate from the editor module.

I'd propose calling this block-library instead. But I agree that is a task for a separate PR :)

Thinking out loud here and continuing conversation from #2119 (comment), as this was on my mind yesterday. I started to question: What is a block without an editor? One cannot exist without the other. But indeed we made a decision early on to split out blocks into its own module because we wanted them to be agnostic to the specific editor, in our case the post editor we're building. But if we're now discussing extracting the core editor bits (#2065), should we not reevaluate whether it makes sense that the block core be independent from the editor core, or should instead seek to converge them?

should we not reevaluate whether it makes sense that the block core be independent from the editor core, or should instead seek to converge them?

Not against merging them but at the moment the editor is not the editor-core, it's everything. So this PR extracts blocks-core. Once we extract editor-core we can decide if these two belong together or not.

"block score"? "blocks core"? Let's call it block-api instead.

I'm ok with that, blockapi then :)

If we're splitting a blocks "core" from blocks with the intent that what would remain of blocks is to be merged into an editor core anyways, why would we even take the step of creating a separate core instead of just moving out the bits that aren't relevant as "core" from blocks. i.e. it sounds like you're suggesting we'll have block-api, and then eliminate blocks. Why can't we just keep the core as blocks?

I think we're getting a little ahead of ourselves...

I'm suggesting we create blocks-api in this PR and rename it later to blocks once we merge what's currently remaining in blocks into editor. I just don't want this PR to be bigger.

Anyway, I think I'm missing something obvious but can anyone tell me why the JS tests are failing?

Ok so renamed the module blockapi and fixed the JS unit tests. Should be better now

Let's go with block-api with a hyphen separator for readability.

I haven't reviewed this in detail, but at a high level the changes are reasonable, and removing the global state from the block registration API makes sense.

I'm suggesting we create blocks-api in this PR and rename it later to blocks once we merge what's currently remaining in blocks into editor. I just don't want this PR to be bigger.

I am not so convinced about this part.

I think we should merge this PR and continue to discuss the next steps.

@nylen Can't you hyphen, right now. I haven't taken a deep look to this, but for some reason, our build fails. Will see if I can fix it.

Edit: I don't know what happened the first time I tried, but block-api worked like a charm. Updated.

I think I'll merge this right after today's release.

Codecov Report

Merging #2182 into master will increase coverage by 0.08%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master    #2182      +/-   ##
==========================================
+ Coverage   26.44%   26.53%   +0.08%     
==========================================
  Files         157      158       +1     
  Lines        4851     4892      +41     
  Branches      819      820       +1     
==========================================
+ Hits         1283     1298      +15     
- Misses       3015     3041      +26     
  Partials      553      553

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c8c8078...1f23e41. Read the comment docs.

I'd like to give this a look, but won't be able until next week.

I thought of a reason not to do this: prohibiting plugins from registering blocks in the core namespaces.

This is much easier to achieve if our registered blocks live in the same ES6 module as the block API, because then we can use an internal flag that is not exported out of that module. See #2241 - the approach taken there would no longer work after this PR.

I think we can probably achieve the main goal of this PR ("don't rely on the globally registered blocks anymore") without creating the new block-api module.

@nylen I don't see why the approach in #2241 won't work with this PR, The global variable and the registration API are still in the same module.

@mtias do you mind taking a look at this, I'd like to merge it soon in the week :)

@nylen I don't see why the approach in #2241 won't work with this PR, The global variable and the registration API are still in the same module.

Because this flag is completely internal to the blocks module, it is not accessible by third-party code.

In this PR the flag would be internal to the block-api module. So the blocks module - which registers the blocks for the editor - cannot use it.

In order to achieve "don't rely on the globally registered blocks anymore", why do we need to split the blocks module in two? Why should the block API be separate from the blocks that will use it most often?

@nylen Registration is not part of the block-api module so why should we declare this variable in this module?

Why should the block API be separate from the blocks that will use it most often?

Because the block API is used by a generic Block Editor while the registration and the blocks are WP specific. A potential generic editor module, let's call it "editor-core" will be dependent on the "block-api" module but do not depend on the "blocks" module, and the final "blocks" module will depend on both "block-api" and "editor-core", so this PR resolves the inter-dependency issue.

"block-api" and "editor-core" could be merged later (like suggested by @aduth) since they'll be both low-level modules but if we merge "blocks" and "block-api", this means we'll have to merge everything in a unique module.

Registration is not part of the block-api module so why should we declare this variable in this module?

I assumed that registerBlockType would be part of block-api since it's the main function of our block API today.

What role does registerBlockType play after this PR? I expected that the changes here would make it accept and modify a config object rather than a global config.

What role does registerBlockType play after this PR? I expected that the changes here would make it accept and modify a config object rather than a global config.

It has the same role as today which is: "declare that a block type in WordPress"
but For an editor to actually use this block type, it has to be included in its config when initializing the editor (see EditorSettingsProvider). For now, the init function just retrieves all the registered blocks to build this config object, but later a PostEditor, a FieldEditor, a CustomizationEditor, a CPT Editor could pick different block types.

The rebase today was very difficult to do, I'd really appreciate some help to move this forward.

but later a PostEditor, a FieldEditor, a CustomizationEditor, a CPT Editor could pick different block types

Won't all of these things want basically the same block types, with some minor variation that could be easily captured in the block settings? e.g. { showInContent: false, showInCustomizer: true }

Because the block API is used by a generic Block Editor while the registration and the blocks are WP specific. A potential generic editor module, let's call it "editor-core" will be dependent on the "block-api" module but do not depend on the "blocks" module, and the final "blocks" module will depend on both "block-api" and "editor-core", so this PR resolves the inter-dependency issue.

I'm not convinced that this distinction will actually be so valuable in practice: we're not building a generic block editor, we're building a WP block editor.

Won't all of these things want basically the same block types, with some minor variation that could be easily captured in the block settings? e.g. { showInContent: false, showInCustomizer: true }

That's exactly how I see it too, but to avoid filtering the blocks in all the places we use the block types, we only filter them once, once initializing the editor.

I'm not convinced that this distinction will actually be so valuable in practice: we're not building a generic block editor, we're building a WP block editor.

Good point, but despite the architectural benefits genericity brings, there are practical benefits too. I'd imagine us needing to load multiple block editors in the same page (say one for the editor, one for a meta-box) or multiple ones in the customizer for different areas. It's not possible right now because all the editor's state is mangled with the Application state (posts, ....). This PR is the first step to bring this genericity.

it sounds like you're suggesting we'll have block-api, and then eliminate blocks. Why can't we just keep the core as blocks?

I think this is relevant, and from a quick glance it looks like this is not what is happening.

Overall this looks good, but would need more time to review this.

closing this one, it needs more thinking