Inconsistent Provider placement in components

[af-cf]

Hi. I noticed that certain components have an inconsistent placement of <Provider>. Sometimes it's the root element, sometimes it's not.

Examples:

• https://github.com/adobe/react-spectrum/blob/main/packages/react-aria-components/src/Select.tsx#L243 (nested)
• https://github.com/adobe/react-spectrum/blob/main/packages/react-aria-components/src/NumberField.tsx#L157 (nested)
• https://github.com/adobe/react-spectrum/blob/main/packages/react-aria-components/src/SearchField.tsx#L168 (root)
• https://github.com/adobe/react-spectrum/blob/main/packages/react-aria-components/src/TextField.tsx#L159 (root)

I noticed when implementing RAC I would use render prop to render a generically styled form field container component, RAC components that do not have Provider as root would (for obvious reasons) not set the context props for elements like RAC label or error that are inside of that form field container component.

For now I am relying on testing as I implement to determine whether render prop works or not and then opt for nesting the field container component instead if render doesn't work. However I imagine ideally it should be consistent across all of the components that implement a provider.

[snowystinger]

Sorry, I don't quite follow what you're saying. Would you mind putting together an example in a stackblitz showing the problem?
I tried something like rendering a NumberField as a span here https://stackblitz.com/edit/psd3f7h3?file=src%2FNumberField.tsx
Feel free to fork that project.

[af-cf]

render prop is applied to dom.div. So if whatever is being passed to the render contains something that depends on what the Provider sets, e.g. a Label, those elements will not receive provider values because of the order in which dom.div is placed, i.e. dom.div -> Provider.

NumberField is not an issue because Provider in NumberField is the root element of that component, so anything that gets passed through the render function can get the values set by the provider.

In the following example you can see that when I pass FieldContainer to the render prop, the Label inside the FieldContainer never receives any of the values set by the Provider inside the TextField component.

https://stackblitz.com/edit/r5trthng?file=src%2FTextField.tsx

The fix should be just swapping Provider and dom.div so that Provider is always the root element in some of those components. However I wasn't sure if this was intentional or not, hence why I chose to ask first before reporting it as a bug.

[snowystinger]

I see, I don't think I'd use the render prop in this way. You can just pass all of those things as children. render is really just meant to replace that one element with a different one. Is there some reason you cannot pass those as children instead?

[af-cf]

I could pass them as children, but would prefer to avoid extra DOM elements in the tree if they are not needed.

[snowystinger]

Apologies, I'm not understanding, what's the extra DOM element? In the example stackblitz there'd be the same number either way.

I'm also not sure why we're avoiding extra dom elements. React is very efficient at reusing and computers and phones these days are plenty fast enough to not worry about it. We actually prefer an extra element in our S2 implementation vs things like psuedo elements.

[af-cf]

Whether one chooses to avoid extra DOM elements is not relevant here. If someone choose to utilize the render prop, then it should work as expected, right?

As per render prop docs:

Overrides the default DOM element with a custom render function. This allows rendering existing components with built-in styles and behaviors such as router links, animation libraries, and pre-styled components.

In the example FieldContainer is a pre-styled component that also happens to contain RAC Label and Text which would expected to be configured by the Provider of TextField.

<!--
<AriaTextField
	{...props}
	render={(props) => (
		<FieldContainer
			{...props}
			label={label}
			description={description}
			errorMessage={errorMessage}
		/>
	)}
>
	<Input className="react-aria-Input inset" placeholder={placeholder} />
</AriaTextField>
-->
<div class="react-aria-TextField" data-rac="">
	<label class="react-aria-Label">Name</label> <!-- missing attributes set by the Provider in TextField because Provider is nested inside `dom.div` in TextField -->

	<input
		placeholder="Enter your full name"
		tabindex="0"
		id="react-aria5239654258-_r_0_"
		class="react-aria-Input inset"
		data-rac=""
		type="text"
		value=""
		title=""
	/>
</div>

<!--
<AriaTextField {...props}>
	<FieldContainer
		{...props}
		label={label}
		description={description}
		errorMessage={errorMessage}
	>
		<Input className="react-aria-Input inset" placeholder={placeholder} />
	</FieldContainer>
</AriaTextField>
-->
<div class="react-aria-TextField" data-rac="">
	<div> <!-- root element of FieldContainer, could be "joined" with parent element via `render` prop -->
		<label
			class="react-aria-Label"
			id="react-aria5239654258-_r_6_"
			for="react-aria5239654258-_r_5_"
		>
			Name
		</label>

		<input
			placeholder="Enter your full name"
			tabindex="0"
			id="react-aria5239654258-_r_5_"
			aria-labelledby="react-aria5239654258-_r_6_"
			class="react-aria-Input inset"
			data-rac=""
			type="text"
			value=""
			title=""
		/>
	</div>
</div>

The main question still stand, as to whether composition of some RAC components is intentional or accidental, i.e. sometimes dom.div inside Provider and sometimes Provider inside dom.div where dom.div is what receives the render prop and if it's not structured in specific order, the rendered component will never receive values set by Provider.