Handle block contexts

How will that be conveyed in the UI? How will the user be informed that more/different choices become available depending on the context they're editing a component tree for?

@lauriii: Is this in scope for 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active ?

Would it be possible to provide a list of blocks that this impacts and what are the contexts they depend on? This would help me understand the impact of this and would make this more actionable for design.

Is there some existing UX for this in the Block module or Layout Builder?

Would it be possible to provide a list of blocks that this impacts and what are the contexts they depend on? This would help me understand the impact of this and would make this more actionable for design.

Grep for context_definitions: [ ("block" attribute), context_definitions = { ("block" annotation) or context_definitions'] (in block plugin derivers).

That surfaces the following (derived) block plugins in core:

• \Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver
• \Drupal\layout_builder\Plugin\Derivative\ExtraFieldBlockDeriver
• \Drupal\views\Plugin\Derivative\ViewsBlock

Is there some existing UX for this in the Block module or Layout Builder?

AFAICT there is not. It's "magic"; it's precisely the much more narrow constraints of the Layout Builder UX that mean that there wasn't a need for a generic UX for this in core. Views similarly provided a narrower UX when configuring Views blocks (and the Block UI then didn't visualize it, nor provided affordances).

It's precisely the lack of properly informing the end user that makes the Block UI so bad, and which XB should do better.

P.S.: I'm totally fine with saying: XB does not support any block plugins that have optional or required contexts defined. But we'll need to figure this out before we can migrate/upgrade Layout Builder to XB.

This is not in scope for 0.2.0. Potentially not in scope for 1.0.0 but need to evaluate later.

Thanks for clarifying, @lauriii!

📌 Define `props` in the context of Block components Active is working on supporting Block-sourced Component's explicit inputs: settings (equivalent to SDC-sourced Component's explicit inputs: props).

This issue is about supporting Block-sourced Component's implicit inputs: contexts. There is no equivalent of this for SDC-sourced Components, but there may be for other component types. See 🌱 [META] Support component types other than SDC Needs work .

tagging for findability

Adding to #4: 📌 Handle block contexts Active Grep for context_mapping in `type:block_settings`

    context_mapping:
      requiredKey: false
      type: sequence
      label: 'Context assignments'
      sequence:
        type: string

In block placement UI, you can set the mapping if a block is context aware:

I've been exploring this in the context (pun intended) of some other work, so documenting findings.

Contexts won't be always implicit inputs, but also explicit inputs. When a plugin is context aware, there are still different scenarios:

- Context is required
- Context can be optional.

Drupal block placement UI, conditions UI, and Layout builder UI itself expose a mapping form when:

- Context is optional (because I can select no context or the matching context)
- There are more than one populated runtime contexts matching the plugin (block) expectation.

See \Drupal\layout_builder\Context\LayoutBuilderContextTrait::getPopulatedContexts and \Drupal\Core\Plugin\ContextAwarePluginAssignmentTrait::addContextAssignmentElement.

What we will need here:

- Remove the check for context definitions in ComponentSource\BlockComponent::checkRequirements

- Previews might be broken (as an exception might throw) if no matching context exists. Layout builder uses createWithSampleValues for preventing that, see \Drupal\layout_builder\Entity\LayoutBuilderSampleEntityGenerator. We will need something similar.

- BlockComponent::renderComponent needs to apply the runtime contexts. We might want sample values when isPreview is true.

In the future we might want to actually have PropExpressions for context data to be able to map them to SDC or JsComponents or other ComponentSources, but that's out of scope here.

I've validated some of this with timplunkett, so crediting him too.

penyaskito → credited tim.plunkett → .

FYI: 📌 Consider renaming the 'inputs' column on ComponentTreeItem to 'input' Active .

wim leers → credited larowlan → .