Let’s start with an example: you developed a component for a list of images in an album; each image has a “X” button to delete it.

This is the most intuitive way to implement the component:

The component reacts to the user’s click by deleting the corresponding image. It notifies its parent of the change by emitting an event, this is a good practice because it allows us to control the API from the root component, without having to spread API calls everywhere.

In principle there is nothing special about this implementation, it is already pretty “reusable”, because it’s quite simple. But I would like to show how you can change it in order to make it even more reusable, and I’ll start by asking myself the question about change detection: upon which circumstances does this component change?

It changes when the parent updates the list of images

It changes when the user clicks on “X” on one of the images

More generally, the component’s status depends on both the parent and an external factor (the user). So, from a change detection perspective, it’s not possible to optimise this component by detaching it from the change detection tree.

Generally, in an application, there will be a number of “dumb” components, that don’t have any power in determining their own internal status, plus a number of “interactive” components, that react to the user’s actions and change their internal status. The first components are the ones that can be detached from change detection by using ChangeDetectionStrategy.OnPush.

Good practice is to try and maximise the amount of “dumb” components, so that change detection can be optimised at its most to make our application really fast. But how does this relate to reusability?

In my opinion, it’s easier to reuse a “dumb” component because it focusses on a single thing and it doesn’t “decide” anything.

A dumb component is nothing else than a brick in your application’s wall, you can take it, control its appearance from outside, and place it anywhere you like with little or no effort.

Let’s try to turn the component above into a “dumb” component. It will be as easy as commenting out a single line

I removed unnecessary things like imports and template, to focus on the line I commented: line 12.

The component still notifies its parent about the user’s click, but it doesn’t actually delete anything. It’s the parent component who has the responsibility to delete the element.

Now, our component only depends upon the parent’s status, not on the user. It can be detached by change detection using the OnPush strategy (provided that we mark the input array as “immutable”). And it’s more reusable too.

Let’s imagine that we implemented image deletion in the component’s parent, like this

Let’s say now that the designer wants the same list implemented in some other page, but in that case he wants you to popup an alert before confirming the deletion: thanks to the fact that the component “images-list” doesn’t determine its internal status, and it’s fully controlled by the parent, you can reuse it immediately without changing even one line inside it.

This is how it would look like to call the same component inside a different context:

Let’s now imagine that the designer turns crazy, and decides that in a third context he wants the application to delete two images, not one, to punish the user for wanting to delete something.

The good new is that we don’t have to turn crazy along with him, because we can still reuse the original component without changing anything in it:

We achieved our goal: developing as many dumb components as we can, besides the obvious benefits in terms of change detection optimisation, we can actually reuse them in extreme contexts that were unthinkable when we first designed them.