Improve field overrides for input attributes

[MoritzLost]

Describe the bug

I'm trying to override some input attributes in a form. I stumbled over two issues, not really bugs, but more like DX problems.

Undocumented format

The documentation only says I can set inputAttributes for individual fields. I would've expected to be able to use the same format accepted by the attr() function:

{% do form.setFieldSettings('myCustomField', {
    inputAttributes: {
        readonly: true,
    }
) %}

But that is silently ignored. I had to fire up XDebug to figure out I need to specify attributes like this:

{% do form.setFieldSettings('myCustomField', {
    inputAttributes: [
        {
            label: 'readonly',
            value: true,
        }
    ],
}) %}

That format is really weird – the name of an attribute is definitely not called a label. I guess that format is taken directly from the input table in the Control Panel?

I would suggest the following improvements:

1. Support the format from the first code example, which would be the standard format to specify input attributes in Craft.
2. If that is not possible, the accepted format should be mentioned prominently in the docs.
3. Passing data in an invalid format should throw an error instead of being silently ignored.

Merging with existing attributes

When I pass inputAttributes, those overwrite any existing attributes on the field. Makes sense since the method is called setFieldAttributes. However, it would be really convenient if there was a way to add additional attributes, without overwriting the existing ones.

The only way I can think of to solve this is to get the existing attributes and merge them with my custom attributes, which feels like a lot of boilerplate.

Steps to reproduce

See above.

Form settings

• Multi-page form: No
• Submission Method: Ajax
• Client-side Validation: Yes
• Custom Form Templates: No

Craft CMS version

5.8.8

Plugin version

dev-craft-5 (3.1.1)

Multi-site?

No response

Additional context

No response

[engram-design]

I agree, it's because the inputAttibutes setting is technically managed by the editable table component, which saves its data like that. I agree that we should probably be transforming that data to fit the control, rather than making that how it's stored. I'm almost sure this is a complication of the Vue component/framework we use for the control panel, which we're looking into at a more holistic level.

We probably do need a better method of setting attributes (HTML attributes) to manage things like add/remove/merge better - like Theme Config. I'll look at adding better handling for that.