Block API: Initial explorations to migrate to server-registered blocks #3962
Conversation
aduth
added
the
[Feature] Block API
|
|
||
| do_action( 'init' ); | ||
|
|
||
| echo json_encode( gutenberg_prepare_blocks_for_js() ); |
There was a problem hiding this comment.
So why do we need these fixtures? For test purpose?
Maybe the unit tests should not rely on the fixtures (on the default blocks), we'll probably lose some coverage but I think the unit tests should be "isolated" tests.
There was a problem hiding this comment.
So why do we need these fixtures? For test purpose?
Right, without these, the block content fixture tests fail too, since otherwise the Node process has no way to know what are the attributes of a paragraph block.
There was a problem hiding this comment.
Not for this PR, but I think we should avoid registering the default blocks in the tests completely and just provide "dummy blocks" in tests.
| @@ -49,6 +49,12 @@ let defaultBlockName; | |||
| * registered; otherwise `undefined`. | |||
| */ | |||
| export function registerBlockType( name, settings ) { | |||
| settings = { | |||
There was a problem hiding this comment.
I guess we should update our documentation to favor SSR registration if we go all server side. At that time we could decide to add a "warning" here if the corresponding registration is not found (for a smooth migration)
There was a problem hiding this comment.
I guess we should update our documentation to favor SSR registration if we go all server side.
Agree.
At that time we could decide to add a "warning" here if the corresponding registration is not found (for a smooth migration)
Customizer controls are bootstrapped in a very similar way, and I find it interesting there's no inclination for developers to go straight to using the JavaScript APIs. I guess one difference here is that we'd probably assume there is a JavaScript counter-part for defining the UI behaviors. Part of my thinking with #2756 is that by moving the script handle to being a property of the block register API, it would require some unconventional hoop-jumping to register the JS block any other way.
Maybe to your earlier work on feeding the editor components with the registered blocks, it would make sense to warn here, since then the editor would still be generic enough to work with client-only blocks in non-WordPress contexts.
|
I'm going to rebase to drop the 615320c76f816226fd871c1301ff9e6adbed4db8 commit (moving paragraph block registration to server) so we can at least move forward with basic support for block bootstrapping outside just attributes. |
aduth
force-pushed
the
try/server-register-script
branch
from
615320c to
4405b97
Compare
|
@aduth love seeing this PR! |
github-actions
bot
added
the
[Status] In Progress
Related: #2751
This pull request starts to iterate toward server knowledge of registered blocks. This isn't intended to limit the capabilities of a client editor, such that editors are strictly dependent on a WordPress back-end, but opens options for the server to operate from a list of all known blocks (e.g. a settings page dropdown for "default block type", REST API endpoints listing all available blocks on a site).
Eventually I could see this tying into #2756, where all blocks begin by registering a block type from the server, with an associated script handle to define the client-specific form handling. The script may even be optional for very early block prototyping. Having better awareness of blocks and their associated scripts and styles could also enable two optimizations:
Implementation notes:
The first iteration seeks to expand the scope of the already-present server block attributes bootstrapping to include a broader range of block properties, not just attributes.
It also improves the server fixtures generation to load more of a WordPress context, as previously we'd merely stubbed the
register_block_typefunction. As more core functions would have been used (e.g.__), this would not have scaled.The paragraph block was ported as an example, though I'm not sure I'd want to merge with a single example port. I think it'd be preferable to either port all blocks, or none at all.
Testing instructions:
Verify that there are no regressions in the registration of the paragraph block, including title, icon, category, keywords, supports (custom class name), attributes behaviors.