Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()`

I would say this isn't so Novice, the tests are quite complicated. I had to:

1. Swap to standard profile
2. Modify cache tags in existing tests to match
3. Enable some new modules
4. Port over helper functions

Locally these tests are throwing a bunch of warnings but I'm testing out the ddev XB setup so it might be related to that.

Not too sure what's causing those unrelated test failures!

Not too sure what's causing those unrelated test failures!

Hm … me neither, but this seems like yet another case of https://www.drupal.org/project/gitlab_templates → being wrong and running contrib module's test suites differently for non-maintainer-pushed commits than for maintainer-pushed commits 😬 (I wish I was kidding!)

Also: you're right, I misjudged, this is not a trivial move. 🙈 Thanks for removing the tag.

But … this issue is novice-like in the sense that you were able to do this without deep XB knowledge! 😄 What do you think would be a more appropriate tag? 😊

Repurposing per #3530907-7: Improve performance of /xb/api/v0/config/component by 80% → .

Suggested API route:

experience_builder.api.info.candidate_dynamic_prop_sources:
  path: '/xb/api/v0/info/candidate_dynamic_prop_sources/{entity_data_definition}'
  methods: [GET]
  …

So: /xb/api/v0/info/candidate_dynamic_prop_sources/entity:node:article etc.

Removal happened to unblock 🐛 Components don't load Active , this is now purely about adding an API

New title

Perfect, thanks!

This will be a blocker for the Content Templates UI: 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active .

Rebase done and tests moved fixed, but a $this->drupalLogout() from a previous tests is failing because Mink can't find "op" button.

https://git.drupalcode.org/project/experience_builder/-/jobs/5801240#L976

After inspecting the HTML right there, the user is logged in and there is a link for logout.

        <ul>
          <li>
            <a href="/user" data-drupal-link-system-path="user">My account</a>
          </li>
          <li>
            <a href="/user/logout?token=INyOF8qdzpnT1xzUapL9vdyU4YKpjP1WM6X-JZOG-VM"
               data-drupal-link-system-path="user/logout">Log out</a>
          </li>
        </ul>

I also added a $this->drupalLogin($this->httpApiUser) and it also fails.

isholgueras → changed the visibility of the branch 3510896-move-propsourceendpointtest-into to hidden.

isholgueras → changed the visibility of the branch 3510896-move-propsourceendpointtest-into to hidden.

isholgueras → changed the visibility of the branch 0.x to hidden.

After talking to @wim, I've realized that #10 📌 Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active is adding a new task, so it's not ready.

The current MR1379 is only moving the test

MR 1379 doesn't address the full issue scope, but I understand how that came to be.

That doesn't mean MR 1379 is wrong — we still need it, but it's only the original side of the coin, since #10 the coin gained another sight (metaphor falling apart — it's been a long day 😅.

Having worked on many of the pieces powering FieldForComponentSuggester and the historical creation ( 📌 HTTP API: update /xb-component/{component_id} to list possible prop sources for current entity context Fixed ) of the test we're refactoring away here, it seemed only reasonable that it was up to me to perform the git+d.o archeology work to bring clarity to the rationale behind what is being tested, and clean it up.

It can be improved further, but it is now sufficiently clear and commented for others to be able to iterate on it further. Merged @isholgueras' MR with my refinements. 👍

Next up: what this issue was rescoped to in #10. I'll get an outline of an MR going.

wim leers → changed the visibility of the branch 1.x to hidden.

Pushed up a rough outline: https://git.drupalcode.org/issue/experience_builder-3510896/-/commit/bca....

We'll need to tackle 📌 Rename `FieldForComponentSuggester` to `StructuredDataSourceSuggester` Active and 📌 [PP-1] Refactor GeneratedFieldExplicitInputUxComponentSourceBase and FieldForComponentSuggester to need only SDC's ComponentMetadata, not SDC plugin instances Postponed too, but there's no need to get blocked on that — it's better to get something rough going to unblock ✨ Content templates, the boss battle: create a UI for editing templates Active :)

🏓 Initial review posted :)

This needs input from ✨ Content templates, the boss battle: create a UI for editing templates Active and especially 📌 Spike: UI for content templates Active , to determine what the ideal API response shape would be for the client side.

Content Templates is still a priority for stable, but we're tracking it separately.

Almost there: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... — please confirm, @hooroomoo.

Changing parent to content template UI

wim leers → credited hooroomoo → .

Perfect, I have everything I need now to finish this up :)

I won’t have time to finish this MR today — there’s still a bunch of loose ends to clean up, but it works.

@hooroomoo, please test, and confirm that this is what you want/need! 🙏 😇

You'll get something like:

Thanks to @hooroomoo's test of this together with their PoC, I can now land this with confidence 🥳

Out of scope:

1. making these API responses cacheable — if the need ever arises, we'll do that then
2. code component support is out of scope — we have had 📌 [PP-1] Refactor GeneratedFieldExplicitInputUxComponentSourceBase and FieldForComponentSuggester to need only SDC's ComponentMetadata, not SDC plugin instances Postponed for >6 months now to do exactly that
3. fixing a shape matching bug that the test coverage I added unearthed: 🐛 Shape matching of an optional SDC image prop fails to find optional field instances Active .
4. while updating the OpenAPI spec, I noticed that for all 4xx responses, the generated docs say
   

   {
     "errors": [
       {}
     ]
   }
   

   is an example value. Which makes no sense, because it should be something like

   {
     "errors": [
       "The 'bla bla' permission is required."
     ]
   }

   But … this is using the ClientErrorResponse already in HEAD, which clearly is wrong for many (not all, but many) routes 😅 It's somewhat right for validation errors for data sent in various API request bodies, but it's wrong for (most?) other cases.

   Created 🐛 OpenAPI spec's `ClientErrorResponse` etc are incorrect for most API routes Active for this.

The very last obstacle is supremely silly:

FILE: tests/src/Functional/ApiUiContentTemplateControllersTest.php
------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
------------------------------------------------------------------------------------------
 20 | ERROR | [x] Doc comment star missing (Drupal.Commenting.DocCommentStar.StarMissing)

… but that all is there and it DOES comply! 🙃

Just removing the comment, don't want this to be held up by that — created supported request upstream: 💬 False `Drupal.Commenting.DocCommentStar.StarMissing` report? Active .