Example of separating triggers, labels and messages from core fields?

[binaryartifex]

Ive noticed in the new react-aria-components lib that there's the capacity to split the parts of a field into constituent elements to have a little more control over where something is rendered. Ive been working with react-aria exclusively for the last year and it is always me accepting the hooks api, then getting frustrated with the tight coupling of triggers, labels and descriptions to the specific field mechanics which prevents me from having the layout or styling freedom that makes headless ui and radix attractive....then ill look into radix or headless ui as an alternative, realise they're not even in the same ballpark as far as accessibility goes and neither have a good calendar component, then ill resign myself to react-aria's hooks and go full material-ui on the overrides to provide a modicum of styling and layout flexibility with my fields.

Is there any examples and is it even possible with the current hooks to perhaps leverage a local react context in a way that provides this kind of flexibility?

[LFDanLu]

Just to be clear, you want to have a component structure like what react aria components allows instead of an implementation like the aria hooks docs show? Do you have an example illustrating the issue you are running into with the hooks here? Is it mainly to do with propagating the various props (e.g. labelProps, errorMessageProps, etc) that are returned by the hooks to their respective Label/Text elements that would be added by the user rather than being rendered as a part of the component inherently? If so, you could perhaps mimic how the react aria components pass those props via context. Alternatively, is there something the current react aria components implementation doesn't offer that you find yourself dropping down to the hooks level to implement instead?

[binaryartifex]

yeah unfortunately with react-aria-components ive run into an issue where, in particular with textfields, the input fields have the hover/focus states and now i can't figure out how to style a parent wrapper based on the data attributes of the input child as the textfield doesn't possess the same classname renderprops as say, button does.

With using context to split out the parts of the component, that works great for things like text-field where the useTextfield can be in a root component (TextField.Root) and pass down the label, error/description, props, etc to the child elements, but my brain fries at trying to do it with something like Select where children is already being used as a collection, and if the collection is used as a child.

<SelectField.Root {...what props?}>
    <SelectField.Label />
    <SelectField.List> 
        {(item) => <SelectField.Item key={item.key}>{item.value}</SelectField.Item>}
    </SelectField.List>
    <SelectField.Description />
</SelectField.Root>

my chicken-egg problem here is that i can't use useSelect or useSelectState in the root component because they rely on the children component, and i can't use it in the SelectField.List because then i can't pass label and error/description props to the label and description props above and below the list.... :/

[LFDanLu]

yeah unfortunately with react-aria-components ive run into an issue where, in particular with textfields, the input fields have the hover/focus states and now i can't figure out how to style a parent wrapper based on the data attributes of the input child as the textfield doesn't possess the same classname renderprops as say, button does.

Hopefully when #4616 is release, the above should be easier for you to do since the parent wrapper of the RAC Select will have things like isFocused available.

As for the issue with select where the collection children may not be the immediate child of the component calling useSelectState, you can checkout how we handled this in RAC Select here. We instead grab the children from the ListBox component and build the collection via a direct call of useCollection instead of relying on useSelectState being passed the children directly and generating the collection via CollectionBuilder.

[binaryartifex]

ahh yeah nice answered the question for both RAC and hooks. makes perfect sense. cheers mate. Looking forward to the next RAC release. with a little more freedom of movement with intrinsic events on interactive fields i think my reasons for hooks-only implementations are out the window.