are @react-aria/* packages more than "accessible primitives" now?

[csantos1113]

after seeing the work done in #5288 that introduced form validation to the @react-aria packages I have a couple clarifying questions regarding the intention of @react-aria/* pkgs and specifically about form integration with external libraries like react-hook-form

1️⃣ Are @react-aria/* hooks doing more than what they were originally intended to do?

from https://react-spectrum.adobe.com/react-aria/:

A library of React Hooks that provides accessible UI primitives for your design system.

I've used these hooks as low-level elements that give me the correct accessible props as well as event handlers for my components to work (aria-*, focus, hover, labelling, etc) where I just passed some props in and these hooks gave me props back for my HTML elements to be accessible.

But specifically talking about @react-aria/textfield (useTextField hook) (and other fields) there is a lot of logic that I wonder if they are truly part of the "accessible hook primitives", and/or if they should be moved somewhere else:

• react-spectrum/packages/@react-aria/textfield/src/useTextField.ts

  Line 139 in 75417bb

  useFormReset(ref, value, setValue);

• react-spectrum/packages/@react-aria/textfield/src/useTextField.ts

  Line 140 in 75417bb

  useFormValidation(props, validationState, ref);

• react-spectrum/packages/@react-aria/textfield/src/useTextField.ts

  Lines 142 to 158 in 75417bb

  	useEffect(() => {
  	// This works around a React/Chrome bug that prevents textarea elements from validating when controlled.
  	// We prevent React from updating defaultValue (i.e. children) of textarea when `value` changes,
  	// which causes Chrome to skip validation. Only updating `value` is ok in our case since our
  	// textareas are always controlled. React is planning on removing this synchronization in a
  	// future major version.
  	// https://github.com/facebook/react/issues/19474
  	// https://github.com/facebook/react/issues/11896
  	if (ref.current instanceof getOwnerWindow(ref.current).HTMLTextAreaElement) {
  	let input = ref.current;
  	Object.defineProperty(input, 'defaultValue', {
  	get: () => input.value,
  	set: () => {},
  	configurable: true
  	});
  	}
  	}, [ref]);

• react-spectrum/packages/@react-aria/textfield/src/useTextField.ts

  Lines 207 to 208 in 75417bb

  	validationErrors,
  	validationDetails

2️⃣ form-validation in @react-aria/* plus react-hook-form integration

I see there is a documentation section for how to integrate with react-hook-form https://react-spectrum.adobe.com/react-aria/forms.html#react-hook-form; but after navigating through the code

• https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/form/src/useFormValidation.ts
• and https://github.com/adobe/react-spectrum/blob/main/packages/%40react-stately/form/src/useFormValidationState.ts

there is a lot of JS running always, regardless if the validation is handled from the outside (in our case, by react-hook-form itself).

It seems to me that we have 2 validation mechanisms running at the same time, so I wonder if there is a way to opt-out of @react-aria validation and let the third-party handle the validation for us?

which piggybacks to my 1️⃣ question: should these primitive hooks stay "dumb" and move that extra logic somewhere else?

---

I appreciate your help talking through these points and what would be the overall roadmap 🙏

[devongovett]

We are certainly adding more features to React Aria to make it easier to use, but I wouldn't consider form validation to be outside its realm. In our case, we are mostly just wrapping the native HTML form validation with a nicer API. If you want to use a separate form library that's also fine – all of the built-in features can be turned off, and they are pretty small so shouldn't affect much. Native validation is nice, but we know that people are mixing our components with others so external form libraries are also supported. As long as it's not getting in the way of anything it seems fine to me.

[csantos1113]

Hey @devongovett thanks for replying back.

Please allow me to dive into this particular topic:@react-stately/form. It has a lot of built-in logic that as far as I can tell, I'm not able to turn off.

For example:

• useFormValidationState is used by all form related hooks in @react-aria/*
• that hook uses a context
• but that context is only initialized in react-aria-components
  • And I'm not using react-aria-components
• Even without that context, react-hook-form is the one doing the validation in my case
  • I use react-hook-form + useTextField; that's pretty much it

Which is what I meant by "there is a lot of JS running always, regardless if the validation is handled from the outside" and would be great to just not have it running in my render cycles.

BTW: having react-hook-form doing the validation with the latest @react-aria works fine as described in https://react-spectrum.adobe.com/react-aria/forms.html#react-hook-form, but that doesn't solve the point that there is extra code running all the time (in this case: @react-stately/form wanting to validate the fields).

---

Deep thought here: Looking from the outside, Devon, could it be possible that react-aria is unintentionally growing in a direction that is too tied to react-aria-components instead of being pure primitives?

---

Thanks for your time talking through this!

[devongovett]

Is this a theoretical concern or do you have a real-world issue with it? By default when using the hooks, native validation is not enabled. So those hooks won't do anything unless you enable it with validationBehavior="native", or use the server validation or isInvalid props (isInvalid always existed and is used for integration with other form libraries). These are not specific to React Aria Components, and can be used in other Hook-based implementations as well (we do this in our React Spectrum library). IMO these are useful features that are pretty much table-stakes for any component library, so building it into React Aria simplifies things a lot and avoids the need for other libraries in many cases. But if you have a specific functionality or performance problem that you're having please let us know!

[csantos1113]

So those hooks won't do anything unless you enable it with validationBehavior="native", or use the server validation or isInvalid props (isInvalid always existed and is used for integration with other form libraries).

While this is true, it's also true the code within the hooks are running always, on every re-render, for each field.

The following lines will always run on every render per field albeit they don't do anything:

react-spectrum/packages/@react-stately/form/src/useFormValidationState.ts

Lines 76 to 186 in fc0e6b6

	function useFormValidationStateImpl<T>(props: FormValidationProps<T>): FormValidationState {
	let {isInvalid, validationState, name, value, builtinValidation, validate, validationBehavior = 'aria'} = props;
	// backward compatibility.
	if (validationState) {
	isInvalid ||= validationState === 'invalid';
	}
	// If the isInvalid prop is true, update validation result in realtime (controlled).
	let controlledError: ValidationResult | null = isInvalid ? {
	isInvalid: true,
	validationErrors: [],
	validationDetails: CUSTOM_VALIDITY_STATE
	} : null;
	// Perform custom client side validation.
	let clientError: ValidationResult | null = useMemo(() => getValidationResult(runValidate(validate, value)), [validate, value]);
	if (builtinValidation?.validationDetails.valid) {
	builtinValidation = null;
	}
	// Get relevant server errors from the form.
	let serverErrors = useContext(FormValidationContext);
	let serverErrorMessages = useMemo(() => {
	if (name) {
	return Array.isArray(name) ? name.flatMap(name => asArray(serverErrors[name])) : asArray(serverErrors[name]);
	}
	return [];
	}, [serverErrors, name]);
	// Show server errors when the form gets a new value, and clear when the user changes the value.
	let [lastServerErrors, setLastServerErrors] = useState(serverErrors);
	let [isServerErrorCleared, setServerErrorCleared] = useState(false);
	if (serverErrors !== lastServerErrors) {
	setLastServerErrors(serverErrors);
	setServerErrorCleared(false);
	}
	let serverError: ValidationResult | null = useMemo(() =>
	getValidationResult(isServerErrorCleared ? [] : serverErrorMessages),
	[isServerErrorCleared, serverErrorMessages]
	);
	// Track the next validation state in a ref until commitValidation is called.
	let nextValidation = useRef(DEFAULT_VALIDATION_RESULT);
	let [currentValidity, setCurrentValidity] = useState(DEFAULT_VALIDATION_RESULT);
	let lastError = useRef(DEFAULT_VALIDATION_RESULT);
	let commitValidation = () => {
	if (!commitQueued) {
	return;
	}
	setCommitQueued(false);
	let error = clientError || builtinValidation || nextValidation.current;
	if (!isEqualValidation(error, lastError.current)) {
	lastError.current = error;
	setCurrentValidity(error);
	}
	};
	let [commitQueued, setCommitQueued] = useState(false);
	useEffect(commitValidation);
	// realtimeValidation is used to update the native input element's state based on custom validation logic.
	// displayValidation is the currently displayed validation state that the user sees (e.g. on input change/form submit).
	// With validationBehavior="aria", all errors are displayed in realtime rather than on submit.
	let realtimeValidation = controlledError || serverError || clientError || builtinValidation || DEFAULT_VALIDATION_RESULT;
	let displayValidation = validationBehavior === 'native'
	? controlledError || serverError || currentValidity
	: controlledError || serverError || clientError || builtinValidation || currentValidity;
	return {
	realtimeValidation,
	displayValidation,
	updateValidation(value) {
	// If validationBehavior is 'aria', update in realtime. Otherwise, store in a ref until commit.
	if (validationBehavior === 'aria' && !isEqualValidation(currentValidity, value)) {
	setCurrentValidity(value);
	} else {
	nextValidation.current = value;
	}
	},
	resetValidation() {
	// Update the currently displayed validation state to valid on form reset,
	// even if the native validity says it isn't. It'll show again on the next form submit.
	let error = DEFAULT_VALIDATION_RESULT;
	if (!isEqualValidation(error, lastError.current)) {
	lastError.current = error;
	setCurrentValidity(error);
	}
	// Do not commit validation after the next render. This avoids a condition where
	// useSelect calls commitValidation inside an onReset handler.
	if (validationBehavior === 'native') {
	setCommitQueued(false);
	}
	setServerErrorCleared(true);
	},
	commitValidation() {
	// Commit validation state so the user sees it on blur/change/submit. Also clear any server errors.
	// Wait until after the next render to commit so that the latest value has been validated.
	if (validationBehavior === 'native') {
	setCommitQueued(true);
	}
	setServerErrorCleared(true);
	}
	};
	}

I haven't ran benchmarks, but that's quite a lot of javascript running on every re-render, even if it does nothing.

(isInvalid always existed and is used for integration with other form libraries)

In the ideal scenario, something like this is what would make the integration with other form libraries solid (note: pseudo code, but that's the overall idea):

let { isInvalid } = props;

if (typeof isInvalid === 'boolean') {
  return early because it's controlled
}

return useFormValidationStateImpl(props);

[devongovett]

Unfortunately hooks cannot be conditional in React so that's impossible. I really don't think this should have any measurable performance impact. If you don't pass in a custom validate function it isn't run, if there are no server errors on context, nothing happens, if no native validation occurred the effect returns early. The only impact would be two extra useState calls and one useRef, which should be essentially free. If you have real-world benchmarks showing a performance issue we're happy to look into it though.