Placeholders/#lazy_builder is not supported for block component rendering

Well-spotted!

wim leers → credited penyaskito → .

Two observations:

1. We can't use exactly as-is, because that uses Block config entities; whereas XB uses the underlying block plugins directly. Still, exactly the same pattern can be applied! 👍
2. With one important exception (identified by @penyaskito!): block plugins whose rendering is delayed (by the use of Render API placeholders to execute #lazy_builders as late as possible) prevent emptiness checks necessary only when rendering XB previews

So, I think we'll want to do something conditional: use the current code path when previewing, use what @catch proposes for end users. That'd look roughly like what's in the attached PoC patch — but lots of details left to get right.

Thoughts?

This made me realize something else: 📌 Test coverage to prove that BlockPluginInterface cacheability + BigPipe support work when rendered via XB Active .

Let's first land 📌 Test coverage to prove that BlockPluginInterface cacheability + BigPipe support work when rendered via XB Active , which will clearly demonstrate the problem 👍

This blocks #3518250 — see #3518250-11: [PP-2] Handle components instances rendering nothing: wrap them in a container → .

I don't know too much about XB yet, but I tried a long time ago to do this with page manager, which turned out to be hard to impossible.

A lazy builder must be able to pass all necessary information as a serialized string.

block.module blocks are 100% standalone and isolated, identified just by their config entity ID, so that's easy. The problem for page manager was context (the block/plugin context system). For example, you could have a view with a term argument, and on the page manager page, you have multiple terms as context that you pass in to the various views blocks.

I think XB does not currently have anything like that and not sure if it ever will. But even then, you don't just have a string/ID, You have the whole configuration set for a given block, which might very well include internal information, maybe you have a block with an API key in the config or something like that. So that can't just be serialized out into the HTML placeholder, might also be quite long. Maybe some kind of key-value lookup, a bit like the configuration for entity autocomplete form elements.

You have the whole configuration set for a given block, which might very well include internal information, maybe you have a block with an API key in the config or something like that.

The lazy builder could take the entity ID of the config or content entity, load it, and then find the config for the block in there. It would need enough information to locate it though, not sure what all of that would be (field name at least on entities etc.) but should be finite.

📌 Test coverage to prove that BlockPluginInterface cacheability + BigPipe support work when rendered via XB Active is in.

The problem for page manager was context (the block/plugin context system)

XB doesn't support contexts yet 😅 For that, we have 📌 Handle block contexts Active .

Very interesting observation though, @Berdir!

The lazy builder could take the entity ID of the config or content entity, load it, and then find the config for the block in there. It would need enough information to locate it though, not sure what all of that would be (field name at least on entities etc.) but should be finite.

Yes, I think this indeed doable.

• Every (content or XB config) entity can only have a single XB component tree. We already have the infrastructure to load it for a given entity: \Drupal\experience_builder\Storage\ComponentTreeLoader
• Every component instance in an XB component tree is identified by a UUID.
• The explicit inputs for a component instance are stored in the inputs field property. The structure of that field property is essentially array<component-instance-uuid-string, array|PropSourceArray|AdaptedPropSourceArray|DefaultRelativeUrlPropSourceArray>. See docs/data-model.md#3.2.2 The `field prop` storing the `component input` values.
• That means for a block component instance's lazy renderer, the only information needed would be:
  1. entity type ID
  2. entity ID
  3. component (config entity) ID
  4. component instance UUID.

  The first two are used to load the entity object and pass it to ComponentTreeLoader:

  $entity = $this->entityTypeManager->getStorage($entity_type_id)->load($entity_id);
  $component_tree = $this->componentTreeLoader->load($entity);
  

  The last two are used to load the Component config entity, its source, and to load the stored explicit input from the stored tree's inputs:
  $component = Component::load($component_id);
  $source = $component->getSource();
  // @see \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::getExplicitInput()
  $explicit_input = $source->get($component_instance_uuid, $component_tree);
  

  That should work! 😊

Point to #12 for implementation approach — thanks for prompting, @Berdir & @catch!

akhil babu → made their first commit to this issue’s fork.

I have created an MR based on the patch in #4 with some additional changes
1. Got the following error for blocks
When a #lazy_builder callback is specified, no properties can exist; all properties must be generated by the #lazy_builder callback. You specified the following properties: #prefix, #suffix, #access

So updated the lazybuilder callback to include the #access, #prefix and #suffix properties. But the Drupal\Tests\experience_builder\Kernel\Plugin\ExperienceBuilder\ComponentSource\BlockComponentTest::testRenderComponentLive fails as #prefix and #suffix are not included in the assertion. Should the test be updated, or is there a better approach?

I can think of one mechanism: for ComponentTreeHydrated to detect the presence of #lazy_builder or not, and if it exists, for XB to decorate the component source's lazy builder with its own, so that it's XB's "decorating lazy builder" that adds the prefix & suffix.

P.S.: I doubt my #4 was as precise/accurate as my #12 😅

Related: #3502371-48: Make "Page title block" work A) also outside regions, B) on the only routes XB currently supports: content entity routes → .