Releases: final-form/react-final-form
v6.2.0
TypeScript fixes
- Use the same default for FormValues type in all declared types (#525)
- Replace empty object default type with any object (#526)
- Refactor getContext back to a simple context file (#524)
New Features
- Strongly typed field values (#530)
- Added tsx generic typings for Field, Form, and FormSpy components (#522)
For Typescript users, you can take advantage of JSX Generics, so you can specify the type of your form values or field value directly in the JSX call to Form, Field, or FormSpy. For Form, it will even infer the form values type if you provide initialValues.
Behold this code:
interface MyValues {
firstName: string
lastName: string
}
const initialValues: MyValues = {
firstName: 'Erik',
lastName: 'Rasmussen'
}
const onSubmit = (values: MyValues) => {
ajax.send(values)
}{/*
Typescript will complain if the type of initialValues is not
the same as what is accepted by onSubmit
*/}
<Form onSubmit={onSubmit} initialValues={initialValues}>
{({ handleSubmit, values }) => {
// 💥 Type of values is inferred from the type of initialValues 💥
return (
<form onSubmit={handleSubmit}>
{/* 😎 Field values are strongly typed using JSX generics 😎 */}
<Field<string> name="firstName" component={TextInput} />
<Field<string> name="lastName" component={TextInput} />
<Field<number> name="age" component={NumberInput} />
<button type="submit">Submit</button>
</form>
)
}}
</Form>v6.1.0
New Features
Usage:
import { withTypes, Field } from 'react-final-form'
type MyValues = {
email: string,
password: string
}
const { Form } = withTypes<MyValues>()
<Form onSubmit={onSubmit}>
{({ handleSubmit, values }) => {
// values are of type MyValues
}}
</Form>
Housekeeping
v6.0.1
v6.0.0
This release contains very minimal, edge-case, breaking changes.
Bug Fixes
- Fixed bug in form component rerendering not responding to changes in form state properly. #498 #487 #492
⚠️ Breaking Changes ⚠️
- Subscription changes will now be ignored. For some reason previous versions of React Final Form did extra work to allow you to change the
subscriptionprop, causing the component to reregister with the Final Form instance. That is a very rare use case, and it was a lot of code to enable it. If you need to change your subscription prop, you should also change thekeyprop, which will force the component to be destroyed and remounted with the new subscription. parse={null}andformat={null}are no longer allowed. That was a bad choice of API design, which is probably why Flow doesn't allow theFunction | nullunion type. #400 Passingnullserved the purpose of disabling the defaultparseandformatfunctionality. If you need to disable the existingparseandformat, you can pass an identity function,v => v, toparseandformat.
< v6
<Field name="name" parse={null} format={null}/>>= v6
const identity = v => v
...
<Field name="name" parse={identity} format={identity}/>v5.1.2
v5.1.1
v5.1.0
New Features
- Used [email protected]'s new
beforeSubmitcallback to enableformatOnBlurbefore submit #478 #470
v5.0.2
v5.0.1
v5.0.0
🎉 v5.0.0 – HOOKS!!! 🎉
First to explain why this change was made... To manage subscriptions to the internal 🏁 Final Form instance, 🏁 React Final Form has been using some legacy lifecycle methods that make the side effect of subscribing to an event emitter cumbersome. Such subscriptions are a perfect use case (no pun intended) for the new React.useEffect() hook. In an effort to modernize and future proof the library, the entire thing has been rewritten to use hooks.
All the previous tests have been rewritten to use 🐐 React Testing Library, which is a superior way to test React components. None of the tests were removed, so all existing functionality from v4 should work in v5, including some optimizations to minimize superfluous additional renders that were made possible by hooks.
⚠️ BREAKING CHANGES 😮
Don't worry...there really aren't that many.
- Requires
^[email protected]. That's where the hooks are. 🙄 - All deprecated functions provided in
FormRenderPropsandFormSpyRenderPropshave been removed. They have been spitting warnings at you sincev3, so you've probably already corrected for this. The following applies to:batchblurchangefocusinitializemutatorsreset
Rather than spreading the FormApi into the render props, you are just given form itself.
v4
<Form onSubmit={submit}>{({ reset }) => (
// fields here
<button type="button" onClick={reset}>Reset</button>
)}</Form>v5
<Form onSubmit={submit}>{({ form }) => (
// fields here
<button type="button" onClick={form.reset}>Reset</button>
)}</Form>Fieldwill no longer rerender when thevalidateprop. Note: it will still always run the latest validation function you have given it, but it won't rerender when the prop is!==. This is to allow the very common practice of providing an inline=>function as a field-level validation function. This change will break the very rare edge case where if you are swapping field-level validation functions with different behaviors on subsequent renders, the field will no longer rerender with the new validation errors. The fix for this is to also change thekeyprop onFieldany time you swap thevalidatefunction. See this test for an example of what I mean. There's also a sandbox demonstrating the issue:
- The previously exported
withReactFinalFormHOC has been removed. Now you should use theuseForm()hook if you'd like to get the 🏁 Final Form instance out of the context. To ease your transition, you can make your own with a single line of code:
const withReactFinalForm = Component => props =>
<Component reactFinalForm={useForm()} {...props} /> 😎 New Hook API 😎
Because it was so easy to do, 🏁 React Final Form now exports the useField and useFormState hooks that are used internally in Field and FormSpy respectively. Literally the only thing Field and FormSpy do now is call their hook and then figure out if you are trying to render with the component, render, or children prop.
For example, before v5, if you wanted to create a custom error component that only rerendered when touched or error changed for a field, you'd have to do this:
v4
const Error = ({ name }) => (
<Field name={name} subscription={{ touched: true, error: true }}>
{field =>
field.meta.touched && field.meta.error ? (
<span>{field.meta.error}</span>
) : null
}
</Field>
)...but now you can do:
v5
const Error = ({ name }) => {
const field = useField(name, { subscription: { touched: true, error: true } })
return field.meta.touched && field.meta.error ? (
<span>{field.meta.error}</span>
) : null
}Not too groundbreakingly different, but these hooks might allow for some composability that was previously harder to do, like this clever disgusting hack to listen to multiple fields at once.
Go forth and hook all the things! 🎣
Special thanks to @Andarist for giving me such an extensive code review on #467.