dom_ref_forwarding_alternatives_before_16.3.md

React 16.2 and earlier doesn't yet support ref forwarding. If you need to expose a DOM ref to components above and can't migrate to React 16.3+ yet, you can use the following approach instead.

Expose a special prop on the child. This prop can be named anything other than ref (e.g. inputRef). The child component can then forward the prop to the DOM node as a ref attribute. This lets the parent pass its ref to the child's DOM node through the component in the middle.

This works both for classes and for functional components.

function CustomTextInput(props) {
  return (
    <div>
      <input ref={props.inputRef} />
    </div>
  );
}

class Parent extends React.Component {
  constructor(props) {
    super(props);
    this.inputElement = React.createRef();
  }
  render() {
    return (
      <CustomTextInput inputRef={this.inputElement} />
    );
  }
}

In the example above, Parent passes its class property this.inputElement as an inputRef prop to the CustomTextInput, and the CustomTextInput passes the same ref as a special ref attribute to the <input>. As a result, this.inputElement.current in Parent will be set to the DOM node corresponding to the <input> element in the CustomTextInput.

Note that the name of the inputRef prop in the above example has no special meaning, as it is a regular component prop. However, using the ref attribute on the <input> itself is important, as it tells React to attach a ref to its DOM node.

This works even though CustomTextInput is a functional component. Unlike the special ref attribute which can only be specified for DOM elements and for class components, there are no restrictions on regular component props like inputRef.

Another benefit of this pattern is that it works several components deep. For example, imagine Parent didn't need that DOM node, but a component that rendered Parent (let's call it Grandparent) needed access to it. Then we could let the Grandparent specify the inputRef prop to the Parent, and let Parent "forward" it to the CustomTextInput:

function CustomTextInput(props) {
  return (
    <div>
      <input ref={props.inputRef} />
    </div>
  );
}

function Parent(props) {
  return (
    <div>
      My input: <CustomTextInput inputRef={props.inputRef} />
    </div>
  );
}

class Grandparent extends React.Component {
  constructor(props) {
    super(props);
    this.inputElement = React.createRef();
  }
  render() {
    return (
      <Parent inputRef={this.inputElement} />
    );
  }
}

Here, the ref this.inputElement is first specified by Grandparent. It is passed to the Parent as a regular prop called inputRef, and the Parent passes it to the CustomTextInput as a prop too. Finally, the CustomTextInput reads the inputRef prop and attaches the passed ref as a ref attribute to the <input>. As a result, this.inputElement.current in Grandparent will be set to the DOM node corresponding to the <input> element in the CustomTextInput.

Thanks @amirHossein-Ebrahimi ! That answer seems to make the case against React.forwardRef, though, not for it. The only points it mentions in favor of forwardRef are:

• uniform access API for DOM nodes, functional and class components
• ref attribute does not bloat your props API, e.g. if you provide types with TypeScript

They seem really weak for me. I just feel silly that I've been using forwardRef for a long time without considering this simple alternative. Like, if these are the only thing sin favor of forwardRef, I won't use it again 😅

I have seen performance hit when using forwardRef (even with extreme memoization) so I stick to props custom ref
you can read more about it here facebook/react#13456

Many of you are discounting the benefits of using forwardRef; having a consistent predictable api. If I'm using a 3rd party library that needs a ref to my components, it may be simply expecting that it can supply a ref prop to my components. Using inputRef or some other prop to pass the ref on, the 3rd party lib wont get a ref to the underlying dom node. There is only 1 legitimate case IMO not to use forwardRef and that is if you are using typescript and you need to add a generic to your component that uses forwardRef. It's not impossible, its just a pain in the ass, and the above can work. Problem is it then falls apart for the reasons I explained.