Re-rendering an app using ReactDOM.render() rather than within its container component -- anti-pattern?
<p>I have a single object state-driven application whose state dispatch/subscribe logic is to be kept separate from the React 'flow' (i.e. no helpers like React-Redux bindings).</p>

<p>When the state changes, my app re-renders.</p>

<p>Is there any difference between the following two implementations, or any anti-pattern concerns? (sorry to anyone upset I'm not using JSX)</p>

<pre><code>var myElementClass = React.createClass(
   render : function() {
      //make use of this.props.state...
   }
);

var myAppContainerComponent = React.createElement(
  myElementClass,
  {state : dataStore.getState()}
);

dataStore.onChange(function(){
  ReactDOM.render(myAppContainerComponent, someDOMContainer);
});
</code></pre>

<p>vs...</p>

<pre><code>var myElementClass = React.createClass(
   componentDidMount : function() {
      var self = this;
      this.props.store.onChange(function(){
         self.setState(self.props.store.getState());
      });
   },
   render : function() {
      //make use of this.state...
   }
);

var myAppContainerComponent = React.createElement(
   myElementClass,
   {store : dataStore}
);

ReactDOM.render(myAppContainerComponent, someDOMContainer);
</code></pre>

<p>The first forces the app-wide re-render from 'outside', i.e. using ReactDOM. The second does the same thing within the container app.</p>

<p>I've done some performance tests and don't actually see a difference. Will I run in to issues down the road? Is hitting ReactDOM.render() many times an issue?</p>

<p>I know some people will comment that both ways are possibly expensive as they're each re-rendering the whole app (isn't that what React is for ;) ), but that's out of scope of this question.</p>