Published in


Components beyond reuse

We are living times where the Model/View/Controller concept is getting more and more obsolete making Component-Based approach the new standard to develop web applications now.

However, as well as Component-based has become a so popular concept, I still see a lot of developers understanding components in a surprisingly weird way.

Which kind of weirdness? (you might be thinking)

a) In the first case, I see developers considering a View as a component. So, the “component” is, in fact, a huge piece of code extremely coupled with its context offering zero flexibility and reuse.

b) In the second one, I see developers not considering components with no behavior as components. They think markup encapsulation is not worth it. The result is a markup code replication and, consequently, pain at the moment you need to make changes in something that should be in one place only.

First of all, I would like to share the concept of what I believe to be a component. These are some wise words written by Derick Bailey in one of his blog posts:

That said, I’ll show you two other benefits beyond reuse which most of the people might not get at first glance:

Small Responsibilities

When you encapsulate a small part of a View in an independent component, you are removing responsibilities from a huge piece of code that would be controlling the whole View. Imagine a website showing some Weather Card on its homepage. On the same homepage you can see a bar showing some current stock prices, a logo, a carousel containing some breaking news, and a card with real-time currency rates.

The less you concentrate responsibilities, more you make it flexible.

Why should be the entire homepage controlled by one piece of code only? That doesn’t make sense. The more you concentrate responsibility, less you enjoy the power of flexibility.


Now, suppose the product team has decided to move the Weather Card to another View. You have in your hands the job of moving it from one View to another. So easy, right?

How easy would be moving a component from one view to another?

Maybe. It depends on how you have organized the code distributed along the homepage. If the homepage is controlled by one piece of code only, you will probably need to make a delicate surgery on this. You have to remove the portion of code related to the Weather Card from those huge homepage files. Then, you will need to accommodate this exact same portion of code into the other View’s files.

That’s done, ok? Not yet.

The homepage tests will not pass anymore. You have just changed it. The same can happen to the other View tests, once you have also changed that. In a Component-Based approach, Weather Card is a component. It encapsulates all its markup, style, behavior and tests. So, all you have to do is moving a simple HTML tag from one View to the other one.

Small responsibilities avoid delicate surgeries.

As you can see, reuse is actually a consequence of the above two benefits. When you break any View in several small pieces of code (small responsibilities), you make it so easy to move them from a context to another (flexibility) or, consequently, reuse them in any other View.

Are you struggling to configure and use StorybookJS? You have an alternative. It’s Pitsby. No rules. No loaders. No regex. Ship your docs with a couple of super simple declarations.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store