Block Infrastructure: allow building blocks separately

[jeherve]

Jetpack product discussion

• pedMtX-RS-p2

Background

Jetpack blocks are currently tightly bound to one another:

• The JavaScript on the editor's side is bundled into a single js bundle, in _inc/blocks.
• The tools used to register, enqueue JavaScript, and manage blocks on the frontend all live in one class, Jetpack_Gutenberg.
• Some blocks rely on other classes that ship with the Jetpack plugin: Jetpack_AMP_Support, Jetpack_Options, Jetpack, and for some blocks some classes created specifically for those blocks: Jetpack_Mapbox_Helper and Jetpack_Instagram_Gallery_Helper come to mind.
• Some blocks rely on custom REST API endpoints, living under _inc/lib/core-api/wpcom-endpoints/.

Those blocks were also created before WordPress 5.8 and its new block registration process were introduced:
https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/

Ideally, we would want to switch to this new block registration process for a few reasons:

• It would allow splitting some of those blocks into standalone plugins if necessary.
• It allow splitting each block's dependencies, thus only loading what is necessary when only some blocks are available on a site.
• It would surface the blocks in the plugin description in the WordPress.org plugin directory, thus helping site owners discover what blocks are at their disposal.

Obviously, switching from one big JavaScript bundle with all blocks and their dependencies to multiple files can have a negative impact on performance. This problem may be addressed with some changes in Gutenberg.

Async block loading in Gutenberg

There has been an effort in the Gutenberg project to change the way blocks are loaded, allowing third-party plugins to load multiple blocks without impacting the block editor performance. This project is tracked here:

• Discussion: Block lazy loading WordPress/gutenberg#53260
• PR: Block lazy loading WordPress/gutenberg#51778
• p9oQ9f-1IS-p2
• p9oQ9f-1P7-p2

Tasklist

Tasks

Preview Give feedback

1. Blocks: ensure visibility of Jetpack blocks in w.org profile #32408
   7 of 7
   Blocks V2 [Focus] Blocks [Plugin] Jetpack [Status] In Progress [Type] Enhancement +5
   
2. Blocks: use a single source of truth for blocks metadata #32602
   11 of 11
   Epic [Focus] Blocks [Plugin] Jetpack [Pri] Normal [Type] Enhancement +5
   
3. Block Infra: async block asset loading Block performance #32069
4. Async load business hours and blogging prompt blocks #32256
   [Block] Blogging Prompt [Block] Business Hours [Package] Blocks [Plugin] Jetpack +4
   
5. POC: blocks bundling #32388
   DO NOT MERGE [Block] Business Hours [Plugin] Jetpack [Status] In Progress [Status] Stale +5
   
6. Blocks: Use apiVersion: 3 #34120
   Triaged [Focus] Blocks [Focus] Compatibility [Plugin] Jetpack [Pri] BLOCKER [Status] Priority Review Triggered [Type] Bug [Type] Janitorial +8
   

Requirements (old project)

Note
The requirements below were originally set for a first attempt at this project back in 2021. They do not apply anymore today.

In order to be able to ship some of those blocks as standalone blocks, without the need for the full Jetpack plugin, we'd need to make a few changes:

• Create a package that would include the tools needed for block management (registration, enqueues, build), and that would be shipped with every block. Blocks: introduce new package for block management #17100
• Move out tools from Jetpack_Gutenberg and into the new package if possible and necessary. Blocks: add new methods to new package #17126 Blocks: add AMP and CSS Classes methods to the new package #17101 Blocks: add block registration to package #17167 Blocks: switch all blocks to be registered using new package #17263 Blocks: add block enqueuing methods #17262
• Add additional files currently required for block registration for all blocks that may be available in the block directory: block.json (https://github.com/WordPress/wporg-plugin-guidelines/blob/28d945f414db3bb42e04805fb109e7178cbabc9a/blocks.md), composer.json to register the package defined above as a dependency, readme.txt file, ...
• Create an action that would update standalone GitHub repos every time a block is updated in the monorepo (that action may only be triggered for blocks that have the block.json file above).
• Update textdomains for standalone blocks, maybe as a post-install composer script, part of the jetpack-blocks package.
• If necessary (that won't be necessary for all blocks we want to make standalone), figure out a way to ship the custom REST API endpoints a block needs, and only those.
• Update the blocks that rely on other classes if necessary, so they can live without those other classes when working standalone.

---

Past Jetpack Product discussions

• p9dueE-1VR-p2
• p9dueE-1BH-p2

Async communication

#jetpack-blocks-improvements
#gutenberg-async-loading-code-splitting

[kbrown9]

Update textdomains for standalone blocks, maybe as a post-install composer script, part of the jetpack-blocks package.

I opened a proposal PR #18003 for using the wp-textdomain npm package to change composer package strings. I wonder if that would also be useful for the blocks work. Let me know if you have any comments on that approach!

[kraftbj]

Once the individual block.json files are present and able to provide visibility, we'll put this project on hold while Gutenberg works on the async asset loading solution.

[kraftbj]

I'm going to close this issue since we've done as much as we can until async block loading is present.