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.

[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.

[snowystinger]

Sorry, I lost this thread. I see what you mean now. Thank you for the extra details. I'll open this as an issue for further discussion

[b3nten]

I'm running into this issue as well with Popover, as the OverlayArrowContext only wraps the children of the render props output. This means if I create a surface that includes OverlayArrow to use as the render input, it's outside of the provider. However I cannot just render the surface as children with a wrapper element, because animations are calculated on the wrapper and not children.

You can be a bit clever and render the host inside OverlayArrowContext but then you end up the DismissButtons outside of the host and I'm not sure what the implications are about that.