github redux-form/redux-form v6.0.0-alpha.14

latest releases: v8.3.10, v8.3.9, v8.3.8...
pre-release7 years ago
  • Field and FieldArray now have instance-level dirty, pristine, and value properties. #988 #993
  • form value given to reduxForm() 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.

Don't miss a new redux-form release

NewReleases is sending notifications on new releases.