Compatibility between SDC and the Form API

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

(if you need form API assistance message chx on Drupal Slack. Response times should be below 24 hours but usually below 4 hours.)

Hello,

@ghost of drupal past, thanks for the proposal.

First POC, trying to tell Element::children to got looking into #slots if the element is a component make the form element inside the component to be prepared by the Form API, but:

1. It remains duplicated on rendering (one textfield outside the component, one inside)
2. The 2 elements have the same name attribute, so when submitting the form it is the element in the component which value is retrieved but I think it i only a side effect of having duplicated name.
3. "parent" mechanism in the form API may be confused/malformed.

So next step will be to try to put slots as component element child and so adapt SDC (and later table element too).

But previous results makes this approach very side effect prone.

Yes, that sounds risky, but it worth to check.

Following, I wrote a number of form components for ui_suite_uswds but really serves no purpose :(

Following, I wrote a number of form components for ui_suite_uswds but really serves no purpose :(

They will be usable once 📌 Define form elements from SDC Active is done.

We are actively working on both issues and we already have very promising results.

I think I did use the checkbox component for uswds in the checkbox.html.twig file but it was messy. SO yay to here that!

Yesterday session is online: https://www.youtube.com/live/6AvlzYN17Rs?t=25741s

Until presentation support is posted somewhere you can go give a look.

From @nod_ feedbacks, I am:
- creating another branch with containing only core changes.
- creating a dedicating plugin instead of altering ComponentElement
- need to find a way to make submitted values work without using #name

In MR https://git.drupalcode.org/project/drupal/-/merge_requests/11866, I removed what is only for 📌 Define form elements from SDC Active so that in this issue, we can focus only on SDC and Form API compatibility.

#name is not usable as it is right now because of Ajax.

Currently poking a field widget which will be able to use components, the settings form is broken.

Ok, we found a way to get rid of the #name. Just need to ensure no numeric key.

Before:

$form['component_card'] = [
    '#type' => 'component',
    '#component' => 'core_sdc_form:card',
    'content' => [
      '#type' => 'component',
      '#component' => 'core_sdc_form:card_body',
      'content' => [
        [
          '#type' => 'textfield',
          '#title' => $this->t('Textfield in content'),
        ],
      ],
    ],
];

After:

$form['component_card'] = [
    '#type' => 'component',
    '#component' => 'core_sdc_form:card',
    'content' => [
      '#type' => 'component',
      '#component' => 'core_sdc_form:card_body',
      'content' => [
        'foo' => [
          '#type' => 'textfield',
          '#title' => $this->t('Textfield in content'),
        ],
      ],
    ],
];

This is looking promising, adding various review tags.

This proposal is close to completion, we keep this "Needs work" until we check existing tests and add new ones.

Most of the remaining work is happening in 📌 Define form elements from SDC Active where I am cgecking the SDC philosophy will be "respected":

• UI only, business agnostic, logic and concepts
• Front-dev friendly
• Sharable and design system oriented

Demo gif in #3508641-12: Define form elements from SDC → .

Pushing current work state before cleanup.

With the fix from 🐛 Incorrect render structure in Navigation PageContext Active , the proposed changes in Renderer and ComponentElement do not break existing tests.

Grimreaper's proposal is to allow slots as children to make them work with Form API:

 #type: component
#component: 'provider:foo'
#props:
  prop_1: ''
  prop_2: ''
slot_1: {}
slot_2: {}

And then, in ComponentElement, we move the slots to the expected position in #slots:

 #type: component
#component: 'provider:foo'
#props:
  prop_1: ''
  prop_2: ''
#slots:
  slot_1: {}
  slot_2: {}

Is it the opportunity to deprecate #slots and to promote render children as the expected way of settings slots in SDC ?

Problem with SDC on component with multiple inputs, solved by using [] on name in the component.

We tried to create a lat/lon component with geofield, not working because of applicative
logic into the field type.

Checkbox in form API directly: OK
Checkboxes in form API directly: OK

Usage of names to handle multiple inputs.

Problem of unchecked checkbox currently handled in Checkbox.php form element, workaround in field widget in UIP 2.

TODO:
- field storage and field setting mapping into the component
- test checkboxes as field widget
- test with multiple values fields in field widget
- handle data type constraints?