Experiment: A Modules API with optional static server dependency graph

[luisherranz]

What?

Built on top of #56092.

This is the second of a series of experiments to understand the requirements of a hypothetical Modules API. More info in the Tracking Issue:

• Tracking Issue: Script Modules API #55942

This experiment aims to implement an API that is slightly more complex than the one implemented in the first experiment, with the same characteristics but adding an optional static server dependency graph to be able to preload modules and avoid initial waterfalls:

• An API to register modules using:
  • A module identifier (required)
  • The full URL or the path (required)
  • Whether the module is for the admin, the frontend or both (required)
  • A version (optional)
  • The static dependencies (optional)
• An API to enqueue modules.
• All registered modules add an entry in the import map.
• Enqueued modules add a <script> tag in the head.
• The static dependencies are preloaded when the module is enqueued using a <link rel="modulepreload"> tag in the head.

Why?

In the first experiment, it's not easy to know which modules need to be preloaded and, therefore, it's not easy to avoid the initial waterfalls.

How?

By leveraging a new Gutenberg_Modules class that acts as a singleton and a couple of functions to expose the functionality:

• gutenberg_register_module to register modules and add entries to the import map.
• gutenberg_enqueue_module to enqueue modules.

Then, we print three times using the wp_head action:

• The import map.
• The enqueued modules.
• The preloaded modules.

Testing Instructions

• Add some interactive blocks: Navigation, Query or Image block.
• Check that in the frontend, there is an import map script.
• Check that scripts with type="module" are loaded by the interactive blocks.
• Check that the @wordpress/interactivity module is loaded by the other modules using import ... from "@wordpress/interactivity".
• Check that the @wordpress/interactivity module is download at the same time than the rest (instead of after, like in the first experiment), and that there is a link tag with rel="modulepreload" in the head.

[youknowriad]

I think at some point in our config we need to maintain an esmodules array to keep these as is in the code (just like we have a dedicated config for bundled modules). I expect interactivity to be just one of these modules

[luisherranz]

Yeah. I didn't pay much attention to the bundling side yet as it shouldn't affect the PHP API, so I just made it work 😄

(I'm not a fan of the code produced by Webpack for ES modules, by the way.)

[youknowriad]

I really like how this simplifies the code of all these "interactive" blocks.

[gziolo]

This is now part of WordPress core 🎉

The final approach is documented in the dev note: Script Modules in 6.5.