This is a nice public enhancement for the fields :)

This approach is problematic from two angles:

• It couples API and implementation (the specific component in use). If we do this, switching the internal component in use by DataForm to a different one (e.g., a new component library) is going to be impossible: the framework doesn't know which properties the consumer is using, and so it can't rematch them if some prop changes the name, for example — not to mention that the new component may not support certain properties the old one does.
• It competes with and dilutes the Field API. For example, why people would use isValid.required or isValid.pattern if they just can pass editProps.required directly? This is problematic because validation becomes something we can't analyze and use outside the component itself.

My suggestion is: can we add this control without the ability to modify it?

Unless we have a concrete use case where we need this immediately, that'd be my preference. It's easier to add new things later than to remove them. If we absolutely need it now for a specific use case, we could do:

{
  type: 'text',
  Edit: {
    type: 'textarea',
    rows: '3'
  }
}

The Edit object would not allow any property, but only the ones we deem necessary. That way, we are in control and API-implementation are decoupled (and we can switch to a different component library, for example).

I do like @oandregal's suggestion better, but I'm also not sure if it's strictly an Edit property, your remark about isRequired is good too.

In some cases, fields can have extra "properties" at the field level that would be good to pass to the form. For instance "min/max" this can be both a validation config and also something for "Edit". In other words even isValid.required might not be a "validation-only" concern and could be a top level property of the field.

All of this is also why I prefer this to be addressed separately from adding the control. It's its own concern.

The tracking issue on Field validation may be relevant as context: #71500

I see min/max as part of isValid. And there's also isValid.elements that has helped to absorb similar needs. For example, a case that came up was the ability to control the FormTokenField (array control): sometimes it allows users to add items not in the elements list, and sometimes it should not. The idea for this is to leverage isValid.elements instead: if isValid.elements: true the control won't allow users to introduce new values. This would also help in removing the logic we have in custom for field types. See ongoing PR #71194

Another use case was adding prefixes/sufixes. See Automattic/wp-calypso#105213 (comment)

So, yeah, I agree we need something like this — though it needs to be controlled by the framework and looked at case by case to decide where it goes (isValid, Edit, etc.).

Tracked this at #70936

Allow consumers to configure the bundled Edit control.

All of this is also why I prefer this to be addressed separately from adding the control. It's its own concern.

Agreed. Thanks for the discussion here!

Overall I quite like the shape of what you've described, so it could even include resize, too:

{
  type: 'text',
  Edit: {
    type: 'textarea',
    rows: '3',
    resize: 'vertical'
  }
}

But yes, let's explore this idea separately.

I summarized this thread and created #71560 for shaping the API.

Can we add this as a control without exposing a specific FieldType for it? Consumers would use it this way:

{
  type: 'text',
  Edit: 'textarea'
}

The difference between a control and a FieldType is a blurry one. Field types communicate some kind of "domain" logic, they don't expose UI components nomenclature (e.g., we don't have a ToogleControl field type but we do have a control for it). If we were to do this, we could perhaps have a longtext field type. I may sound like a broken record, but I'd rather implement a longtext when/if we need it.

Agreed this should be just a control :)

I'd prefer to leave this out of this PR and its own dedicated one.