mixins are fragile for a number of reasons:

1. The contract between a component and its mixins is implicit. The mixins often rely on certain methods being defined on the component, but there is no way to see that from the component’s definition.

2. As you use more mixins in a single component, they begin to clash. For example, if you use something like StoreMixin(SomeStore) and you add another StoreMixin(OtherStore), React will throw an exception because your component now has two versions of methods with the same names. Different mixins will also clash if they define the same state fields.

3. Mixins tend to add more state to your component whereas you should strive for less. You should read the excellent Why Flux Component is better than Flux Mixin essay by Andrew Clark on this topic.

4. Mixins complicate performance optimizations. If you define the shouldComponentUpdate method in your components (manually or via PureRenderMixin), you might have issues if some of the mixins need their own shouldComponentUpdate implementations to be taken into account. for example:

function StoreMixin(…stores) { var Mixin = { getInitialState() { return this.getStateFromStores(this.props); },

componentDidMount() {
  stores.forEach(store =>
    store.addChangeListener(this.handleStoresChanged)
  );

  this.setState(this.getStateFromStores(this.props));
},

componentWillUnmount() {
  stores.forEach(store =>
    store.removeChangeListener(this.handleStoresChanged)
  );
},

handleStoresChanged() {
  if (this.isMounted()) {
    this.setState(this.getStateFromStores(this.props));
  }
}   };

return Mixin; }