React: Mixins Considered Harmful

I think one of the biggest misunderstandings about JS and a large portion of the community complaining about "churn rate", is that JS does not have a churn problem, it has an inexperienced developer problem. Which is not to say that is a bad thing, JS/web is the first language for MANY programmers now.

When you get stuck on learning this framework vs that framework, or a antipatterns within a framework and "complexity" being added to a framework, take a look back and understand the WHY first.

Many ideas and the fundamental design of React are not new. Infact, they are very old, even before there was such thing as the internet. Functional programming patterns, also very old. Immutability, a very old concept. Composing rather than inheriting, old concept. Eliminating all side effects (through immutability and composition), very old concept.

The idea of a "higher order component", is not new, nor does it have any direct relation to React. It is a design pattern. This article is simply teaching you a design pattern that aligns with the design patterns React was built upon and works very well. Instead of complaining about React and "added complexity", I encourage you again, to ask why. Learn why this blog post, from the React core team, recommends doing it this way. It is in no way a requirement. React is just a tool. It is just Javascript. It is just programming. Welcome to the development world.

Also, understand the problems you are trying to solve. Facebook uses these design patterns because they have thousands of components at a massive scale. The majority of users will not be working on something of that size. Don't feel like you have to use everything that comes out and is available in the React ecosystem. Infact, I would urge you, never start using something UNTIL you come across a problem and need to find a solution. It is a common thing for inexperienced developers to feel the need to incorporate everything they have read about, when they are using them to "solve" problems they don't understand, nor even have. This applies to problem solving in general, not just React, not just programming.

TL;DR Understand WHY something is used in the way it is before throwing it out as "too complex". Don't solve problems you do not have, until you need to actually solve them. If you do use a pattern/tool/etc., understand the WHY. (Don't use Higher Order Components or redux if you have not had the need for them and do not understand the problem they solve.) Also understand that many design patterns coming to JS are not a result of JS churn, they have been around a long time and have a very good reason for existing. JS churn is not real, it is a misunderstanding of using a solution in a world that has many solutions available.

Because we already did embrace it, and we found that it was a mistake.

I believe that the article addresses why mixins didn’t scale well in our React codebases. We have written a ton of React code and wanted to share our experience.

It seems quite normal to me that our experience might not match experience of other JavaScript users. React offers a component model based on functional composition solution that was not quite common in JavaScript until very recently. Paradigms are much more fundamental than languages. We found that, with React’s paradigm, in our experience, mixins were unnecessary. For sure, your mileage may vary.

>most of the issues mentioned exist everywhere with JavaScript because, well, it's a dynamic language

You might not believe me, but these issues had much less of an impact on us with React’s component model. And even less so after we started using gradual static typing with Flow (http://flowtype.org/).

>I would suspect many of the issues lie outside of using mixins and more of how everything is architected but without seeing their codebase I don't actually know that.

I have been employed by Facebook for just a few months. I have written a few relatively complex React apps myself before. I didn’t see much of a difference between the mixins I wrote previously and mixins I saw at Facebook. In my view, both mixins I wrote and mixins I saw at Facebook introduced similar problems to the respective codebases.

It’s great that you know how to use mixins without shooting yourself in the foot. This is a rare gift in my experience. Most people (like me) will overuse them because they’re too powerful. On the other hand, components are limiting enough that even people like me can write code that is easy to maintain in the long term.

>The syntax without mixins just seems overly complex. I mean sure it's still simple but more complicated than before.

What syntax are you referring to? I don’t think there was any new syntax in the article. The only challenging part might be the idea of a higher-order component, but this is not even a React feature. It’s the way JavaScript works: you can create functions and pass arguments to them. It turns out that we could solve one of the use cases for mixins with vanilla JavaScript constructs and without the need for a complex mixin system.

I think you might be missing the point that we have seen quite a bit of React apps being developed. Some of the things we say might be counter-intuitive but they come from Facebook’s extensive experience of using React (more than 20,000 components). So when we’re saying something, it is not theoretical or out of spite. We are trying to share our experience with you, in the hope that you might find it useful not to repeat our mistakes.

It was not migrating the logic from the component. The example was about getting rid of a mixin. I think the article even mentions the opposite:

“If there is just one component subscribed to this data source, it is fine to embed the subscription logic right into the component. Avoid premature abstractions.

>the problem is that everyone else seems to rely on these tools and see them as an integral part of the "React experience"

Who is “everyone else”? I think you might be listening to a vocal bubble. As Redux author, I can tell you that it is not in any way essential to React. Some people use it, many people don’t. Solve your problems, don’t just follow what you see in flashy magazines.

>I think it would be great if there could be a bit more emphasis on "keeping it simple" in the React tutorials

I think this is exactly what React tutorials do:

* https://facebook.github.io/react/docs/tutorial.html

* https://facebook.github.io/react/docs/thinking-in-react.html

We can’t really control what third party tutorials write.

Higher-order functions are extremely common and useful in all functional languages. In fact many people gave us the exact opposite feedback: React taught them many functional programming patterns that they later used elsewhere, both with and without JavaScript, not to say React.

>I wouldn't go so far as to say, never use mixins in JavaScript, for example.

This is not what the article says. There is a paragraph clarifying this specific point, as the sibling comment points out. And the article is sprinkled with “in React codebases” and “in our experience” for this very reason.

>Sure, but it seems to be a trade off of complexity for user experience.

I don’t understand what you mean. In most cases you don’t need to do anything, React is fast. When you have an especially complex tree (not very common), you can add three lines to a few files, and React is even faster. It is a tradeoff, and it is a pretty damn good tradeoff in my experience working on React apps. What am I missing?