Field storage

(Legend: = TODO, = working)

Goals

• Being able to create, store, edit and view component trees.
  • Note: viewing component trees must support component prop values of sourceType == static:… ("fixed values") and sourceType == dynamic ("dynamic values": fetched from the host entity using a StructuredDataPropExpressionInterface)
  • WITH test coverage
• Editing individual sourceType == static:field_item:<field type> prop values using field widgets in modal dialogs.
  • WITHOUT test coverage: viability alone is sufficient

Non-goals

• Good UX
• Any UI to change the expression used for a sourceType == dynamic prop value
• Nested components
• Translations
• "default" component trees aka bundle-defined defaults (in the Capabilities Doc: "content type templates"), which this field ought to store the additions/overrides for; it should no repeat the defaults.
• API representation (JSON:API) or otherwise

MR contents

• New field type based on @effulgentsia's proposal at https://www.drupal.org/project/drupal/issues/3440578, with 3 properties:
  1. tree to store the component tree
     • Here just restricted to a component list, not doing nesting yet. That should happen in !2 (merged).
  2. props to store the props values assigned to the components in the tree
  3. 932ce4b9: hydrated to compute the combination of both — and available as both a JSON blob with cacheability metadata and as a Drupal render array.
     • … based on configuration, we can achieve symmetric translation or asymmetric translation.
• With validation:
  • the component instance UUIDs in tree and props must match
  • 0c4ffd00: each component's assigned prop values must not trigger an InvalidComponentException
  • … much more!
• With the most minimal UI possible:
  • widget: two <textarea>s — validation: see above

    • : !15 (d964218b) Edit individual sourcetype: static:field_item:<field type> prop values using their corresponding widgets using modal dialogs — this would increase confidence that we'll be able to pull this off via the React UI eventually:

      

    • The above MUST run explicit validation against the SDC props, because e.g. the link field type accepts relative URLs, fragment URLs, etc, whereas the SDC prop does not.

    • Edit individual sourcetype: dynamic expressions using a <select> → !20 (merged)

  • formatter: reuse the same rendering that was in hook_entity_view_build_alter() and uses _eb_resolve_sdc_prop_value() — refactored to value object in 04ce0599 (belongs elsewhere but trying to avoid conflict with @f.mazeikis' work on adapters — @f.mazeikis indicated this was no problem)
    • Out-of-scope here: taking over the entire rendered entity: for the purpose of this MR being able to render the component tree inside a field is sufficient.
• Moved to !17 (merged) Drop Drupal 10.2 support~~; require Drupal 10.3, due to plugin annotations being deprecated since 10.3: ~~~~https://www.drupal.org/node/3229001~~
• Tests (minimal)
  • Unit
  • Kernel

assigned to @wimleers

added 1 commit

• 27af9de0 - Make it easy to try this in the Standard install profile: `drush si standard`...

Compare with previous version

changed the description

changed the description

added 2 commits

• 38568415 - Enrich `ComponentPropsValues` and `ComponentTreeStructure` with functionality...
• 0c4ffd00 - Reuse the SDC `ComponentValidator` to ensure resolved props values truly make sense.

Compare with previous version

changed the description

added 1 commit

• 66495e5a - `phpcs` + `phpstan`

Compare with previous version

added 2 commits

• 15205172 - Ignore `phpstan` errors upstream is forcing upon us.
• 90107c49 - Add method I forgot to commnit

Compare with previous version

added 1 commit

• eea38ec7 - Require Drupal 10.3, due to https://www.drupal.org/node/3229001.

Compare with previous version

changed the description

fwiw you can add return types now, php supports narrowing of return types on children

True. But that alone is not enough. You'll get with no value type specified in iterable type array. for all of the ones that either @return array or have a @param array. Once core defines those, these ignored errors can go away. And … note that I do not have reportUnmatchedIgnoredErrors: false, so PHPStan will fail once this is fixed upstream

added 1 commit

• 932ce4b9 - Introduce a third field type property: `hydrated`, which combines `tree` +...

Compare with previous version

changed the description

added 1 commit

• 0e6146bb - `cspell` + `phpcs` + `phpstan`

Compare with previous version

added 1 commit

• 0ae66bc9 - `cspell` + really only test 10.3 + 11.0.

Compare with previous version

added 1 commit

• e9f35bb0 - YAML syntax.

Compare with previous version

added 1 commit

• 04ce0599 - Converted `_eb_resolve_sdc_prop_value()` to a value object.

Compare with previous version

added 1 commit

• 2860f80d - Thanks to the `StaticPropSource` value object introduced in the previous...

Compare with previous version