Maintain a per-component set of prop expressions/sources

💯

Working on this as it now blocks 📌 [PP-1] Send page data to Drupal for storage in auto-save store Postponed: needs info

Pre-emptive high-level review, prior to a green test run. 🏓

I am worried how this is changing the tightening that 📌 Tighten validation: only allow StaticPropSource in XB fields + PageTemplate, DynamicPropSource in ContentTypeTemplate Active brought. AFAICT that's only necessary because 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active is not yet done, and we want the UI to leap forward in this way?

Also linked issues that are referenced by @todos in the MR.

This is postponed on 📌 Remove dynamic prop sources from test data Active

📌 Remove dynamic prop sources from test data Active is in. 🥳

The issue with component-operations.cy.js is

      'static-static-card1ab' => [
        'heading' => [
          'sourceType' => 'static:field_item:string',
          'value' => 'hello, world!',
          'expression' => 'ℹ︎string␟value',
        ],
        'cta1href' => [
          'sourceType' => 'static:field_item:uri',
          'value' => 'https://drupal.org',
          'expression' => 'ℹ︎uri␟value',
        ],
      ],

Because we only have these two props set in the stored model, only these two fields actually render in the SDC component form. Not sure where to fix this, putting this down here for today.

This is green now 🎉

(FYI: I've not lost track of this; @larowlan has just indicated that 📌 Implement saving block settings forms Active is more important to land first.)

I'm very sorry, but 📌 Remove references to 'props' outside of SDC - use 'inputs' instead Active seemed both more important and like it could help make this more clear, because it'd ensure this MR would then make this change from a clearer starting point.

So I'm afraid this needs a reroll. But I'm very eager to get this in early next week :)

P.S.: please first check #3500994-15: Remove references to 'props' outside of SDC - use 'inputs' instead → + #3500994-18: Remove references to 'props' outside of SDC - use 'inputs' instead → — I think this issue is the perfect one to identify what could/should be clearer in docs/shape-matching-into-field-types.md.

Per #3501902-20: Adding the Image component results in a state considered invalid → , let's get this going again! And … I see @larowlan already did 😄 🤩

📌 Move clientside assumptions about prop form data shape into a series of prop specific transforms Active landed, let's get this in next!

@longwave already started pushing this forward today 👍

HardcodedPropsComponentTreeItem was already removed in 📌 Implement saving block settings forms Active 😄

In #12 (on Jan 17, >2 weeks ago), @larowlan assigned this to me for review. Then we landed a bunch of other issues first.

Time to review this, even though it's not currently passing tests. I don't want @larowlan's work here to go to waste.

Made minor tweaks only, and now this MR is passing all PHP tests, and most of the e2e tests. See attached patch for the full set of changes I made — it's only 7 files changed, 26 insertions(+), 9 deletions(-).

Review

Most important first:

1. There are a few @todos relating to the handling of default values — AFAICT that's what 📌 Split model values into resolved and raw Active is for. Please confirm 🙏
2. I'm concerned about how this makes the hydrated computed field property much more complicated; that was always intended for hydration prior to rendering, not for editing. But 📌 Connect client & server, with zero changes to client (UI): rough working endpoints that mimic the UI's mocks Needs review indeed made the sensible-at-the-time decision to use hydrated to generate the client-side layout + model (for the /api/layout/{entity_type}/{entity} route).
3. Some naming concerns, because this is the golden opportunity to make the connection between client-side terminology/infra and server-side terminology/infra more coherent. Especially now that ✨ Create a ComponentSource plugin for JS components Active introduced GeneratedFieldExplicitInputUxComponentSourceBase as a common foundation for "SDC" and "JS" components. Looks like @larowlan already raised similar concerns in his self-review 😄 My observations: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...
4. … plus relatively minor things on the MR.

This MR is going through the effort of making sure the client side has both a source and resolved representation. It even updated openapi.yml to convey that it expects /api/layout/{entity_type}/{entity} to return that in its response. But … only openapi.yml examples were updated, not its schema.

Otherwise it would've flagged that the actual responses do not match the prescribed schema! However … for Block-sourced components, the source and resolved key-value pairs should not exist! Fortunately, OpenAPI 3 supports polymorphism for this: https://swagger.io/docs/specification/v3_0/data-models/inheritance-and-p...

Per \SchemaTest::testDiscriminator(), the OpenAPI validation library XB is using does support that 👍

Digging into this made me stumble upon 📌 Allow source components to control how hydrated values are mapped into the clientside model Active , which is very closely related to that. In fact, landing that trivial change should enable this MR to avoid all concerns I raised over at https://git.drupalcode.org/project/experience_builder/-/merge_requests/5... 😇

Finally: the e2e tests are still failing due to

{
                      "status": 500,
                      "data": {
                        "message": "Missing the keys value."
                      }

… which is due to https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...

The client side still needs to merge in that value when assembling the request body to send to ComponentInputsForm.

📌 Allow source components to control how hydrated values are mapped into the clientside model Active is in, this MR can now take advantage of that, and remove the complex additions to ComponentTreeHydrated.

See https://git.drupalcode.org/project/experience_builder/-/merge_requests/5... for how I implemented #23.

So we have an answer to 📌 Will passing the model props for a component via GET parameters hit limitations due to URL length Active then - in our failing cypress tests on this issue.

{
                      "status": "PARSING_ERROR",
                      "originalStatus": 414,
                      "data": "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>414 Request-URI Too Long</title>\n</head><body>\n<h1>Request-URI Too Long</h1>\n<p>The requested URL's length exceeds the capacity\nlimit for this server.<br />\n</p>\n</body></html>\n",
                      "error": "SyntaxError: Unexpected token '<', \"<!DOCTYPE \"... is not valid JSON"
                    }

So I think this is blocked on 📌 Will passing the model props for a component via GET parameters hit limitations due to URL length Active and we need to make form fetching use a POST request.

x-post

I have an MR up on 📌 Will passing the model props for a component via GET parameters hit limitations due to URL length Active 🤞

📌 Will passing the model props for a component via GET parameters hit limitations due to URL length Active is in. Merged in upstream.

I've been over the MR twice and done some manual poking around with it - no additional comments, I think this is ready to land; onwards to the next issue!

Given that @bnjmnm has been expressing his +1 to the direction taken by @larowlan in 📌 Move clientside assumptions about prop form data shape into a series of prop specific transforms Active and 📌 Support server side massage and validation of component prop form values Active , I think it's reasonable for me to merge this without Ben's explicit +1.

Especially considering @larowlan is going to go on PTO after tomorrow, so I'd rather have him finish as much as possible of 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active before then.

This paves the path for:

1. 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active in the future (which will need DynamicPropSources).
2. #3500152 — see #3500152-6: Remove InputBehaviorsBlockSettingsForm and consolidate with input components form →
3. … more ComponentSource plugins
4. closing the overarching 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active .

Unpostponed subsequent issues/MRs planned by @larowlan:

• 📌 Maintain a per-component set of prop expressions/sources Active
• 📌 [PP-1] Rename PropSourceComponent.field_data to propSources Postponed

Automatically closed - issue fixed for 2 weeks with no activity.