2

The procedure for sharing data between components in a child-parent relationship is well documented and dealt with straightforwardly in the React docs. What is less obvious is the accepted way of how one shares state and arbitrary data between components that do not share a child-parent relationship. Flux is offered as a solution, and in the past I have rolled my own pub/sub system, but still there seems a great divide among reactjs developers in this arena. RxJS has been offered as a solution, and many variants on the observer pattern, but I was wondering if there was a more canonical way of managing this issue particularly in larger application where components are less tightly bound.

sjt003
  • 2,407
  • 5
  • 24
  • 39

1 Answers1

1

My solution has generally been to pass a callback as a prop to components that will be accepting user input. The callback executes a state change in the parent, which propagates down. For instance:

UI = React.createClass({
  getInitialState() {
    return {
      text: ""
    };
  }

  hello(text) {
    this.setState({
      text: text
    });
  }

  render() {
    return (
      <div>
        <TextView content={this.state.text}>
        <Button onclick={() => this.hello("HELLO WORLD")}>
      </div>
    );
  }
});
// TextView and Button are left as an exercise to the reader

I like this because each parent component is still uniquely responsible for its content, and the child components don't intrusively know anything about each other; it's all callbacks. It admittedly may not scale very well to massive react apps, but I like that there isn't a global event dispatcher managing everything, making control flow hard to follow. In this example, the UI class will always be completely self-contained, and can be replicated as needed without any risk of name reuse.

Lucretiel
  • 3,145
  • 1
  • 24
  • 52
  • is this not still not a parent-child relationship? what if there were two ```UI``` "parent" components, both meant to stay in-sync, both with their own set of children? Could you update your example with that in mind? – sjt003 Feb 26 '16 at 20:22
  • @sjt003 well, in the example, it's the Button and the TextView that have the relationship. It's the parent's job to set up and facilitate that relationship. In your example, if you had two UI components that needed to communicate, you put them both under a parent that sets up the communication. I've updated the example with a Button and TextView that have a more direct relationship– the Button receives a callback that calls TextView's setText method directly. However, I generally find it preferable to move state higher and props lower in the graph, wherever possible. – Lucretiel Feb 26 '16 at 21:09
  • @sjt003 My philosophy when it comes to React is that everything visible should be managed in terms of props and state. If two distant components share some state and need to be kept in sync, then that state should live in their parent. Most React apps have a single top-level parent component where that state can go. Can you update your question with an example where two components are completely separate in a way that they aren't under a single parent? – Lucretiel Feb 26 '16 at 21:17