Redux: What about refs?

Created on 27 Jun 2015  ·  8Comments  ·  Source: reduxjs/redux

If I use a <Connector> around some components that have a ref attribute, I can no longer access it via this.refs. I just refactored a bit to fix it -- I am guessing this is kind of in the vain of smart versus dumb components. Or am I missing something simple?

help wanted question

Most helpful comment

Sorry but I do not see how encouraging the use of 'findDOMNode' in such a trivial case can even be considered a solution. This is an anti-pattern! It's returns us to days of jquery where we need to access all element and know exactly the hierarchy of the nodes. Your docs rightfully read :

'findDOMNode() is an escape hatch... use of this escape hatch is discouraged because it pierces the component abstraction'

All 8 comments

smart versus dumb components

I think so yes, your _smart_ component with the Connector should just render _dumb_ components and pass the needed props to them.

@cymen you can use a ref callback for this :)

const decorator = (Base) => {
  return class {
    render() {
      return <Base {...this.props} />
    }
  }
}

@decorator
class Test {

  render () {
    return <div ref={this.props.refCallback}>my div</div>;
  }

}


class Wrapper {

  componentWillMount() {
    this.nestedRef = null;
  }

  componentDidMount() {
    console.log(React.findDOMNode(this.nestedRef));
  }

  setNestedRef = (ref) => {
    this.nestedRef = ref;
  }

  render() {
    return <Test refCallback={this.setNestedRef} />
  }
}

The above will log the div. Maybe this helps?

This uses a decorator, but It would probably just work as well if you passed a callback to your components which you nested inside Connector. Inside the callback you can then assign the ref back to your component.

Do you really need a nested ref?

If you just want to access the DOM node, you can do findDOMNode on the outer component and it will work just fine. (They will point to the same node.)

If you want to call methods, consider using props as the declarative interface instead. See also https://github.com/jsstyles/react-jss/issues/15 for a discussion about this.

Finally, if you're _certain_ you need a ref, yeah, you can grab a nested ref like @johanneslumpe suggested in https://github.com/gaearon/redux/issues/183#issuecomment-115988937.

Closing, please let me know if something isn't clear.

Sorry but I do not see how encouraging the use of 'findDOMNode' in such a trivial case can even be considered a solution. This is an anti-pattern! It's returns us to days of jquery where we need to access all element and know exactly the hierarchy of the nodes. Your docs rightfully read :

'findDOMNode() is an escape hatch... use of this escape hatch is discouraged because it pierces the component abstraction'

Sorry but I do not see how encouraging the use of 'findDOMNode' in such a trivial case can even be considered a solution. This is an anti-pattern! It's returns us to days of jquery where we need to access all element and know exactly the hierarchy of the nodes.

I’m not sure what you mean. I’m saying that, if you need a reference to the rendered node (for example, to calculate its offset and size), you can use findDOMNode(this). I’m not suggesting you to “go deeper” or mutate it.

That said if you’re not happy with this, just use ref callback props as suggested above.

I don't think we should depend on findDOMNode(this) seeing as it's not applicable to React-Native.

@xvalentino findDOMNode is not necessary. See the bits related to getWrappedInstance in the API docs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

LeeDownshift picture LeeDownshift  ·  21Comments

justjacksonn picture justjacksonn  ·  13Comments

genert picture genert  ·  9Comments

ernieturner picture ernieturner  ·  19Comments

richb-hanover picture richb-hanover  ·  4Comments