[Needs design] Display validation errors in page data form

Note that the back-end is already providing validation errors. There is explicit test coverage for that at \Drupal\Tests\experience_builder\Functional\ApiContentUpdateForDemoControllerTest::testSave():

// Make a request with invalid heading properties.
    $invalid_heading_client_json = $valid_client_json;
    $invalid_heading_client_json['model'][self::TEST_HEADING_UUID]['style'] = 'not-a-style';
    $this->assertClientRequest(
      $node2,
      $invalid_heading_client_json,
      422,
      [
        'errors' => [
          [
            'detail' => 'Does not have a value in the enumeration ["primary","secondary"]',
            'source' => [
              'pointer' => 'model.' . self::TEST_HEADING_UUID . '.style',
            ],
          ],
        ],
      ],
    );
    // Ensure none of the entities have been saved.
    $this->assertNodeValues($node2, [], [], $node2_original_title);
    $this->assertValidJsonUpdateNode($node1);

In other words: it's now up to the client side to update the rendered form and display error information.

(And once that works, it'll also work for the ComponentInputsForm, i.e. the form generated for an SDC component or a "code component".)

However, not everything is possible to do client-side. Which is why we have 📌 Support server side massage and validation of component prop form values Active . So, to achieve the full scope of this issue, we AFAICT need to do #3499550 first.

AFAICT this is not actually actionable at this time. This requires server-side changes to land first before the necessary FE pieces can happen.

Wim asked me to write up my thinking about how we will achieve this.

• At present we send entity_form_fields to Drupal using the HTML input name as the keys
• However when we return 422 errors from Drupal, the validation errors are keyed using entity-api property paths - e.g. `title.0.value`. These don't always align with what the name attribute is on the HTML input element (or select, or textarea).
• When 📌 Move clientside assumptions about prop form data shape into a series of prop specific transforms Active is done we have transforms to map from widget structures to an object structure. So we should be able to do something similar for the page data form - but instead of using it to map input values to prop names, we need to be able to use it to generate a map from HTML name attributes to property paths. e.g an error on some_enum_field.0.value might map to <select name="some_enum">
• Once we have this we can also do away with the flat structure of entity values and start sending them in a fashion closer to how we send JSON with JSON:API. This allows us to do away with the \parse_str we are using in a few places to convert the flat structure back into a nested object.

I _think_ the blocker is in to at least do a spike here

Now that 📌 Move clientside assumptions about prop form data shape into a series of prop specific transforms Active is in I think we should explore using these for entity form fields as well.

I could also see a world where we had server-side transforms (these would be callbacks) so that we could sidestep issues like \Drupal\Core\Entity\Element\EntityAutocomplete::validateEntityAutocomplete and the like - this would hopefully mean we could decouple from the form system and not need to build and submit a form anymore.

AFAICT this would also unblock #3506467-15: Media Library dialogs triggered from page data do not have buttons yet → .

This is what it looks like:

And I'll set to NR once the tests that pass locally can pass on CI 👹

Approved the BE pieces, but @larowlan's review from yesterday identified some remaining bugs.