Components in any JS stack are fundamentally required for making your code reusable and scalable. The components you build can be typically broken into two types: smart and dumb. Smart components are pretty straightforward to understand. They hold, or have direct access to, business logic and manage state information. So realistically, the bulk of what your application does is directed from smart components. Dumb components, on the other hand, hold no logic and aren’t aware of anything that isn’t passed down to them as a prop.
In contrast, dumb components may seem simple and boring. However, there is much more to them and that is what we’re going over in this article.
The most obvious benefit of dumb components is code abstraction. By this, I’m referring to the ability to place a section of code outside of your smart component into dumb components. This is great because it allows us to keep our code intentional and gives us a clear separation of logic and presentation when need be. In addition, we won’t have largely overpopulated files. Lines 100+ in most cases.
Efficient Data Usage
As we mentioned in our light summary of dumb components, their only source of data comes directly from their parent. This is great because it limits the access to your application’s data layer to only areas in your codebase that need it. Or in other words, the levels of the application that are appropriately high enough to deserve access are the only ones that have it.
For example, look at a child and parent component that both have direct access to a value in the global data layer. Keeping things simple, let’s just say that both have aspects inside them where they require it to display or calculate for what they do or present. When that value updates, it triggers two separate events in both components. That’s not the best use of resources and lifecycle events. A more efficient approach would be to do all the logic in the parent and pass down the end result.
Clear Presentation Layer
Taking a step further ahead of code abstraction, the division between business logic-focused smart components and dumb components creates another benefit. This is that your collection of dumb components create a presentation layer. The clean separation for business and presentation layers is important for scalability and allows a large group of engineers to easily collaborate.
For example, imagine the scenario of you managing a team of 10 engineers in one repository. Amongst the team, they are grouped together into varying size task forces to accomplish different initiatives. Adding another wrinkle into the equation, the initiatives between the task forces are split between infrastructure and product.
Well, without solid code abstraction and a clear presentation layer everyone will collide and have conflicts. When you do, it makes it easier to divide tasks and work at the same time with minimal disruption. That is the goal!
Dumb components are much more important to your codebase than those with less experience realize. They allow for easier collaboration, cleaner architecture, and efficient use of memory. In truth, without them properly defined a codebase becomes a mess and almost impossible to properly ship anything without an overly complicated process. So always keep that in mind when building out your applications and outlining your architecture.