Refine API response with DynamicPropSource suggestions to provide better UX

Step 1 is done: https://git.drupalcode.org/project/canvas/-/merge_requests/107/diffs?com... passed tests.

FYI the "subset" stuff was introduced in #3512433: Provide visibility into which (core) field types (74%), field type props (63%) can be mapped into Content Type Templates vs not, and which field widgets (36%) are supported (again, for developer-facing purposes).

Step 4 is done: https://git.drupalcode.org/project/canvas/-/merge_requests/107/diffs?com...

LOL, apparently I wrote

              // Generate a label for the suggestion:
…
              // - one that describes the subset of the entity field otherwise,
              //   with explicit (developer-friendly, user-overwhelming) info on
              //   which field props are present vs absent.

back in #3512433: Provide visibility into which (core) field types (74%), field type props (63%) can be mapped into Content Type Templates vs not, and which field widgets (36%) are supported 🤣

Step 3 is done: https://git.drupalcode.org/project/canvas/-/merge_requests/107/diffs?com...

Step 2 is done partially: https://git.drupalcode.org/project/canvas/-/merge_requests/107/diffs?com...

→ now shows as Silly image (only width, for example.

The current MR represents all changes that can happen without drastically changing #3541037: Allow linking `ContentTemplate` SDC/code component instance props to fields (aka finally use `DynamicPropSource`s!), too.

What remains: generating a nested structure. However, what we failed to discuss/realize yesterday, but do need to solve somehow, is the distinction between nesting for:

• a field pointing to a field on another entity → requires a nested contextual menu
• a field of which only a subset is consumed (and this could also be a reference field!)

Because it's possible that both occur!

Quotes from the test coverage, for datetime string matching:

            "field_event_duration (only end_value)" => 'ℹ︎␜entity:node:foo␝field_event_duration␞␟end_value',
            "field_event_duration" => 'ℹ︎␜entity:node:foo␝field_event_duration␞␟value',

and for UUID matching:

            "Authored by → User → uuid" => 'ℹ︎␜entity:node:foo␝uid␞␟entity␜␜entity:user␝uuid␞␟value',
            "Authored by (only target_uuid)" => 'ℹ︎␜entity:node:foo␝uid␞␟target_uuid',

and for integer matching

            "Authored by → User → access" => 'ℹ︎␜entity:node:foo␝uid␞␟entity␜␜entity:user␝access␞␟value',
            "Authored by → User → changed" => 'ℹ︎␜entity:node:foo␝uid␞␟entity␜␜entity:user␝changed␞␟value',
            "Authored by → User → created" => 'ℹ︎␜entity:node:foo␝uid␞␟entity␜␜entity:user␝created␞␟value',
            "Authored by → User → login" => 'ℹ︎␜entity:node:foo␝uid␞␟entity␜␜entity:user␝login␞␟value',
            "Authored on" => 'ℹ︎␜entity:node:foo␝created␞␟value',
            "Changed" => 'ℹ︎␜entity:node:foo␝changed␞␟value',
            "Silly image 🤡 → File → changed" => 'ℹ︎␜entity:node:foo␝field_silly_image␞␟entity␜␜entity:file␝changed␞␟value',
            "Silly image 🤡 → File → created" => 'ℹ︎␜entity:node:foo␝field_silly_image␞␟entity␜␜entity:file␝created␞␟value',
            "Silly image 🤡 → File → filesize" => 'ℹ︎␜entity:node:foo␝field_silly_image␞␟entity␜␜entity:file␝filesize␞␟value',
            "Silly image 🤡 (only height)" => 'ℹ︎␜entity:node:foo␝field_silly_image␞␟height',
            "Silly image 🤡 (only width)" => 'ℹ︎␜entity:node:foo␝field_silly_image␞␟width',

👆 we need to decide how we want to present those; presenting the same is probably not going to make a lot of sense if executed in the simplest way, because in that last example, we'd present the following tree:

Authored by 
    → User
        access
        changed
        created
        login
Authored on
Changed
Silly image 🤡
    → File
        changed
        created
        filesize
    only height
    only width

Either way, what's in this MR causes zero disruption to #3541037: Allow linking `ContentTemplate` SDC/code component instance props to fields (aka finally use `DynamicPropSource`s!), so landing this MR first 👍

For the explanation + question in #11.

From a technical POV, it can. That's literally what I illustrated in the code blocks.

From a usability POV, I think it's really bad. Because in some cases, the nesting means following an entity reference, in other cases it means picking a single field property of the field in the top level.

Point 4 in the issue summary (matching form display order) doesn't work correctly. Root cause: EntityFormDisplay::getComponents() confusingly doesn't return them in the right order 🙃

Wow, now GitLab is broken — the branch points to the open MR at https://git.drupalcode.org/issue/canvas-3547598/-/merge_requests/129, but that is a 404 🙃

#3548322: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` and remove `ContentTemplates` from feature flag is the FE follow-up to implement #11 at the UI level. @lauriii responded in #14, but incompletely. See #15 for the outstanding question.

If somebody wants to pick this up before me (please do!): this requires refactoring \Drupal\canvas\ShapeMatcher\FieldForComponentSuggester::structureSuggestionsForResponse() to output the structure @hooroomoo outlined in #26.

Made good progress on this today. Sprinkled 🚧 comments to pick this up tomorrow. Will finish then.

Tests passed! Next up: making it work for multi-bundle reference expressions; those test cases had been commented out to get the bulk of this MR going, because they require extra complexity (introduced by #3530521: Decouple image shape matching from the `image` MediaType: support matching multiple bundles of a single MediaSources (`image`)).

Fully green! 🥳

Time now to generate the JSON structure outlined by @hooroomoo in #26.

Time to visualize the progress. See the updated issue summary.

Now it's time to aim for meeting all of the requirements set forth by @lauriii at #3548322-13: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` and remove `ContentTemplates` from feature flag:

1. We should sort the fields based on default form display order (when there is a form display to reference)
2. Fields not on the form display should be displayed below the ones that are on form display in alphabetical order
3. In the scenario of file entity in images, we should simplify the structure and bring the file entity properties to the second level

.

4. We should capitalize properties
5. We should not display 'only' as a prefix

• #1 already landed in this issue as part of !107+!129.
• #4 + #5 are done as you can seen in the screenshots, in the in-progress !191.
• #2 I'm not sure what it is referring to. 😅

Working on #3 now.

Fix HTML.

#3 is implemented 👍

That leaves now only the hierarchical response structure outlined by @hooroomoo in #26.

As the screenshots in the "UI changes" section illustrate, this is already a big leap forward.

The UI will take advantage of this in the follow-up this unblocks, see #3548322-16: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` and remove `ContentTemplates` from feature flag and the subsequent comment for guidance.

primary-panel.cy.js's previews components on hover test case seems to be failing consistently on CI for this MR (passing consistently on 1.x HEAD), but locally it passes just fine:

Re-tested a 3rd time: https://git.drupalcode.org/project/canvas/-/jobs/6811379 🤞

Worst of all: that is testing component previews in the list of components available to instantiate, which this MR is not even getting close to touching any code path for 😭

@jessebaker touched that file yesterday, so I'm hoping he has a hunch…

OMG — now it passed: https://git.drupalcode.org/project/canvas/-/jobs/6811379 (but now navigation.cy.js failed 🤷‍♂️ — random fails are such a PITA!).

See y'all in #3548322: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` and remove `ContentTemplates` from feature flag! 🎉