Add (validation) error handling to AddCodeComponentDialog and friends

Made some edits to better reflect that errors are already handled, but the error details are not exposed.

Besides the 422 error, what other errors can we expect?

Currently sending a machineName that's already taken results in a 500 error, which Wim already explained in a Slack conversation that:

500 you should NEVER see on a live site: it essentially always means “Server-side bug”.

With that said, I don't think we should be concerned about that before we tackle 📌 JavaScriptComponent config entities should have mutable machineNames Active , which would mean the client doesn't need to send what is used as the id entity key for the config entity.

Currently sending a machineName that's already taken results in a 500 error, which Wim already explained in a Slack conversation that:

We'll need to change that to return a 409 (conflict).

Besides the 422 error, what other errors can we expect?

No other HTTP status codes; you should only see 409 and 422.

Note: I agree the value is currently limited. But as soon as ✨ Defining props for code components Active lands, there'll be even more possibilities for validation errors: props must be named in a particular way, for example (just like machineName in the example above). And the name of a prop must not be used by a slot, and vice versa.

So: the more complete 🌱 [Meta] Plan for code components Active becomes, the more valuable this becomes.

For more context:

• the test cases in \Drupal\Tests\experience_builder\Kernel\Config\JavaScriptComponentValidationTest::providerTestEntityShapes() that start with the string 'Invalid: for a sense of what validation errors could occur.
• ⚠️Note that this relies almost completely on SDC's metadata validation, which itself is incomplete/inaccurate — for example ✨ SDC DX does not inform about invalid JSON schemas Active .
• the end-to-end HTTP API test coverage for these config entities — which is nowhere near as complete as I'd like — at \Drupal\Tests\experience_builder\Functional\XbConfigEntityHttpApiTest::testJavaScriptComponent(). I know for sure that the renaming/remapping in \Drupal\experience_builder\Entity\JavaScriptComponent::normalizeForClientSide() is not being respected when generating validation errors, so a validation error for a key the client sent may return a validation error for a different key: in the server-side representation. \Drupal\experience_builder\Controller\ApiConfigControllers should be using ConstraintPropertyPathTranslatorTrait but doesn't yet.

… but none of that is actually a blocker for this issue — this issue can pretend none of those problems exist, and in a future server-side issues we can fix all that — when somebody runs into it :)

Did you see

1. Bonus: use the pattern attribute for providing client-side validation, to make the user immediately aware? 🤓

?

That'd literally prevent the 422 in the screenshot from ever occurring!

Created issue for #3.1: 🐛 ApiConfigControllers::post() should detect a conflicting ID and throw a 409 exception Active .

wim leers → credited kristen pol → .

It's possible to run into the same problem for the "section" creation dialog: 🐛 ConstraintViolationException: Validation errors exist when creating section Active .