Separating content from the technical implementation 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 the 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,” explains 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 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 was executed properly in the first place. 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 “simple”: they can convey logic, but do not contain it. Mostly, they are stateless components related to the layout. This leaves more freedom in terms of the technical creation of a form field. In a component you can 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,” notes Oskari.
Recently, 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 reminds us.
“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.”
Who?
Oskari Blomberg, originally from Mikkeli, at Compile since autumn 2017. He previously had a long career 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 his military service to study IT and business, but, eventually, work transported him first to digital agencies and then to Yle.