- 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 usingDynamicPropSource
, and at-render-time, by usingContextAwarePluginInterface
), 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
StaticPropSource
s! And some block plugins sure do have very complicated structuresβ¦IOW:
- the explicit inputs for an SDC are "props", and SDC offers no UI for these. (There are no implicit inputs.)
- 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. - π¬π§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.