Using HOCs instead

I believe that you can easily translate the preceding use case into HOC. Let's do this together, and then we will discuss why HOCs are better:

// Chapter 2_View patterns/ Example 13/ App.js
const withLogger = (ComponentToEnrich, logText) =>
    class WithLogger extends React.Component {
        componentDidMount = () => console.log(
            logText || 'Component has been rendered successfully!'
        );

        render = () => <ComponentToEnrich {...this.props} />;
    };

const App = () => (
    <View style={styles.container}>
        <Text>Some text in a component with mixin.</Text>
    </View>
);

export default withLogger(withLogger(App), 'Some other log msg');

The first thing you will immediately spot is that HOCs stack on top of each other. HOCs literally compose with each other. This is much more flexible and protects you from name clashes that may happen when using Mixins. React developers mention the handleChange function as a problematic example:

Additionally, Mixins may lead to adding more and more state. Looking at the preceding examples, it may appear that HOCs do the same, but in fact, shouldn't. This is an issue that I struggle with in the React ecosystem. It gives you a lot of power and you may not realize that the patterns you begin to use are so-so. To me, stateful components should be rare, and so should stateful HOCs. In this book, I will teach you how to avoid using state objects in favor of a better solution that decouples state from your components as much as possible. We will learn about this further in Chapter 5, Store Patterns.