[v2] Additional unit testing for Formik hooks implementation

[johnrom]

🚀 Feature request

Current Behavior

As Formik evolves, the community is becoming highly involved in creating PRs and executing changes. To support growth and alleviate some pressure on the maintainers, a healthy Unit Testing suite is a worthy goal.

Currently v2 hooks have a lot of callbacks which merely deal with Promises and Dispatch. Testing those callbacks is generally out of scope for this project because those would be integration tests. However, some of those callbacks use logic that I would like to consider for Unit Testing in the future, and I've outlined that logic below.

These are the only pieces I've found on my first pass, but feel free to give it another pass and see if you can find any other important decision-making blocks.

• ResetForm

formik/src/Formik.tsx

Lines 313 to 338 in af86ca9

	const resetForm = React.useCallback(
	(nextState?: FormikState<Values>) => {
	const values =
	nextState && nextState.values
	? nextState.values
	: initialValues.current
	? initialValues.current
	: props.initialValues;
	const errors =
	nextState && nextState.errors
	? nextState.errors
	: initialErrors.current
	? initialErrors.current
	: props.initialErrors || {};
	const touched =
	nextState && nextState.touched
	? nextState.touched
	: initialTouched.current
	? initialTouched.current
	: props.initialTouched || {};
	const status =
	nextState && nextState.status
	? nextState.status
	: initialStatus.current
	? initialStatus.current
	: props.initialStatus;

• Parse / Format Field Value (I believe this functionality is changing, ref: Remove special number parsing logic for input of type number and range #1171 [v2]: Add parse and format props to useField/Field #1525)

This is one of the most important functions of Formik, so I recommend creating a test suite for it.

formik/src/Formik.tsx

Lines 496 to 528 in af86ca9

	let val = eventOrTextValue;
	let parsed;
	// If the first argument is not a string though, it has to be a synthetic React Event (or a fake one),
	// so we handle like we would a normal HTML change event.
	if (!isString(eventOrTextValue)) {
	// If we can, persist the event
	// @see https://reactjs.org/docs/events.html#event-pooling
	if ((eventOrTextValue as React.ChangeEvent<any>).persist) {
	(eventOrTextValue as React.ChangeEvent<any>).persist();
	}
	const {
	type,
	name,
	id,
	value,
	checked,
	outerHTML,
	} = (eventOrTextValue as React.ChangeEvent<any>).target;
	field = maybePath ? maybePath : name ? name : id;
	if (!field && process.env.NODE_ENV !== 'production') {
	warnAboutMissingIdentifier({
	htmlContent: outerHTML,
	documentationAnchorLink:
	'handlechange-e-reactchangeeventany--void',
	handlerName: 'handleChange',
	});
	}
	val = /number|range/.test(type)
	? ((parsed = parseFloat(value)), isNaN(parsed) ? '' : parsed)
	: /checkbox/.test(type)
	? checked
	: value;
	}

Suggested Solution

Split out the decision-making code blocks into unit testable selectors.

Who does this impact? Who is this for?

Maintainers, Contributors

References

Initial discussion: #1063 (comment)