Separating content from technical creation and layout has long been clear in online services and applications, but what is going on with the current component libraries and style guides? And what should a developer in particular know about the subject, even if they do not work with a front end on a daily basis?

“In terms of layout, there is of course a top-level brand guidance, i.e. different brand documents that define the use of the logo, typography, colours and more,” says Oskari Blomberg from Compile, who specialises in front end development and has been involved in creating several React component libraries and related style guides.

It is very typical to find ourselves in a situation where a so-called “million euro button” is created. Graphic designers in different projects make layouts that include, for example, a button that matches the style of the company. Next, the developers in different projects create the button to match the style of the layout, and possibly slightly differently in each project. It is significantly smarter to make a reusable component that has been done once properly. In this case, the developers can focus on the logic of the app instead of pixels, while the designers can polish the user experience to the max.

From a technical point of view, components should be “stupid”: they can convey logic, but do not contain it. Mostly they are stateless components related to the layout. This leaves more freedom, for example, in terms of technical creation of a form field. In a component you can, for example, specify what an error message looks like, but the validation of the input is left to the developer who utilises the component.

Savings and accessibility

The benefits of the component library are obvious. First of all, you save money: when you can plan everything appearance-related at the component level, you avoid unnecessary work. Another key benefit is improving accessibility. This is even more important when the requirements of the Accessibility Directive are put into practice.

“The benefits for the developer are, of course, being able to focus on logic and not counting pixels. It is not uncommon to have many different versions of the same type of implementation if you do not have a component library. Especially in the React world and when done correctly, component changes are easily used in applicable projects. At best, with one yarn/npm command,” says Oskari.

Recently, the interest in living style guides has increased rapidly – companies such as Elisa have a public style guide, and a group of other Finnish companies have private ones. There are even more public style guides around the world. “You can and should use them as a benchmark: how have things been done elsewhere, and what would be a good way for us?” Oskari advises.

In general, the style guide includes instructions for designers in addition to components and their documentation. “The fact that someone has coded a bright red button does not, of course, mean that this button should be used in every situation,” Oskari says.

“There are ready-made package solutions for implementing living style guides, such as React Styleguidist, but they may not be customisable enough for your needs,” says Oskari. “A ready-made solution can be ok, especially in the early stages, but we’ll quickly reach a point where the entire style guide could be built with components coded for it.”


Oskari Blomberg, originally from Mikkeli, at Compile since autumn 2017. He previously worked long at Yle as a creator of news and current affairs websites. He ended up in the field “by accident.” This media assistant got excited about coding and went briefly to Tampere after the army to study IT business, but eventually work transported him first to digital agencies and then to Yle.