DataForm: Fix Edit for array field type

[oandregal]

What?

When the array field type has elements, render a multi-selection select control.

Screen.Recording.2025-07-31.at.14.24.31.mov

Why?

It's returning an error because there's a mismatch between the control displayed for editing (select with single-selection) and the array nature of the field (multiple elements).

How?

By making the select control use multi-selection when the field type is an array.

Testing Instructions

• Start the local storybook (npm install && npm run storybook:dev, and visit the "DataViews > FieldTypes > Array" story.
• Select an item in the table.
• Verify the right sidebar displays a select control with multi-selection and that changing data updates the table.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: oandregal <[email protected]>
Co-authored-by: chihsuan <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[oandregal]

cc @chihsuan

[chihsuan]

Thanks for the fix! @oandregal The approach addresses the immediate issue well.

I have a few observations:

1. Default value mismatch: Should we also update line 20 for array field? e.g const value = field.getValue( { item: data } ) ?? (field.type === 'array' ? [] : '');

2. Using field.type checks in controls creates coupling - Each new field type might require control modifications. While I'm fine with this approach, but if I remember correctly, we wanted to avoid field.type coupling in implementation. What are your thoughts on this? I'm not sure if it's easy to avoid this coupling. We would probably need to create multi-select control that fields can specify when elements are provided. Not blocking for this PR, just bring this up for discussion.

[oandregal]

Default value mismatch: Should we also update line 20 for array field?

Good catch, I fixed this as well.

Using field.type checks in controls creates coupling - Each new field type might require control modifications. While I'm fine with this approach, but if I remember correctly, we wanted to avoid field.type coupling in implementation. What are your thoughts on this? I'm not sure if it's easy to avoid this coupling. We would probably need to create multi-select control that fields can specify when elements are provided. Not blocking for this PR, just bring this up for discussion.

I considered a select-multi control, but creating different controls for different prop variations doesn't seem scalable. A promising angle would be to allow the fields to configure the controls. If we enabled 3rd party to add more field types, checking the type wouldn't work and we'd need a different approach. I agree to that.

One alternative that solves the two issues above would be to add a field.isMultiple flag. The reason I didn't implemented it is that it is more impactful: it means the field is "an array", effectively, so it affects rendering, editing, and filtering. If we went that route, I'd remove the array field type in favor of that approach. Any thoughts?

For now, I think this PR is fine to land: fixes the bug, doesn't introduce any new API, doesn't add new coupling between subsystems, and it's easy to migrate to another approach if we open up field type definition to 3rd parties.