By now it’s no secret that the recommended approach for building websites is using components. Component-driven development is breaking entire web pages into smaller pieces and working with those pieces individually. As Stephen Hay puts it in his talk on Responsive Design Workflow, “We’re not designing pages, we’re designing systems of components."
Components present several advantages over traditional top-to-bottom development. To mention a few: better and cleaner code, fewer regressions, improved collaboration and reusable components.
The process of creating components
1. Rethink design:
Component driven development begins at design. Being able to identify potential issues or opportunities during the design process pays off during development.
2. Naming conventions:
Naming components are something your entire team should agree on. The name of a component will affect markup, styles and the overall discussions when communicating with your team or stakeholders. Component names should be unique, descriptive and use standard naming conventions. In some cases, however, a client may already have a naming convention in place that works for them, in such a case adhering to it may be the best way to go as this will make things easier for the client.
3. Identifying patterns:
If a site element is repeated—even if it looks or behaves differently—that’s a clue to make a component out of it. In addition, look for opportunities to create new patterns by finding ways to make components reusable to streamline the development process.
4. Markup and styles considerations:
Markup and naming conventions go hand in hand. But there is more to markup than semantics. Having a clear picture of how a component looks/feels in mobile, tablet, desktop, and other devices will play a big factor on how your markup should be structured. Well-written markup allows for natural and fluid transition of content between breakpoints. Content should flow naturally for a better user experience and its flow should not be restricted.
Now that we have some pointers on how to build components from either a full site, a site’s page, or a page’s section, let’s do that.
The example below is is a page section, which for the purpose of this example we’ll call “breaker”. You have probably seen something like this before since is a current trend in web design.
Breaker image above shows many elements that lend themselves to be individual components.
Breaker image above for mobile.
Breaking it Down
We have designed our breaker so it easily adapts to any device size. This was a conscious decision during design.
Breaking a website into smaller pieces allows us to simplify a complex problem. Often times is overwhelming to look at a website as a whole because there may be too much going on, breaking things down lets us focus our attention in more manageable pieces.
Let’s start by identifying the elements that make up our breaker, and document useful information for our build process.
Note: Item numbers represent the number labels on the design above.
| Item# | Design Item | Type | Component Name |
| 1 | Image | Image | Hero |
| 2 | Label | Text | Eyebrow |
| 3 | Title | Text | Heading |
| 4 | Text block | Text | Body Text |
| 5 | Box | Component | Card |
| Icon | Image | Icon | |
| Title | Text | Heading | |
| Text Block | Text | Body |
One thing to notice is that our design shows 3 boxes (cards). Each of them has the same type of elements (icon, title, text block). This is a great example of patterns we can leverage. We will build one Card component and will repeat it 3 times to match our design. In addition, since we already have title and text box components as part of the top portion of the breaker, we can also reuse those in the Card component.
So far if we go back to 'the process of creating components”' section, we have completed 3 out of the 4 steps (Design, Naming, and Patterns). The last step is writing our markup and styles. Let’s do that now.
We’ll start with markup for the individual components, then we will combine the components to build the breaker.
Note: Item numbers represent the number labels on the design above.
1 <img class=”hero [ class ]” src=”image.jpg” alt=”Alt text”>
2 <p class=”eyebrow [ class ]”>Drupal Development</p>
3 <h2 class=”component__heading [ class ]”>Content Creation Workflow</h2>
4 <p class=”[ class ]”>Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Aenean lacinia bibendum nulla sed consectetur. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus.</p>
5 <article class=”card [ class ]”>
<span class=”card__icon”>card.svg</span>
<h3 class=”card__heading”>Truly responsive content</h3><p class=”card__teaser”>Donec id elit non mi porta gravida at eget metus. Cras mattis consectetur purus sit amet fermentum.</p>
</article>Let’s go over what we’ve done here. You’ll notice “[ class ]” in some of the components. This is a css class placeholder. Some components can use a universal css class such as “eyebrow”, “icon” and others. However, to ensure proper semantics and more manageable code, some components need to inherit names of the components they are part of. For example, the component with class .component__heading, when used within the breaker, should also have the class “breaker__heading”. Same applies to other subcomponents such as Card. In addition to the class .card, the component will have breaker__card. The “[ class ]” placeholder will allow us to apply those modifier classes when we combine all the components.
The universal classes on a component are used to apply global styles. No matter where a component is used, these styles will still apply. The more specific class is used to apply unique styles or variations to a component.
It’s important to note we use BEM naming convention for our css classes. This allows for better semantics in our markup as well as it provides a namespace for each component.
Building the breaker
Now that we have named all the pieces in our design, let’s combine them to build the breaker.
<section class="breaker">
<div class="breaker__hero">
<img src='../assets/hero.png' alt='Alt text'>
</div>
<div class="breaker__top">
<p class="eyebrow breaker__eyebrow">Drupal Development</p>
<h2 class="breaker__heading">Component main heading here</h2>
<p class="breaker__intro">Integer posuere erat a ante venenatis dapibus posuere velit aliquet. Aenean lacinia bibendum nulla sed consectetur. Cras mattis consectetur purus sit amet fermentum.</p>
</div>
<div class="breaker__cards">
<article class="card breaker__card breaker__card--first">
<span class="card__icon"><svg>...</svg></span>
<h3 class="card__heading">Fully responsive content</h3>
<p class="card__teaser">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor.</p>
</article>
<article class="card breaker__card breaker__card">
<span class="card__icon"><svg>...</svg></span>
<h3 class="card__heading">Fully responsive content</h3>
<p class="card__teaser">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor.</p>
</article>
</div>
</section>
Note: I created a sandbox project that includes all the code we wrote above and more. Feel free to get it at https://github.com/mariohernandez/building-components.
There are no hard rules for organizing and write your code but you will gain a lot if you stick with standards and best practices. I mentioned earlier we use BEM for class names, in addition, we also use some parts of SMACSS for organizing our code. If you downloaded the project from GitHub, you will notice our code is organized in a way that makes sense and each component’s code is grouped in a folder by the same name as the component. In addition, you will notice the file names on any given component follow the same name as the component. This is all done in an effort to make code reusable not just within a project but you can literally take these components and reuse them even on different projects.
In closing
It may seem like there is a lot of work upfront to get things in place when developing with components and it’s probably an accurate observation. However, all this work upfront pays off in the long term. I have worked on projects where the longer I work on the project the fewer things I am building because we get to a point where we are just reusing the components we already built.
Components are relatively new as a trend but the more you do it the more you will see their benefits.