Field
andFieldArray
now have instance-leveldirty
,pristine
, andvalue
properties. #988 #993form
value given toreduxForm()
now available as a prop to the decorated component. #1007- Minor fix for race conditions when blurring and focussing. #1004
- Fixed
handleSubmit
bug when the submit button is clicked rapidly. #986 - Added missing action creator exports. #1013
- Fixed bug with array field initialization and blurring. #1023
We've got some 😃 news and some 😢 news. Let's start off with the latter...
😢 Breaking Change
Well, not so much breaking, as embracing a problem (#961) that seemed broken before. The way that the Migration Guide recommended <Field>
be used was flawed. There is a new rule:
You may not inline "fat arrow components" inside your form's render()
method.
Let's look at what that means:
WRONG: 😢 👎
class MyForm extends Component {
render() {
const { handleSubmit } = this.props
return (
<form onSubmit={handleSubmit}>
<Field name="username" component={props => // <----- CANNOT DO THIS
<div>
<input type="text" {...props}/>
{props.touched && props.error && <span>{props.error}</span>}
</div>
}/>
</form>
)
}
}
RIGHT: 😄 👍
// define "fat arrow component" outside of render()
const renderInput = props =>
<div>
<input type="text" {...props}/>
{props.touched && props.error && <span>{props.error}</span>}
</div>
class MyForm extends Component {
render() {
const { handleSubmit } = this.props
return (
<form onSubmit={handleSubmit}>
<Field name="username" component={renderInput}/> // <-- refer to component
</form>
)
}
}
That sucks! Why?
The reason is that defining a fat arrow component inside render creates a new component on every form render, which causes each Field
to rerender (because the component
prop is !==
). If you don't care that much about performance, and you are using a custom input widget, you might still be able to get away with it, but if you are using an <input>
component, that input will lose its focus whenever the form is rerendered.
It's not that bad. Take a look at the Examples and see if you don't agree that the code is cleaner this way.
😃 Adapter API
As a side effect of the breaking change above, an "adapter" API was developed, as a way to provide a shorthand for referring to commonly used input render routines. Check out the new Adapter Example.