[PP-1] Refactor GeneratedFieldExplicitInputUxComponentSourceBase and FieldForComponentSuggester to need only SDC's ComponentMetadata, not SDC plugin instances

Created on 29 January 2025, 7 months ago

Overview

✨ Create a ComponentSource plugin for JS components Active introduced GeneratedFieldExplicitInputUxComponentSourceBase. In order to make most of the logic in that class (which powers the input UX for the "SDC" and "JS aka code component" ComponentSource plugins) work, it needs an SDC plugin instance.

Changing it to not need that would've led to even more refactoring in #3498889 than it already did.

Proposed resolution

  • Refactor all the XB-owned infrastructure to not expect an SDC plugin instance as an argument, but only a subset of that plugin instance: a ComponentMetadata object.
  • Start with GeneratedFieldExplicitInputUxComponentSourceBase
  • Note: this may require in some places an ephemeral SDC plugin object (not tied to an actually installed SDC on disk) to be generated from that metadata object, for example to be able to call SDC's \Drupal\Core\Theme\Component\ComponentValidator::validateProps().
  • Then move on to \Drupal\experience_builder\ShapeMatcher\FieldForComponentSuggester.
  • Expected end result: SingleDirectoryComponent or JsComponent-specific checks/logic remain.

This will allow docs/components.md to be updated to state something like:

Any `Component Source Plugin` without a native (explicit) input UX can reuse the infrastructure that XB originally
built to provide an input UX for `SDC`-sourced `Component`s. To generate an input UX,  the precise shape of each
input (and it being required or optional) must be expressed in a standardized way. To avoid inventing new infrastructure,
XB opted to rely on the SDC subsystem of Drupal core's abstraction for expressing this: the `ComponentMetadata` class.

While imperfect (because it contains _all_ metadata rather than only that relating to its explicit input shapes), it is
the pragmatic choice to get the job done. See [`XB Shape Matching
into Field Types` doc](shape-matching-into-field-types.md) for details on how that works.

In other words: _any_ `Component Source Plugin` can use the same Drupal Field-powered UX that XB provides for SDCs,
all it requires is generating a `ComponentMetadata` object that expresses its input schema.

@see \Drupal\Core\Theme\Component\ComponentMetadata

User interface changes

None.

πŸ“Œ Task
Status

Postponed

Version

0.0

Component

Shape matching

Created by

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

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

Merge Requests

Comments & Activities

  • Issue created by @wim leers
  • πŸ‡¬πŸ‡§United Kingdom longwave UK
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10
  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Made a start on this.

  • Status changed to Needs work 4 months ago
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    I don't think this needs to be a stable blocker; XB at release won't yet allow additional ComponentSourceInterface implementations. Which means this would be an entirely internal refactor?

  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    The fact we had to pretend this exists in the fallback plugin makes me feel it is a stable blocker.
    I know @mohit_aghera has a pinto component source plugin that is also grappling with this.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Adding back tag until the conversation above is resolved (we can always remove it again, just want to make sure it's not lost)

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

    I think this is less urgent.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Tagging for colleagues as this is a bug bear for the Pinto work Mohit has been doing

  • First commit to issue fork.
  • Pipeline finished with Failed
    3 months ago
    Total: 790s
    #500902
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    Thanks, @mohit_aghera, for pushing this forward! πŸ₯³πŸ™

  • Status changed to Active 12 days ago
  • πŸ‡ΊπŸ‡ΈUnited States effulgentsia

    I read #10, but I don't think this is a stable blocker. We'd be happy to merge this once it's ready though, so by untagging it I have no desire to slow this issue down.

    For XB, the definition of stable is different than core's. We'll be adding @internal to almost everything and relaxing that in 1.x minor releases. The main goal of an XB stable release is to unblock a Drupal CMS 2.0 stable release, allowing people/agencies to build and deploy real sites with that. But XB 1.0.0 won't yet have a proper PHP API surface for contrib projects to perform more advanced integrations than what DCMS 2 exercises, except to the extent that issues like this one just happen to get done ahead of a 1.0.0 release.

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

    This is going to block 🌱 [META] Content templates Active , and πŸ“Œ Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active made it very apparent πŸ˜…

    Quoting \Drupal\Tests\experience_builder\Functional\ApiUiContentTemplateControllersTest::testSuggestionsClientErrors():

       *           ["node/article/js.xb_test_code_components_with_link_prop", 400, "Code components are not supported yet."]
       *           ["node/article/js.xb_test_code_components_with_no_props", 400, "Code components are not supported yet."]
    

    So, starting point:

    diff --git a/src/Controller/ApiUiContentTemplateControllers.php b/src/Controller/ApiUiContentTemplateControllers.php
    index 85bcf22f9..3f3909582 100644
    --- a/src/Controller/ApiUiContentTemplateControllers.php
    +++ b/src/Controller/ApiUiContentTemplateControllers.php
    @@ -112,11 +112,6 @@ final class ApiUiContentTemplateControllers extends ApiControllerBase {
           throw new BadRequestHttpException('Only components that define their inputs using JSON Schema and use fields to populate their inputs are currently supported.');
         }
     
    -    // @todo Add support for suggestions for code components in https://www.drupal.org/i/3503038
    -    if (!$source instanceof SingleDirectoryComponent) {
    -      throw new BadRequestHttpException('Code components are not supported yet.');
    -    }
    -
         if ($this->entityTypeManager->getDefinition($content_entity_type_id, FALSE) === NULL) {
           throw new NotFoundHttpException(sprintf("The `%s` content entity type does not exist.", $content_entity_type_id));
         }
    
Production build 0.71.5 2024