Flaky tests detected in 61aea31.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17951265739
📝 Reported issues:

• [Flaky Test] should refresh the page when stylesheet loading fails #71722 in /test/e2e/specs/interactivity/router-styles.spec.ts

Size Change: +2.02 kB (+0.1%)

Total Size: 1.95 MB

_{compressed-size-action}

Hey @oandregal ,

This is a very meaningful update to the array field type, that will definitely benefit the use case we discussed.

I really liked that in the example you created, you added both a list and another field outside the list (i.e. Total Amount). This matches perfectly our use case where we have a date picker field and then a list.

A couple of notes:

One of the things that I didn't fully explore when creating the DataForm with a custom Edit component was how to validate each field in the list, so I wanted to see how you handled it here. I understand that this is handled by isValid, but I wasn't able to trigger this validation in the Storybook example.

The main reason why was that the Storybook example that opens in a modal behaves in an unexpected way for me:

I think there are 3 potential types of validation that we need to consider here:

• Per individual field, for example typing a non-email string in a email field.
• Per row, when the validation of one field in the row depends on the value of another field in the same row. For example, in our use case each row is a pair of start and end times, where it is expected that the end time will always be after the start time.
• Per list, when the rows added in the list are not compatible with each other. For example, in our use case, we want to ensure that there aren't any start/end time pairs that are overlapping.

Which of those validation levels are supported now?

Another question I have about extensibility, is around the "Add item" button. I noticed that this string is hardcoded -- is there a way to make it so each list has its own button text, like "Add product" or "Add time slots", depending on the context?

I think that the new API is flexible and easy to grasp. Combining it with custom Edit controls for non-editable fields gives plenty of space to cover a wide set of requirements.

I've noticed that the buttons to add and remove rows are part of the new TableControl component. This use case feels specific enough that I wonder whether it is necessary to have something built-in for this purpose or leave this completely in user land, where removing and adding a row would be achieved by editing the data passed to DataForm?

Which of those validation levels are supported now?

All of them.

"Per individual field" + "Per row" can be addressed by implementing a custom function in any of the child fields. Note that isValid.custom receives the full item (row). "Per list" can be addressed by implementing isValid.custom at the parent field level.

The main reason why was that the Storybook example that opens in a modal behaves in an unexpected way for me:

I'll fix this.

Another question I have about extensibility, is around the "Add item" button. I noticed that this string is hardcoded -- is there a way to make it so each list has its own button text, like "Add product" or "Add time slots", depending on the context?
...
This use case feels specific enough that I wonder whether it is necessary to have something built-in for this purpose or leave this completely in user land, where removing and adding a row would be achieved by editing the data passed to DataForm?

I suppose these two things are part of the same: we may want to configure the table so that it can have a fix number of rows (no add/remove actions) + the labels of the actions.

@straku @jimjasson I've addressed your feedback by allowing consumers to control these actions: they can disable them and update the labels by leveraging the Edit config.

By default, the table displays with delete/add actions and the labels are "Add item", "Remove item":

{
  id: 'productList',
  label: 'Product List',
  type: 'array',
  children: [ /* ... */ ],
}

Consumers can configure the labels as such:

{
  id: 'productList',
  label: 'Product List',
  type: 'array',
  Edit: {
    control: 'table',
    actions: {
      delete: "Remove product",
      add: "Add product"
    }
  },
  children: [ /* ... */ ],
}

And consumers can also disable the actions (these renders a table without delete/add actions):

{
  id: 'productList',
  label: 'Product List',
  type: 'array',
  Edit: {
    control: 'table',
    actions: {
      delete: false,
      add: false
    }
  },
  children: [ /* ... */ ],
}

We could be even more flexible: change the action icon, adding custom actions, etc. but I think that'd better be a follow-up, only when/if we need it.

"Per individual field" + "Per row" can be addressed by implementing a custom function in any of the child fields. Note that isValid.custom receives the full item (row). "Per list" can be addressed by implementing isValid.custom at the parent field level.

Makes sense!

I've addressed your feedback by allowing consumers to control these actions: they can disable them and update the labels by leveraging the Edit config.

This is very useful, thanks for addressing it!

Overall, I like the decision to:

• use the standard combobox element for array fields without children and;
• the new TableControl for arrays with children (nested or not nested).

I tested the Fields stories and they all work as expected.

However, the DataForm story is still not fully functional for me:

(1) When I type in a single character in the product name field, it automatically loses focus:

(2) The modal doesn't work correctly: