Where Block module beats Layout Builder

Facts

Drupal core ships Block and Layout Builder modules.

• Block module is in business of placing blocks.
• Layout Builder module is in business of placing blocks.

But...

Block placements are decentralized: Each block placement is a config entity. Several modules can work together to place blocks on the same page. In other words, a module providing a block placement, doesn't know if a different module is also providing a placement on the same page or even on the same region.

while...

Layout Builder placements are centralized: All the block placements are living in a single object (e.g. as 3rd-party settings of the entity view display). This means that the underlying object should know that the modules providing the block exists. As an effect, the object providing the block placements has a hard dependency on modules providing the blocks. Third-parties are not able to hook-in by themselves, they should be dependencies of the module that provides the object providing the placements.

This is, probably, the only advantage of Block module over Layout Builder. Its decentralized nature.

A Use-Case

At European Commission, we're building a library of reusable components (in technical terms: Drupal modules). Let's say we want to provide a landing page, built with Layout Builder & Page Manager, assembling blocks. Each block is provided by different modules, which are reusable units. This means that some projects might want not to use one or more of the modules that are providing the blocks. This not possible right now as the landing page config will have hard dependencies on the modules providing the blocks. But this is possible with the Block module as each module is able to ship their block placements.

The Plan

We need a mechanism that allows a module to hook-into the layout even with the layout knowing nothing about the block placement provider existence:

I plan to address this issue but here is a short list of problems to be solved:

• There's nothing similar to SECTION_COMPONENT_BUILD_RENDER_ARRAY event, but on a section level. This would allow 3rd-party to intercept the produced render array and inject additional components/blocks into the section. A 3rd-party would listen to that event and would ask all modules if they want to provide block placements. There are also other use-cases that are requiring to be allowed to alter the section render array. We can collaborate to push Third party should be allowed to alter the section render array in core.
• As soon as the previous point is fixed, we need a storage for these kind of block placements. An entity where to store a single placement together with the block plugin data (ID and configuration) and a set of conditions that allows to decide in which layout, section and region to store that particular block placement. But wait! This is very close to what the Block (block) config entity offers right now: the plugin, the plugin configuration and a collection of condition plugins. Seems that we can use this for our scope. But no, unfortunately the Block (block) config entity is too coupled right now to theme and region. Would it be possible to push a patch in Drupal core to relax this dependency on theme & region (i.e. to make the theme/region optional)? Maybe yes, but for sure it would take a long journey till that would land in the Drupal core codebase. Given all these, I'm planning to create a contrib module that will define a new config entity type, very similar to Block (block), but decoupled from the theme. This module should ship a layout/section/region condition plugin that knows to determine if the block placement is in the context of a given region from a given section from a given layout. Probably this is not that easy, as it might need a new plugin type so that each plugin knows to deal with different layout builder storage types.
• We need to address the representation of these "alien" placements in the Layout Builder editor. Can we use something similar to placeholder text, to indicate that block is provided by a certain module and cannot be configured/removed in the layout editor? Also, as the new block placement entity will define also a weight, needed to for reordering, could we allow it to be ordered with drag and drop, directly in the Layout Builder editor? This part is more a nice to have but would help for a better UX.

Long Term Plan

• Fill a Drupal core issue to relax the block theme dependency and allow Block (block) config entity to be used for Layout Builder region placements.
• Integrate the contrib module in core.