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