What is component-driven development and why to use it

9 min readMay 17, 2020

Out of curiosity, I have visited the websites of the most popular UI frameworks today to create web apps (Vue, React & Angular) and they were there: Starring… Components.

They are already extended among libraries as an important part of modern applications development and there is also a web component standard to make use of them with just vanilla javascript. We already know that using components is a great way of encapsulating and reusing styles and functionality.

Even if most of us have embraced the usage of components in our daily workflow, the best way of using them efficiently seems not very clear yet.

The developer and designer conversation

The front-end developer receives from the designer a new screen mockup to be implemented in the app.

A mockup that our teams need to make real

She quickly divides that design by components in her head (we all do it). In the developer's head…

Look at that list of items! I’ll extract it in its own component.
The items themselves don’t look complex. I think they’ll be generated by the list, no need for a new component for them.
Oh! That box is similar to what we have on the page we made last week. I think I can reuse the components I made then.

The developer is free to decide what’s the best way of organizing the code, but that process is personal and might change from one programmer to another.

On the other hand, the designer has created the mockup using previous assets he had. In the designer head…

I’ll divide the screen into two parts, the right and the left one.
All the items will be rows stacked at the left and everyone will have an edit link at the right.
At the right of the screen, I’ll use the card from the last week, but now we need that when clicking the title the card should expand to reveal some content.

As we can see, the designer is thinking in a really similar way than the developer. He is reusing assets the same way components are reused in the app code.

Even if this way of working has been making the app progress nicely so far, let’s have a close look at how the process of creating this new page went:

The designer created the mockup, the specification, and presented it to the developer.
Both talked about the screen and they agreed it can be built quickly because is similar to what has been done before.
The developer built a list of items. She didn’t have the “row” concept in mind, nor the component, but she could reuse some CSS classes from other screens.
After finding what classes she needed to reuse, the look of the list wasn’t exactly the same. She added some style fixes and she also needed to have those links at the right, so a couple of new CSS classes were added.
The “Box” at the right (the card for the designer) had already a component for it (it took a while to find it because of the name mismatch), so the developer just included it on the screen with the right content.
When the designer received the implementation to validate, he realized about the card not expanding after clicking the title, so he bounced the task back to the developer again.
The developer thought that the designer implicitly wanted the same behavior for the box than the last week. Just a misunderstanding. Adding the new behavior in the old component would need a refactor of it, so she decided to create a new component copying the logic in order to not having side effects and break the screen she made last week.
In that new “RevealingBox” component she added the revealing logic, reusing most of the styles from the Box component.
The designer validated the screen is working as expected and the work was done.

The new page was then deployed and the team was ready again to work in another task.

Communication breakdown

The screen was created as needed, but the process was far from optimal.

After finishing it, the designer wonders why the developer can’t make any task at the first try. The developer is also complaining to herself about having a designer that never reuse the exact same component twice, so she has to work a lot more than what she should.

There were multiple things that can be improved in the process:

The specification of the screen wasn’t accurate. The designer and the developer both thought that the implementation was going to be finished faster.
They were using different languages and that lead to different mental models that didn’t quite match. They don’t fully understand each other and the task bounced back and forward more than what is desirable.
The designer is kind of reusing assets, but he modifies them every time he creates a new screen. He works in the screens in an isolated way and he is not aware of how the developer tries to reuse the code. That makes the developer work more and the app have an inconsistent design.
The developer, instead of refactoring the code she has, tackles the small changes required by creating new components and adding more CSS classes that can hardly be reused again. She already had problems finding the needed pieces in the project and, as the number of files and classes grow, the app becomes more inefficient and difficult to maintain.

All those are symptoms of one problem: the communication between designers and developers is failing. It’s like if the developer was playing Tetris and the designer was throwing her pieces difficult to fit. Or brand new pieces that are not in the usual Tetris rules. And the developer is trying to fill the gaps with sand… I think it’s an awful example… Are we really playing Tetris?

As we saw before, both developers and designers use similar processes to reuse their previous work. They create in a very similar way but the tools they use are not exactly the same. What if they together could define a common visual language to work together and improve communication? That can be done efficiently by taking the components to the center of the development.

Components as a language tool

In component-based development, we are building UIs by creating small pieces of interface that are well specified and documented. Those small bits of UI are what we are going to call components. They can be used together to create more and more complex layout and functionality, and finally, to create new screens by composition.

A component can be defined as a self-contained unit of interface that handles the visuals (styles), the interaction (behavior) and the purpose (functionality) for a particular use case in an app. Components have the following properties:

They are reusable. They are self-contained and provide functionality that can be needed in multiple places of our UI. We need to create them with re-utilization in mind and enforce it over creating new components.
They are consistent. No matter where we use them, components need to look the same, behave in the same way and offer the same functionality defined in their specification.
They are configurable. Components might accept some parameters that customize the way they work. This way they are flexible enough to adapt them to slightly different situations without the need for coding again.

In a component-driven approach, we put the focus on how to create every part of a screen so they can work independently, but in a coordinated way in order to make the screen work as required. Even if our goal is to deliver the screen, we are thinking ahead: the components are made to be reused in the future.

Using the component-based approach

Our development team has read about component-based development from some blog and they are decided to give it a try! They want to rebuild the previous screen thinking about components first:

The developer has a look at the design, compare it with other designs she had received and decide to extract a couple of components: the list item and the right box.
After talking to the designer, they decided together to call those components ListItem and UserCard. They are starting to create a common language.
The designer needs to create mockups for those components individually. He recognizes similar patterns that are already used by the app, so he designs every one with their different variations.
Component designs arrive at the developer. She works in the implementation considering the different variations, so she decided that the component will allow some parameters in order to adapt them to the different use cases.
The designer validates the look and the behavior of the components and, if everything is ok, they are ready to build the screen.
The developer uses the components to build the screen resulting in a much smaller and simpler logic. She just adds some styles to stick the components together and sets them up with the needed configuration.
The designer validates the screen is working as expected and the work is done.

The screen can be deployed again.

Components the good parts

The screen was delivered and the result looks the same as the one before using the component-driven approach.

The process was quite different though. It has some benefits that are not only nice for the new screen, but also for new screens that might be developed in the future:

The screen is not just the only piece of software delivered, the result of the development was also two new components: ListItem and UserCard. From the point of view of the developer, they are 2 small independent modules that need to be required and configured in order to get the expected result instantly. From the point of view of the designer, he has 2 assets with their variations that can be dragged to new screen designs.
Since the components were created by the designer and the developer together, their communication has improved hugely. For the next screen, the designer might ask the developer to add the UserCard that reveals the content, knowing that the process will be fast and the result exactly what he expects. The development time is now much more predictable.
On the other hand, when the designer needs a new variation of the ListItem for some screen, he knows that it will require some extra development work. Component-based development makes designers be more aware of developers’ work.
When the designer wants to make changes to a component, he will need to design it individually, abstracting himself from any screen and that will force him to pay attention to the detail. Component driven design leads to apps that look polished because every single element has been thought carefully.
Following this approach, the developer works to encapsulate her code in small modules based on reusability. Those modules should be independent of the business logic, creating a great separation of concerns and making much simpler to create automatic tests for both parts of the code. Component-based development enforces a nice code organization.
Since components look and behave in the same way throughout the app, they lead to a consistent user experience without extra effort. Also, redesigning the UI is much simpler, because enhancements made to a component will take effect in every part of the app where that component is used.

What does it take to follow a component-based approach?

All the points above sound really good, but switching to component-based development is not easy.

First, developers and designers must be decided to take the step. It will change their “free way of working” to a more strict one. Their performance will decrease at the beginning, since they need to agree and create good definitions for the components, besides building the app’s screens with them. It’s like developing two products at the same time.

But once we have a good component gallery, our performance will boost hugely and a small team will be able to create new screens at a fast pace with a very maintainable base code.

The need for considering components as a communication tool is essential to maintain the component system. To do so, we need tools that help us to share and understand the available components, allowing other developers and designers to learn the language and what can be achieved with it.

I hope that this introduction has been enough to grasp the idea of how we can improve our UI placing the components at the center of the development. Stay tuned to keep learning about component-based development.

Thanks to getavataaars.com for the online tool to create the designer and developer characters. I have used screenshots from Tetris for Nintendo’s GameBoy and Not Tetris 2 games. The mockup image was created using moqups.com.

Don’t forget to follow @arqex to not to miss the following articles of the series.