Controlled and uncontrolled form inputs in React don't have to be complicated

07 Nov 2016

Cover image: Controlled and uncontrolled form inputs in React don't have to be complicated

You may have seen many articles saying "you shouldn't use setState," and the docs are claiming "refs are bad"... That is so contradictory. It's hard to understand how to "get it right" and even what are the criteria for choosing.

How the hell are you supposed to make forms?

After all, forms are central to many web apps out there. And yet, form handling in React seems to be a bit of a... corner stone?

Fear no more. Let me show you the differences between the approaches, as well as when you should use each.

The Uncontrolled

Uncontrolled inputs are like traditional HTML form inputs:

class Form extends Component {
  render() {
    return (
      <div>
        <input type="text" />
      </div>
    );
  }
}

They remember what you typed. You can then get their value using a ref. For example, in onClick handler of a button:

class Form extends Component {
  handleSubmitClick = () => {
    const name = this._name.value;
    // do something with `name`
  };

  render() {
    return (
      <div>
        <input type="text" ref={(input) => (this._name = input)} />
        <button onClick={this.handleSubmitClick}>Sign up</button>
      </div>
    );
  }
}

In other words, you have to 'pull' the value from the field when you need it. This can happen when the form is submitted.

That is the simplest way to implement the form inputs. There certainly are valid cases for using it: in simple forms in the real world; and when learning React.

It's not as powerful, though, so let's see those controlled inputs next.

For what it's worth, I'm giving away two chapters of my book about forms. Get it below if you want; and continue reading the article.

Article continues:

The Controlled

A controlled input accepts its current value as a prop, as well as a callback to change that value. You could say it's a more "React way" of approaching this (which doesn't mean you should always use it).

<input value={someValue} onChange={handleChange} />

Which is fine and all... but the value of this input has to live in the state somewhere. Typically, the component that renders the input (aka the form component) saves that in its state:

class Form extends Component {
  constructor() {
    super();
    this.state = {
      name: "",
    };
  }

  handleNameChange = (event) => {
    this.setState({ name: event.target.value });
  };

  render() {
    return (
      <div>
        <input type="text" value={this.state.name} onChange={this.handleNameChange} />
      </div>
    );
  }
}

(Of course, it can be in the state of another component, or even in the separate state store, like Redux.)

Every time you type a new character, handleNameChange is called. It takes in the new value of the input and sets it in the state.

  • It starts out as an empty string — ''.

  • You type a and handleNameChange gets an a and calls setState. The input is then re-rendered to have the value of a.

  • You type b. handleNameChange gets the value of ab and sets that to the state. The input is re-rendered once more, now with value="ab".

This flow kind of 'pushes' the value changes to the form component, so the Form component always has the current value of the input, without needing to ask for it explicitly.

This means your data (state) and UI (inputs) are always in sync. The state gives the value to the input, and the input asks the Form to change the current value.

This also means that the form component can respond to input changes immediately; for example, by:

But if you don't need any of that and consider uncontrolled to be simpler, go for it.

What makes an element "controlled"

There are other form elements, of course. You have checkboxes and radios and selects and textareas.

A form element becomes "controlled" if you set its value via a prop. That's all.

Each of the form elements, though, has a different prop for setting that value, so here's a little table to summarize:

ElementValue propertyChange callbackNew value in the callback
<input type="text" />value="string"onChangeevent.target.value
<input type="checkbox" />checked={boolean}onChangeevent.target.checked
<input type="radio" />checked={boolean}onChangeevent.target.checked
<textarea />value="string"onChangeevent.target.value
<select />value="option value"onChangeevent.target.value

Conclusion

Both the controlled and uncontrolled form fields have their merit. Evaluate your specific situation and pick the approach — what works for you is good enough.

If your form is incredibly simple in terms of UI feedback, uncontrolled with refs is entirely fine. You don't have to listen to what the various articles are saying is "bad."

featureuncontrolledcontrolled
one-time value retrieval (e.g. on submit)
validating on submit
instant field validation
conditionally disabling submit button
enforcing input format
several inputs for one piece of data
dynamic inputs

Also, this is not an once-and-for-all decision: you can always migrate to controlled inputs. Going from uncontrolled to controlled inputs is not hard.

Finally, here's the organized list of my posts about forms in React.

References

Think your friends would dig this article, too?

Google+
If you need a mobile app built for your business or your idea, there's a chance I could help you with that.
Leave your email here and I will get back to you shortly.