Home » Reactjs » Use state or refs in React.js form components?

Use state or refs in React.js form components?

Posted by: admin November 29, 2017 Leave a comment


Im starting with React.js and i want to do a simple form but in the documentacion I have found two ways of doing it.
The first one is using Refs:

var CommentForm = React.createClass({
  handleSubmit: function(e) {
    var author = React.findDOMNode(this.refs.author).value.trim();
    var text = React.findDOMNode(this.refs.text).value.trim();
    if (!text || !author) {
    // TODO: send request to the server
    React.findDOMNode(this.refs.author).value = '';
    React.findDOMNode(this.refs.text).value = '';
  render: function() {
    return (
      <form className="commentForm" onSubmit={this.handleSubmit}>
        <input type="text" placeholder="Your name" ref="author" />
        <input type="text" placeholder="Say something..." ref="text" />
        <input type="submit" value="Post" />

And the second one is using state inside the React component:

var TodoTextInput = React.createClass({
  getInitialState: function() {
    return {
      value: this.props.value || ''

  render: function() /*object*/ {
    return (
      <input className={this.props.className}

  _save: function() {
    this.setState({value: ''

I can’t see the pros and cons of the two alternatives, if some exists.


The short version: avoid refs.

They’re bad for maintainability, and lose a lot of the simplicity of the WYSIWYG model render provides.

You have a form. You need to add a button that resets the form.

  • refs:
    • manipulate the DOM
    • render describes how the form looked 3 minutes ago
  • state
    • setState
    • render describes how the form looks

You have an CCV number field in an input and some other fields in your application that are numbers. Now you need to enforce the user only enters numbers.

  • refs:
    • add an onChange handler (aren’t we using refs to avoid this?)
    • manipulate dom in onChange if it’s not a number
  • state
    • you already have an onChange handler
    • add an if statement, if it’s invalid do nothing
    • render is only called if it’s going to produce a different result

Eh, nevermind, the PM wants us to just do a red box-shadow if it’s invalid.

  • refs:
    • make onChange handler just call forceUpdate or something?
    • make render output based on… huh?
    • where do we get the value to validate in render?
    • manually manipulate an element’s className dom property?
    • I’m lost
    • rewrite without refs?
    • read from the dom in render if we’re mounted otherwise assume valid?
  • state:
    • remove the if statement
    • make render validate based on this.state

We need to give control back to the parent. The data is now in props and we need to react to changes.

  • refs:
    • implement componentDidMount, componentWillUpdate, and componentDidUpdate
    • manually diff the previous props
    • manipulate the dom with the minimal set of changes
    • hey! we’re implementing react in react…
    • there’s more, but my fingers hurt
  • state:
    • sed -e 's/this.state/this.props/' 's/handleChange/onChange/' -i form.js

People think refs are ‘easier’ than keeping it in state. This may be true for the first 20 minutes, it’s not true in my experience after that. Put your self in a position to say “Yeah, I’ll have it done in 5 minutes” rather than “Sure, I’ll just rewrite a few components”.


I’ve seen a few people cite the above answer as a reason to “never use refs” and I want to give my (as well as a few other React devs I’ve spoken to) opinion.

The “don’t use refs” sentiment is correct when talking about using them for component instances. Meaning, you shouldn’t use refs as a way to grab component instances and call methods on them. This is the incorrect way to use refs and is when refs go south quickly.

The correct (and very useful) way to use refs is when you’re using them to get some value from the DOM. For example, if you have an input field attaching a ref to that input then grabbing the value later through the ref is just fine. Without this way, you need to go through a fairly orchestrated process for keeping your input field up to date with either your local state or your flux store – which seems unnecessary.


TL;DR Generally speaking, refs go against React’s declarative philosophy, so you should use them as a last resort. Use state / props whenever possible.

To understand where yo use refs vs state / props, let’s look at some of the design principles that React follows.

Per React documentation about refs

Avoid using refs for anything that can be done declaratively.

Per React’s Design Principles about Escape Hatches

If some pattern that is useful for building apps is hard to express in a declarative way, we will provide an imperative API for it. (and they link to refs here)

Which means React’s team suggest to avoid refs and use state / props for anything that can be done in a reactive / declarative way.

@Tyler McGinnis has provided a very good answer, stating as well that

The correct (and very useful) way to use refs is when you’re using them to get some value from the DOM…

While you can do that, you’ll be working against React’s philosophy. If you have value in an input, it most certainly comes from state / props. To keep code consistent and predictable, you should stick to state / props there as well. I acknowledge the fact that refs sometimes gives you the quicker solution, so if you do a proof of concept, quick and dirty is acceptable.

This leaves us with several concrete use cases for refs

Managing focus, text selection, or media playback.
Triggering imperative animations.
Integrating with third-party DOM libraries.