The obsession with reusable React components has led to over-engineering, complexity and unmaintainable code. Time for a new mindset.

The New Stack is a publication covering trends and technologies in cloud-native development, DevOps, and software delivery. Developers can learn about containerization, Kubernetes, and cloud computing, as well as explore topics such as microservices architecture, serverless computing, and continuous integration/continuous delivery (CI/CD) pipelines.

The New Stack

The pursuit of reusable React components has created over-engineered codebases filled with complex abstractions and prop-heavy components that are harder to maintain than simpler alternatives. The DRY principle, when applied dogmatically, leads to premature abstraction and components like Button.jsx that try to handle every use case with dozens of props and conditionals. Intentional code duplication is often more pragmatic than forced reuse, as it preserves clarity and allows code to evolve independently. The solution is adopting a post-reuse mindset that values simple, self-contained, context-aware components over universal abstractions, recognizing that the best component is one you can understand instantly rather than one you can use everywhere.

The React Component Pyramid Scheme: An Over-Engineering Crisis

When the DRY Principle Leads to Complexity

Adopting a Post-Reuse Mindset for React Architecture

I feel like this also comes down to a common misunderstanding of what the DRY principle intended. In Andy Hunt and Dave Thomas’ “The Pragmatic Programmer”, the principle states that your shouldn’t repeat knowledge (i.e. single source of truth); repeating code is permissible and even encouraged if it serves a distinct purpose. Instead, we’ve (myself included) taken it to the illogical extreme where any duplication is considered bad.
Also, Sandi Metz: “Duplication is cheaper than the wrong abstraction.”

These are just amateur-built components and codebases.
Every senior knows that stuffing components with more props does not equal smarter/more capable/better components. The way is to decouple-decouple-decouple. The pyramid needs to be wrappers and not props-heavy components.

Thx for the read. Although I haven’t worked as a full-stack developer for a long time, it didn’t stop me from enjoying the article, as it contains a universal message.

For me, what works best is the combination of both, sometimes prop heavy component is better for modularity when reuse of the component is heavy, other times using a self contained component is better. It all depends on the problem at hand.