Component design patterns in Angular

Smart & Dumb Components (Containers/Presentation components)

Designing, we often hear this word about architecting or designing solutions effectively & how important it is to have an application to be architected right in order to provide scalability & reusability.

As we are aware that angular is component oriented & in the world of angular, components are one of the critical entities to achieve reusability. But a very common mistake as a beginner most of us would have made is how much of responsibility can a component take. Let us try to understand from the below snippet.

Here we have a component designed considering the factor of reusability, i have a component which was solely designed to display a single product. If this component can display one product perfectly we can possibly reuse it to display maybe multiple products too.

But, wait…

what’s the problem with this component it all seems to do it right.

lets take a one more look at the code. (hint : constructor)

yes, the constructor has the product data. Now let us assume that the data comes from a server thru an ajax call, so arguably we can get any product data & display that.

The core problem here is maybe today we implement the logic inside our component to fetch the product information & we also implement the logic to add the data into the cart it works all fine.

What if, later the client comes back with a new request(sighs), let me help you with a client feature request scenario.

1. Initially client came to us stating he only wants the data to be added into the cart on event of button click.
2. later, we have a new request where the client states the same component will be used in a different place but on click of add to cart, it should add into cart but as well place it in wishlist of user (dont know why but he wants it).

Somehow, we feel the need to incorporate this in our existing system. We write a condition to handle this use case & there we’re both are satisfied. But are we sure this will be the last of this component that client can ask for. What if, he comes back with another few conditions for the same. Now we have tons of conditions to be loaded into our existing component logic to handle all the use cases.

So does this make your component reusable in actual!!

Nope, we’re just burdening are component with more responsibility & just making our life’s harder by doing so, as maintaining this will always be a challenge.

In event of designing components effectively, it always incorporates a thoughtful process & one simple rule. “One component One responsibility” (psst… its the single responsibility principle)

Let each guy do one task & make him do it as good as he can. In component designing you ideally construct 2 types of component

1. Smart/container component : This component only focuses on logical tasks, like fetching data from the server or any decision making.
2. Dumb/presentation component : This component targets only on the presentation aspect

Yes, the product component we have created was actually a dumb component. Why, because it was designed to display the product not take the load of fetching the data from server or deciding what needs to be done when you click on add to cart. So what happens in tactical flow now, your component hierarchy frames up as below

— SMART (Parent)

— — — DUMB (Child)

You will have a parent-child relationship in the form of smart & dumb.

1. The smart goes to the server fetches data & makes all the decisions
2. The child receives the information or notifies the parent about any activity

Something as below.

Here’s what the refactored version looks like, what we can see now is product component no longer knows about what data it is going to display nor is it aware of what happens when add to cart is clicked.

1. component takes the product data as an input
2. provides notification on event of add to cart button click

what does this mean to us now, the product is unaware of anything but does the task of display perfectly. Since, this guy receives the info the consumer in our case from product-list(smart component). The smart component takes in the responsibility of which data the product is going to display or what will happen on event of button click.

So what does this smart/dumb combo allow us to do. Since, the dumb is unaware of what happens with its data the consumer can decide anything. Let’s take it this way, in a real world scenario a child should never hide anything from the parent, it should always take inputs from the parent & give notifications to parent on any event/activity.

The fact the anyone can now use product component & have differential implementation on what actually happens on the button click makes it completely reusable in your application across scenarios.

Sounds Cool right !!

Thanks for reading, Cheers :)