Share ref with multiple ref handlers

[joaovieira]

Before React 16.3 we were able to proxy the same element ref to multiple listeners, for example, to grab hold of the element for internal purposes and also expose it publicly, like so:

class MyComponent extends Component {
  attachRef = el => {
    this.buttonEl = el;
    this.props.buttonRef(el);
  }

  // Do something with `this.buttonEl`

  render () {
    return <button ref={this.attachRef}>Button</button>;
  }
}

After React 16.3 this is more complicated as the ref prop can be a function or an object:

class MyComponent extends Component {
  buttonRef = React.createRef();

  attachRef = el => {
    this.buttonRef.current = el;
    
    if (typeof this.props.inputRef === 'function') {
      this.props.inputRef(el);
    } else {
      this.props.inputRef.current = el;
    }
  }

  // Do something with `this.buttonRef.current`

  render () {
    return <button ref={this.attachRef}>Button</button>;
  }
}

First, is this the right approach?

And if so, Typescript types say:

interface RefObject<T> {
  readonly current: T | null;
}

Which prevents us from assigning to current. Shouldn't it not be readonly?

[gaearon]

The approach you're suggesting should work. Yeah, it's more complicated. But we also don't encourage often doing this as it breaks encapsulation.

The property is usually read-only in the way it's currently used, but in your case it's fair to want to write to it. It's possible that we'll ask to change that type to be writeable in the future. (We don't maintain the typings ourselves.)

[luixo]

@gaearon
Is there any update on writeability of the current?
The problem of composing the refs is still relevant.
If the property should be writeable - I need you to confirm that - I can open a PR in typings repo.
But it looks for me as it should not be.
Maybe it should be allowed to pass an array of RefObjects to ref property of the element?

[joaovieira]

Just linked to a real use case:

researchgate/react-intersection-observer#46
https://github.com/researchgate/react-intersection-observer/blob/master/src/IntersectionObserver.js#L107

[gaearon]

If someone can't find a workaround for their findDOMNode use case please file a new issue and succinctly describe your use case. Preferably with an example. Thanks!

[ludvigalden]

Just wrote this general ref-"merger" or "resolver" accepting as many refs as you'd like. Added typings as well.

@Gearon According to your previous comment, doing it this way would have no negative effects, right?

export const mergeRefs = <T>(...refs: Array<Ref<T>>) => (ref: T) => {
	refs.forEach((resolvableRef) => {
		if (typeof resolvableRef === "function") {
			resolvableRef(ref);
		} else {
			(resolvableRef as any).current = ref;
		}
	});
};

[ngbrown]

@luddzo in some scenarios, when mergeRefs is called as part of the render, your implementation can make a DOM element repeatedly unload and load because the returned function is a new object on every call.

I was using react-measure, there may be some weird ordering going on, but to fix it, I had to memorize the returned function so it wasn't always new.

[pronebird]

@ngbrown the same principle applies for everything in React, changing props triggers an update.

[voliva]

This is particularly useful for hooks now, because you might have two pieces of encapsulated logic that they should work toghether.

For instance, let's say we have two hooks:

• useHeight(): [height: number, ref: Ref<HTMLElement>] => whenever ref mounts, it gets the height of that element, and listens to resize events that updates height.
• useScrollY(): [scrollY: number, ref: Ref<HTMLElement>] => whenever ref mounts, it gets the current scroll position of the element, and listens to scroll events that updates the scrollY.

In this use case, we need to pass those refs to the same element, so we need a way of combining them.