[RAC] Group doesn't receive `disabled` state from TextField

[Faithfinder]

🤔 Expected Behavior?

Group has data-disabled=true when text field is disabled

😯 Current Behavior

It doesn't

🔦 Context

Potential solution could be to pass data-disabled to Group manually (see in repro), however it's overwritten by Group.

🖥️ Steps to Reproduce

https://codesandbox.io/p/sandbox/agitated-snyder-5fcp5c

Version

1.5.0

What browsers are you seeing the problem on?

Chrome

What operating system are you using?

MacOS

[snowystinger]

Thanks for the issue. I think this setup is going to have issues, what else are you planning to put in the Group?

Instead, I suggest moving the Group out and around the TextField, that way, the state for the TextField won't interfere with anything else in the Group.

Maybe I'm missing a use case, can you provide a real life example?

[Faithfinder]

Thanks for the issue. I think this setup is going to have issues, what else are you planning to put in the Group?

Instead, I suggest moving the Group out and around the TextField, that way, the state for the TextField won't interfere with anything else in the Group.

Maybe I'm missing a use case, can you provide a real life example?

I'm just building out our components, everything's in flux.

Right now there's nothing in the group, but I could see adding an optional leftIcon/rightIcon or something. I have common structure between all input components

<FieldWrapper> // This is TextField/SearchField/NumberField/Select etc
	<Label />
		<Group>
			<Adornments /> // Whatever. Icons, extra buttons, etc, anything that visually goes into the input border
			<Input /> // Also different per field type
			<MoreAdornments />
		</Group>
	<Description />
	<Error />
</FieldWrapper>

In this case I could do without the group, but I'm sharing styles between all the components, and I don't want to redefine both group and input styles for this one component. Disable works in other components ok.

I don't really need group around the field wrapper, it's there to provide border around input and adornments. BTW, structure is mostly adapted from examples in the docs.

[snowystinger]

I see. What does the group having data-disabled get you that the top level of the component doesn't?

Group is specific in Aria, it "groups" the increment/decrement/input of the NumberField for instance. This means that extra information is passed along to screen readers about how to announce those various interactive elements so they are associated.
It's not needed for adornments.

Instead, you can just use a div and you can make use of the various contexts for each component or the renderProps in order to change styling. Or you can use CSS based on the top level of the component where we already attach various attributes.

[Faithfinder]

I see, I don't mind a div for sure.

The example on the "Group" page is with a text field though, is it gonna start working if a button is added?

[snowystinger]

It's fine to use a Group like that, you've got multiple interactive elements in the group. It's just unnecessary and perhaps misleading when there is only one.

Edit: looking more at the docs for Group again, it does seem a little misleading that data-disabled is listed in the styling table. I'll bring this up with the team to see what we want to do about that. But the above comments still apply with multiple interactive elements vs just presentational elements.

[Faithfinder]

My issue isn't about explicit data-disabled on a group though, it's that when TextField is disabled, the group isn't marked as disabled. Explicit data-disabled is just a simple possible workaround that also doesn't work.

I've updated the example to exactly match the docs on Group, you now have multiple interactive elements, it still doesn't work =P
I've also added the number field to the example, where it does work, despite only one interactive element inside, to show that the issue isn't number of elements, it's Group not being wired correctly into the TextField context.

[snowystinger]

Sorry if my comment was misleading. Number of interactive elements has nothing to do with the disabled state appearing on Group.

My comments were that Group has an aria role "group", which is useful when there are multiple interactive elements, so the screen reader announces them as related. It is a misleading role if there is only one interactive element. Better to just use a div for accessibility in that case.

when TextField is disabled, the group isn't marked as disabled

yes, and this is what I'm going to bring up to the team since it's odd that data-disabled is exposed at all in any way from Group according to the styling table.

[Faithfinder]

Sorry, I really am confused. Why wouldn't data-disabled be exposed? RAC or not, If you want a button inside an input border (e.g Search field), you make input invisible, and style the border of the group instead, no? Then if you need to mute the border color for disabled, it goes on the group.

That is how RAC does it for multiple kinds of fields, why is Text field any different?

[snowystinger]

NumberField/SearchField/etc, all work that way because they expect multiple interactive components (inputs + buttons + whatever)

TextField only expects the one input, so it is not concerned with Group and does not send anything to it as a result. However, I'm reconsidering if that is true or if we should warn/throw when people try to put a Group inside a TextField and enforce that assumption.