For the types, should we go more granular, as suggested in #71560 (comment)? For example, prefix shouldn't be allowed on the textarea control, and rows should only be allowed on the textarea control.

Based on the conversation in the linked issue, I don’t think we want this, right? I believe we want to carefully consider adding new properties to avoid competing with the existing Field API.

Thanks for thinking of updating the examples. Can we move this to the field-types story instead? We can update the field type text to include examples with all of this (as well as any other field type affected).

The textarea doesn't have an equivalent field type, but we can add it to the field type text as well.

The render has a config object that includes extra information for certain fields (e.g., when a field is marked as "media" it gets the sizes from the layout). Can we follow suit here as well?

createConfiguredControl would pass the proper config object to the underlying control depending on its type (all the EditConfig properties but type).

Do we need this one?

I think it makes sense to have the exclusion and be speciic so IDE show the correct values when we are over EditConfigGeneric.

What others suggested: just rename from type to control to avoid overusing type.

Can we normalize the ValidatedText component (and the EditConfig type) so it exposes prefix and suffix props and both are the same type?

Both should work the same (receive an icon component or an element). I've noticed prefix receives an icon, but suffix receives an element. I'm leaning to allow an element through any prefix/suffix, but I'd like to gather @mirka thoughts on this.

The advantage of being an element is that it can be interactive. For example, a consumer could pass a prefix/suffix that opens a modal on click to do something, ala units control. This is something that could help address some use cases, but I wonder if it's a pattern we want to promote/support.

Hi @oandregal the code was updated now we have simple suffix and prefix props.

I'm leaning to allow an element through any prefix/suffix

👍

I believe you've noticed how we want different paddings depending on the slot content — icons and controls look good with 8px padding, plain text with 12px, and then sometimes you could want a full-bleed background color in the slot, which will call for 0px padding (not that common though).

So there will be a few ways to deal with that here. Either:

• Bake that into the DataForm as another configuration (e.g. slotType: 'control').
• Recommend consumers to use the wrapper components.
• Document the suggested padding values in the DataForm documentation and expect the consumers to apply those values manually in CSS.

In either case I think DataForm itself now needs to have sufficient documentation on how to apply standard paddings according to the slot content. If that sounds like too much, I think it's fair to draw a line and say we're not going to support that level of customization out of the box 😅

And as a heads up, separately from this InputControl case, similar responsibility boundary issues are likely to pop up in custom rendered select controls and combobox controls, where there will be a lot of possible customization options at the component level. I know we have concerns about back compat and feature bloat in the DataForm system, so we'll definitely need to draw a hard line somewhere in exactly how much the DataForm is going to support in its own API.

Good points @mirka, I guess for this initial version it is better to keep it simple and allow prefix and suffix but don't expose the different padding configurations, and leave it to the consumers to use InputControl...Wrapper explicitly as it is the most flexible and simple approach.

Thanks for the context, Lena!

Agreed to using the slots without further Edit config. @jorgefilipecosta when you add the README for this Edit config, could you add a note about this? I think just what the input component uses would be fine (copy/paste from the input's stories for prefix and suffix):

By default, the prefix/suffix is aligned with the edge of the input border, with no padding. If you want to apply standard padding in accordance with the size variant, wrap the element in the provided component.

@mirka, I don't see that we explain the differences between the variants (icon vs control), and, as far as I read, it doesn't make any difference. Is that correct?

I don't see that we explain the differences between the variants (icon vs control), and, as far as I read, it doesn't make any difference. Is that correct?

We do explain variants in the story and in the prop docs, if that's what you're referring to.

And yes the spacings for icon and control are the same. I just separated the variant names for ergonomics. (In v2, they may be merged into a single variant with a more generic name like minimal.)

Nit: These are text content, not controls, so they would use the "default" variant. Otherwise they will look a bit off.

Good catch, it was fixed ☺️

Can we make one of these use an icon to demonstrate the usage of the icon variant?

Do we need this story? The new fields are going to be picked up by the text fields story. I'd prefer to keep the stories organized by field type.

It was removed 👍