Define `props` in the context of Block components

Created on 30 October 2024, 16 days ago

Overview

In SDCs, we have props (scalar values that affect the output) and slots (places where further HTML can be embedded).

Blocks have no slots, but they can have "block settings". These are used to configure the block and (in most cases) affect its output in some way. Examples are the number of levels of hierarchy to show in a menu block, or checkboxes to control which elements are displayed in the site branding block.

Are block settings conceptually similar enough to props that we can treat them as the same thing? As well as static block settings, do we want dynamic block settings? For example if you had a term field on a node, you might want to map that field value into a block setting so you can embed a list of related articles on the node that automatically corresponds to the selected term.

Proposed resolution

?

User interface changes

πŸ“Œ Task
Status

Active

Version

0.0

Component

Data model

Created by

πŸ‡¬πŸ‡§United Kingdom longwave UK

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @longwave
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    Are block settings conceptually similar enough to props that we can treat them as the same thing?

    No, we can't treat them as the same thing.

    See #3484669-4: Define how block settings should be presented in the UI β†’ and the comment it links to.

    As well as static block settings, do we want dynamic block settings?

    AFAICT we don't, because that'd pretty much duplicate the "context" concept that blocks use, but in a more narrow sense:ContextAwarePluginInterface can consume any context, not just that of the host entity. In other words: this would AFAICT "just" be duplicating the equivalent in Blocks-as-XB-Components what \Drupal\layout_builder_fieldblock_test\Plugin\Block\FieldBlock already does … but because then there can be "dynamic resolution of values" at two stages (pre-render-time, in XB, by using DynamicPropSource, and at-render-time, by using ContextAwarePluginInterface), it'd become very confusing?

    For example if you had a term field on a node, you might want to map that field value into a block setting so you can embed a list of related articles on the node that automatically corresponds to the selected term.

    Hm … πŸ€”

    Can you walk me through how that code flow would work? Is this something like: ? If so, is that not already supported today … through contexts?

  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    OK, so we will need some UI handling for block contexts.

    But if we ignore dynamic values and only allow static block settings: why do we have to treat them any differently from static props? They are validatable values, that affect the output of the component.

  • πŸ‡ΊπŸ‡ΈUnited States tedbow Ithaca, NY, USA

    Clarifying where we currently call things "props" that might not make sense

  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    why do we have to treat them any differently from static props?

    Because the sole/whole reason StaticPropSource exists is to reuse Drupal's Field/Typed Data infrastructure to A) store, B) manipulate (through a UI) values for SDC props.

    But block plugins already offer a UI, so the "B) manipulate" part is already handled, we only need the "A) store" part. Storing each key-value pair in a block setting in a field seems overkill. And … we do not yet have the ability to store arbitrarily complex values as StaticPropSources! And some block plugins sure do have very complicated structures…

    IOW:

    1. the explicit inputs for an SDC are "props", and SDC offers no UI for these. (There are no implicit inputs.)
    2. the explicit inputs for a block plugin are "settings", and a block plugin does offer a UI for these. (There are implicit inputs too: contexts. β†’ πŸ“Œ Handle block contexts Active )
  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Given that we know we want `props` for SDCs but `settings` for blocks I think we can use this issue to:
    1. Ensure that separation is done everywhere following πŸ“Œ [PP-1] Add support for Blocks as Components Active
    2. Introduce settings forms for blocks instead of props forms for SDCs.

  • Merge request !392#3484666 Implement block settings forms β†’ (Open) created by longwave
  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Repurposing this slightly now we know `props` and `settings` are different, we can use this to figure out how to handle `settings` as the related @todos all still stand.

  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    πŸ“Œ Add support for block derivatives Active is also in, making this more actionable.

    As @larowlan already wrote on Nov 5: needs rebase.

Production build 0.71.5 2024