HTTP API: update /xb-component/{component_id} to list possible prop sources for current entity context

The FE of this is handled in 📌 Make store API paths/uris configurable via environment variables (and eventually drupalSettings) Needs work it shows (in comments) the extension points. I knew we'd need this at some point so took the time to document it there.

I need to update this issue — many things have changed since this was created.

All originally identified blockers are in. But 📌 Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings Fixed changes things.

Issue summary fully updated 👍

📌 Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings Fixed is in.

Thank you, @bnjmnm, for getting this going! 🤩🙏

This looks stellar. Zero remarks on the code. Looks like the details I write >2 months ago were sufficient? 🤓

The exact shape of the response is irrelevant at this time — because the very purpose of this issue is to just leap ahead of the UI and at least allow some experimentation to happen on the front end when the necessary designs for this eventually arrive.

But I am surprised the new test does not fail because 📌 Create an Open API spec for the current mock HTTP responses Fixed introduced an OpenAPI spec that covers this route too. In that OpenAPI spec, /xb-components has this schema:

                type: object
                minProperties: 1
                # @see \Drupal\Core\Plugin\Component::$machineName
                patternProperties:
                  '^\\[a-zA-Z0-9_-]:[a-zA-Z0-9_-]$':
                    $ref: '#/components/schemas/Component'

and that $ref does list additionalProperties: false, which this test should be triggering? 🤔

Now, I know that I literally just wrote:

The exact shape of the response is irrelevant at this time […]

… but I'd expect we'd need to update openapi.yml somewhat like this as a very MVP way to capture this in the OpenAPI spec:

diff --git a/openapi.yml b/openapi.yml
index a29efe50..4160b691 100644
--- a/openapi.yml
+++ b/openapi.yml
@@ -180,6 +180,10 @@ components:
                 type: [string, integer, number, boolean, object]
         default_markup:
           type: string
+        # @todo Refine when designs for choosing a PropSource arrive.
+        # @see https://www.drupal.org/project/experience_builder/issues/3455975
+        prop_source_choices:
+          type: object
       additionalProperties: false
     Layout:
       title: layout

Still missing here: an update to openapi.yml. The fact that this is currently passing tests is indicative of the openapi.yml file not being validated correctly by ApiResponseValidator, because additionalProperties: false in $ref: '#/components/schemas/Component' should result in a validation error 😬

Ugh, looks like thephpleague/openapi-psr7-validator does not really support patternProperties, because the only mention of it is in a comment, and the same goes for devizzent/cebe-php-openapi which it relies upon?! 😱🤯

• https://github.com/search?q=repo%3Athephpleague%2Fopenapi-psr7-validator...
• https://github.com/search?q=repo%3ADEVizzent%2Fcebe-php-openapi%20patter...

😭

Time to call it a day.

@Wim Leers see my MR comments. let me know what you think the `x-xb-validation` using the OpenAPI extension naming to check this. If you are good with approach assign it back to me and I will finish it up

+1 for this direction. Details on the MR. Glad you've found a way forward! 👏

@Wim Leers see my MR comments

Actually I still need to look at test failures

Unassigning myself. I am not sure the Cypress test is failing. I have the tests running locally but I can't figure it out. Thought maybe it was `ApiResponseValidator` but I commented that out and the test is still failing

✨ Implement simplified zoom interface Fixed significantly rewrites those end-to-end tests and introduces hardening for the tests to avoid trying to access elements in the iframe before their events are initialized. It's close to being merged, so I recommend that we wait until it lands, and see how the failing tests behave with those changes.

Thanks, @balintbrews!

@balintbrews thanks!

Turns out it's not ✨ Implement simplified zoom interface Fixed that will fix that, but 🐛 Unnecessary wait() use in e2e tests causing failures Active .

There's a remaining test failing because it is failing to find an iframe where data-test-xb-content-initialized is TRUE and I discovered why by adding console.log() calls next to where data-test-xb-content-initialized is switched to false and true.

The two final logs - both which change the attribute to FALSE (without the expected switch to TRUE) - only happen in this MR.

I can see how this might happen since the switch to FALSE will occur any time the useEffect is triggered by a change to dispatch, height, handleDragAdd, handleDragEnd, handleDragStart, layout, model, components, but the switch to TRUE only happens when the onload callback is invoked. It seems like there are plenty of opportunities for one of the 8 useEffect dependencies to change and change data-test-xb-content-initialized to FALSE without onload firing to change it to TRUE.

If those extra renders of the iframe are unnecessary, perhaps they should be addressed in this issue. If it is expected and acceptable, then we need a different way to mark something as initialized.

WITH THIS MR OPEN YOU CAN CONFIRM THIS BY... going to the XB UI and look at the iframe html - you'll see the data-test-xb-content-initialized within moments of the UI loading.

Further debugging shows that this MR is not creating any new changes that trigger the iFrame attribute update changes. Instead, it is changing the order that they change, and components is changing after layout and model.

A change to component triggers the useEffect that sets data-test-xb-content-initialized to false, but unlike layout/model it does not result in the iframe loading anything new, so the onload that would set data-test-xb-content-initialized to TRUE is not invoked.

Based on the extensive debugging it looks like this can be addressed by changing a few lines so components (a list of the available components) is no longer a dependency of the iframe-impacting useEffect or the updateData useCallback. Neither of these should need to update if the components list changes.

While it's true that updateData requires components to have initialized for it to properly add a component to the layout, this doesn't need to be enforced as a callback dependency because the UI doesn't offer that option until it is ready anyways.

I think this solution is sound but it would be good to get another FE person to look it over to ensure this isn't going to break something elsewhere.

Truly great investigation, and I agree with the solution! I love how this ended up being an actual problem — unnecessary rerenders — our test uncovered.

👏 @bnjmnm! Agreed with @balintbrews 😊

Somehow the removal of patternProperties got remove from this MR will open up a follow-up

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