Get Options as buttons in Page Data form working

The initial POST to https://drupal.test/xb/api/layout/node/{nid} fails due to the radio option being an array instead of the expected string

The option is being sent as a string on the FE

The last XB line of code before the error occurs is in \Drupal\experience_builder\ClientDataToEntityConverter::setEntityFields

    $form = $this->formBuilder->buildForm($form_object, $form_state);

And during that build it eventually culminates in The submitted value type array in the XB Options (Buttons) element is not allowed. and a few other type validation issues. The $entity_form_fields sent to the build process has many similarly structured fields -> values so at first glance there doesn't appear to be anything wrong with the structure itself, so I suspect it's an issue with setting the correct validation expectations... but that is just speculation ATM. Will explore further.

I have gotten past the issue in #4 now

But then we hit a new issue because this gets modified by OptionsWidgetBase::elementValidate which in turn sees the new value (array) get stored in autosave so that when we publish, we end up with the same issue as #4 😭

I think this will likely require some special casing of options_buttons and anything that subclasses OptionsWidgetBase

Before I go down that route I will revisit why we store the updated entity form fields in autosave, it was for Media but perhaps there's a middle ground where we don't have to.

Got around #5 and media library tests are still passing
The key thing we need to save is the form_build_id, nothing else matters

Ok, new tests are passing 🙌

I think this is small enough to get in without disrupting multi-value.

And then we can tackle the remaining widgets in individual issues with smaller scope.

Added the service provider

This is now green, adding parent meta

This fixes the problem twice-reported in the following issues

• 🐛 "There are no users matching '' error message appears after reloading the editor page Active
• 📌 Get Options as buttons in Page Data form working Active

I started the branch so I can't provide any codeowner approvals, despite this largely turning into something authored by @larowlan

Otherwise, I'd be the approver for Redux-integrated field widgets so if @larowlan wants to be my proxy for that I think that is fine.

I am not sure why yet but when manually test the default values for radio buttons don't show up

Steps:

1. Add 3 fields to article, 1 integer list, using radio buttons, 1 string list using radio buttons, 1 text field

   make sure all 3 fields have default values

2. Add an article, all 3 default value should be set in the form
3. open the article in XB
4. The text field default value is correct but no values are selected for the radio buttons
5. Select values for the radio buttons, and change the value of the text field
6. reload the page
7. The value for the text field retains the updated values, the radio buttons are not selected again
8. Select values for the radio buttons(make sure not to use default), a
9. publish the node
10. The radio button fields are not correct, in case they completely different from the default and what I selected

I am going to test 0.x to see if some of these problems exist

Addressed all changes, ready for review again

📌 Add e2e test and confirm support for language widget Active is postponed on this but has an MR that includes this branch (Squashed)

wim leers → credited hooroomoo → .

Wow, so much greatness in this MR! 😄

@larowlan in #5:

I think this will likely require some special casing of options_buttons and anything that subclasses OptionsWidgetBase

Isn't this entirely attributable to

multiple_values: TRUE,

and hence detectable? 🤔

See this bit in section 3.3 The spectrum of `HTML form control element` → `component input` flows of docs/redux-integrated-field-widgets.md:

6. **Multi-value `field widget`s**: some `field widget`s natively support multiple values, without the need
   repeating the form structure multiple times.
   For example: `\Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget` has
   ```
   multiple_values: true
   ```

Regardless of the answer to that question, I think this MR should update docs/redux-integrated-field-widgets.md's section 3.3 to reflect the improved new status! 🤓😄

Actually, not sure if it's @bnjmnm or @larowlan who wants to push this forward :)

I took care of some 0.x conflicts since I knew what it would be conflicting with, and also few bits of feedback while I happened to be in there, but didn't want @larowlan to think I was still actively working through all the items and potentially conflicting with work he's doing.

Picking this up - thanks all 🙌

Blocked on 🐛 ComponentTreeHydrated prevents serialization Active

This MR is not yet updating the docs as described in #18.

Reliance on JSON:API for validation

Apparently this is obvious to everyone here except for me 🫣 …but I don't understand why this MR installs JSON:API to perform validation that ApiAutoSaveController::post() already did?

That's the only reason this is blocked on 🐛 ComponentTreeHydrated prevents serialization Active .

Client-side transforms → component instance, not content entity?

I know this issue is only targeting the "Page Data" (aka content entity) form. But if that's the case, why is it also specifying xb.transforms? Because those are only used for the ComponenInputsForm, right?

If we're specifying client-side transforms, shouldn't we also explicitly test that this works in prop-types.cy.js and expand the all-props test SDC?

Related: 📌 Automatically use radio buttons for "small enums" and dropdown for "big enums" Active . I tried cherry-picking that entire MR (without the test changes) onto this MR, and that still applies cleanly. That still works (as the screenshot in that issue shows), but clicking the radio buttons is impossible. If the client-side transform exists, shouldn't that work? 🤔

Also, AFAICT we can close #3497669 as a duplicate?

Unblocked, as we have landed 🐛 ComponentTreeHydrated prevents serialization Active

e2e tests failed, retrying 🤞

is n o longer needed because this issue is specifically scoped to the "Page Data" (aka content entity) form.

Very nice to see getNameAttributeBasedOnId() get removed and inputBehaviors.tsx become more explicit.

Best of all: this MR proves that that was all that was needed to make the options_buttons field widget work: we just needed to make sure input[type=radio] work: that makes them appear in entity_form_fields, and then everything else is handled by Drupal's existing form submission logic! 🥳

(I hope that statement was fully accurate — I'm trying to keep @bnjmnm and @larowlan unblocked on making progress, and accept that I don't understand every detail!)