Although the principle of components is modularity and independence from each other, sometimes different components may share functionality and code. React provides mixins to handle this problem (primarily for creating the React component using the createReactClass).

Mixins are used to define methods that components using mixins are free to use (just as they are defined in components), so mixins are an extension of components that can also define “lifecycle” methods.

For example, a timer mixin:

var SetIntervalMixin = { componentWillMount: function() { this.intervals = []; }, setInterval: function() { this.intervals.push(setInterval.apply(null, arguments)); }, componentWillUnmount: function() { this.intervals.map(clearInterval); }}; var TickTock = React.createClass({ mixins: [SetIntervalMixin], // Use the mixin getInitialState: function() { return {seconds: 0}; }, componentDidMount: function() { this.setInterval(this.tick, 1000); // Call a method on the mixin }, tick: function() { this.setState({seconds: this.state.seconds + 1}); }, render: function() { return ( <p> React has been running for {this.state.seconds} seconds. </p> ); }}); React.render( <TickTock />, document.getElementById('example') );Copy the code

The power of React mixins is that if a component has multiple mixins that define the same lifecycle methods (for example, if several mixins want to do some cleanup when a component is destroyed), these lifecycle methods will all be invoked. When mixins are used, they are executed in the order in which they are defined, and then the corresponding methods on the component are called.

Components defined using ES6 classes no longer support mixins, Because components using a combination of Mixins scene can use this pattern to do (see Mixins Are Dead. Long Live Composition, zh-hans.reactjs.org/blog/2016/0…).

The use of Mixins in React is non-explicit and chaotic. Mixins can use the methods declared in React or vice versa.

For example, a mixin references state in a component. When the state changes, can you remember that the mixin also references state?Even assuming you find that state used in a mixin, how do you know about and modify another component that references that mixin?Or, when you think about tracking mixin methods mixed with components, the hierarchy of mixins nested is ♾ :You never know what happens when you add methods to a mixin, you might have naming conflicts with methods in a component, etc. To address these issues, React recommends HOC high-order components (functional programming patterns that wrap one component into another) :​

Here’s an example:

1. Create a wrapped component:2. Unlock 🔓 packaging method:3. Next, simply modify the List component:4. Finally:​

Advantages of HOC:

​

Components do not receive any intrusions; in HOC, components are decoupled from functionality. HOC can be applied to any component, and components can be wrapped around any HOC 📦, very flexible.

In addition, mixins apply object-oriented concepts, which have a stiff feel in JS; HOC is declarative, reflects the idea of functional programming, in line with the modern JS programming concept.

Problems with HOC:

  • Nested hell, meaningless nested

​

  • Don’t easily change the order in which HOC is nested

  • Props delivery problem

    During transmission, props may be processed by HOC on each layer without knowing what the other layer is doing, for example:

​

Hooks:

To solve the problem of reusing logic between components, it neither invades components as mixins do, nor scrambles the structure of components as HOC does. It can extract logic from components in a natural way.

Hooks replace Mixin and HOC in most cases.