Manually assigning instance to React.createRef()

[everdimension]

Hello!

Let's say I'm creating a component that needs to manage its underlying DOM node, but also it needs to be able to forward the ref prop using the React.forwardRef() feature.

I believe that in this case I need to manually pass the node to the forwarded ref.

Here's some code for a better explanation:

class MyComponent extends React.Component {
  constructor() {
    super();
    this.mount = this.mount.bind(this);
  }

  mount(n) {
    // MyComponent needs to have access to the DOM node
    this.el = n;

    // But also it needs to forward the ref:
    if (typeof this.props.forwardedRef === 'function') {
      this.props.forwardedRef(n);
    } else {
      // But what do I do in case of a `React.createRef()` instance?
      this.props.forwardRef.current = n; // is this okay?
    }
  }

  render() {
    return (
      <input
        type="text"
        ref={
         /* use both props.forwardedRef and this mount? */
         this.mount
        }
      />
    );
  }
}

export default React.forwardRef((props, ref) => (
  <MyComponent {...props} forwardedRef={ref} />
));

So as far as I understand it I need to manually assign the node to the current props of the React.createRef() object in case I'm dealing with it.

But i'm not sure if this will always be supported. It's not documented, at least.

Is it ok to do it like in the code above?

Also, I'm not sure if the this is an appropriate repo for this type of question. Should this issue be somewhere else or perhaps it'd be better on Stackoverflow?

[gaearon]

I don't think your solution would work correctly if the parent passed a different ref on an update, e.g. ref={someCondition ? ref1 : ref2}. So it's pretty fragile. You're also forgetting to clear it up on unmount so I think there might be a memory leak.

In general I'd recommend to rethink whether this is necessary. It's a pretty complicated pattern.

But if you really need it I think your solution could work if you also handle updates and unmounts and take into account that forwardedRef prop itself may change.

[gausie]

@gaearon what you're saying here makes complete sense but I've come across a situation for which I'm not certain how to proceed. I'm using a third party library that provides a contenteditable div and I'd like to be able to access the inner element for focusing. The library (very reasonably) creates its own ref to track internally. This, however, causes the problem described in this issue.

I want to write a PR but don't know how to proceed. Would it be to use an externally managed ref if it's passed in as a prop, and fall back to an internal ref otherwise?

[gausie]

(The library in question is https://github.com/lovasoa/react-contenteditable if you're interested in looking)

[nikolay-borzov]

I've faced a similar problem. I need to forward ref and add event listener at the same time. Use with caution.

const Button = forwardRef<HtmlButton, ButtonProps>((props, ref) => {
  const { children, onClick, title, ...buttonProps } = props;

  const buttonRef = useRef<HtmlButton>(null);

  useLayoutEffect(() => {
    if (ref) {
      if (isFunction(ref)) {
        ref(buttonRef.current);
      } else {
        (ref as any).current = buttonRef.current;
      }
    }
  }, [buttonRef]);

  useEffect(() => {
    const button = buttonRef.current!;

    if (onClick) {
      button.addEventListener('click', onClick);

      return () => {
        button.removeEventListener('click', onClick);
      };
    }
  }, [onClick]);

  return (
    <button
      ref={buttonRef}
      title={title}
      {...buttonProps)}>
      {children}
    </button>
  );
});

[everdimension]

@nikolay-borzov
Thanks, that looks like a valid approach!

@gaearon But the reason why I originally created the issue was that I was trying to point out that the docs seem to miss the info on how this should be handled and on how React.createRef() works in general.
I used to think it was some kind of magic box that existed specifically for dom node instances and component instances with a "public" current prop.

Turns out it's just a simple object that is expected to carry any value? Would be great to see that in the API docs :)