{"id":2972,"date":"2021-04-19T16:48:00","date_gmt":"2021-04-19T16:48:00","guid":{"rendered":"https:\/\/radicalbit.ai\/?p=2972"},"modified":"2026-04-23T08:56:51","modified_gmt":"2026-04-23T08:56:51","slug":"design-system-tips","status":"publish","type":"post","link":"https:\/\/radicalbit.ai\/it\/resources\/blog\/design-system-tips\/","title":{"rendered":"Sparking joy in a design system"},"content":{"rendered":"\n

Implementing BEM in a cluster of products made with React.js following Marie Kondo\u2019s secret of happiness
Any frontend developer will have experienced the pleasure of opening the newly released page with the Chrome inspector finding a clear and semantic clean code. Not even Marie Kondo could do better!
How many times has it happened to you to review some old code and think: \u201cgosh, how bad is this? ? who assigned the classes? What a mess!\u201c.<\/p>\n\n\n\n

At first glance, it might be the work of the former nice but bungling colleague, but Git doesn\u2019t lie and Visual Studio quickly reveals the author \u2013 what the heck \u2013 it was me to create this obscenity! There might be a positive side: you have improved your skills over the time, and the code you write today is neater than yesterday.
When working as a team on a complex and rapidly evolving product, this individual process takes its toll:
a shared nomenclature system must be adopted then.<\/p>\n\n\n\n

\u201cTidying up should be about re-establishing a balance between people, their belongings and the house they live in<\/em>.\u201d \u2013 Marie Kondo<\/p>\n\n\n\n

Teamwork<\/h2>\n\n\n\n

As naming things is a rare talent, adopting a naming convention helps teamwork and turns the giant question mark about how to name an object into an automatic process that follows precise rules, and that \u2013 at best- someone has defined before you. It\u2019s reassuring to have both a tidy closet and a uniform code, isn\u2019t it?<\/p>\n\n\n\n

Designing an interface thinking in BEM<\/h2>\n\n\n\n

An interface designer, able to reach a good level of abstraction, may already have in mind the html structure of components while drawing them, from the draft to Figma.
After reasoning about the user experience and the aesthetic research of the interface, the designer can focus on assembling and naming the components and levels to prepare the code development process, anticipating potential development problems.<\/p>\n\n\n\n

BEM provides a model that helps to reason in these terms: association between Figma and BEM
component = block,
layer \/ group = element,
variant = identifier, works well.
Just as our cute Japanese heroine suggests organizing spaces in the simplest way possible, dividing the garments according to a logic grouped by type, so also in designing a mockup it is useful to declutter and group by sets and subsets according to a defined protocol.<\/p>\n\n\n\n

It is essential to discuss with the technicians to validate feasibility and nomenclature, and with the help of the FE colleagues, to work on functional and shared solutions for this \u201cchest of drawers\u201d \u200b\u200bwhich will mainly serve them.<\/p>\n\n\n\n

\u201cWords can be bullets, but they can also be rescue teams\u201d \u2013 J\u00f3n Kalman Stef\u00e1nsson<\/p>\n\n\n\n

Block_element \u2014 identifier<\/h2>\n\n\n\n

BEM is a convention created in 2007 (read here how it was born) to improve collaboration in frontend development.
Thanks to BEM we are able to assign to the classes of our DOM elements names that are explicit about the type and hierarchy of their content:
Block is the main container that contains a set of other elements, even at multiple nesting levels: our \u201cchest of drawers\u201d, to clarify
Element is the child of the block and distinguishes each of the main sections that contain other elements, the \u201cbox that divides the socks\u201d, simply
Identifier is an indicator that changes the appearance of the block or element, as if the labels of the containers transform the shirts into wool sweaters.<\/p>\n\n\n\n

An example: l-header, a component of our design system, has an intrinsic structure that can contain strings, objects or other independent components.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

styles.less<\/h4>\n\n\n\n
.l-header {\n   display: flex;\n   flex-direction: row;\n   padding: 1rem;\n   flex-wrap: wrap;\n   gap: 1rem;\n   align-items: stretch;\n \n \n   &__title {\n       display: flex;\n       flex-direction: column;\n       justify-content: center;\n       align-items: flex-start;\n       order: 1;\n       flex-grow: 1;\n   }\n \n   &__details {\n       display: flex;\n       flex-direction: row;\n       justify-content: flex-end;\n       align-content: flex-end;\n       order: 2;\n       flex-grow: 2;\n       flex-wrap: wrap;\n       gap: .5rem;\n   }\n \n   &__actions {\n       display: flex;\n       flex-direction: column;\n       justify-content: space-between;\n       order: 3;\n       flex-grow: 0;\n       flex-wrap: wrap;\n       gap: .5rem;\n   }\n  \n   &--dark-mode {\n       background: @rdb-dark;\n       color: @rdb-white;\n   }\n}<\/code><\/pre>\n\n\n\n
index.js<\/p>\n\n\n\n
<div className={`l-header ${modifier || ''}`}>\n \n     <div className=\"l-header__title\">\n       <PageTitle\n         subtitle={subtitle}\n         icon={icon}\n         isEditable={isEditable}\n         onTitleChange={onChange}\n         title={text}\n       \/>\n     <\/div>\n     {details && (\n       <div className=\"l-header__details\">\n \n         {details.one && details.one}\n         {details.two && details.two}\n         {details.three && details.three}\n \n       <\/div>\n     )}\n     {actions && (\n       <div className=\"l-header__actions\">\n \n         {actions.one && actions.one}\n         {actions.two && actions.two}\n \n       <\/div>\n     )}\n <\/div><\/code><\/pre>\n\n\n\n
\u201cThere are only two hard problems in Computer Science: cache invalidation and naming things\u201d \u2013 Phil Karlton<\/p>\n\n\n\n
Robust CSS architecture<\/h2>\n\n\n\n
In Radicalbit we have chosen BEM as the reference model among the many conventions available (OOCSS, SMACSS, SUITCSS, Atomic) because its peculiarities are perfectly adaptable to the needs of a design system:<\/p>\n\n\n\n
Clear Structure<\/h2>\n\n\n\n
Having a semantics similar to the React structure allows us to think in terms of components: each component is an easy block to intercept and recognize within the project also in the compiled html.<\/p>\n\n\n\n
<div class=\"l-header \">\n    <div class=\"l-header__title\">\n        <div class=\"c-section-title\">\n            <h1 class=\"c-section-title__title\">\n                Microfrontend Title\n            <\/h1>\n            <div class=\"c-section-title__props\">\n                Title props \n            <\/div>\n        <\/div>\n     <\/div>\n     <div class=\"l-header__details\">\n        <div class=\"c-detail\">\n            <span class=\"c-detail__label\">Detail label<\/span>\n            <h3 class=\"c-detail__content\">Detail <\/h3>\n        <\/div>\n        <div class=\"c-detail\"><\/div>\n        <div class=\"c-detail\"><\/div>\n    <\/div>\n    <div class=\"l-header__actions\"><\/div>\n<\/div><\/code><\/pre>\n\n\n\n
Modularity<\/h2>\n\n\n\n
Each block is made up of distinct units, each performing a specific task and capable of interacting with the others, or being used in different patterns.
Below is our l-header used in various sections of the RNA interface, our MLOps Platform.<\/p>\n\n\n\n
\"data<\/figure>\n\n\n\n
Reusability<\/h2>\n\n\n\n
Each component, while maintaining its properties, can change shape or color to match its parent or its identifier.
This is how our l-header changes its appearance based on context and content.In this case the product has the structure of our design system but in light mode and with a different primary color in our product GoLive.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
ABEM: a useful adaptation of BEM  <\/h3>\n\n\n\n
Distinguishing a room from a wardrobe and a wardrobe from a drawer is natural when we tidy up our house. When it comes to a design system, things become more complicated.
Fortunately, some specificities of our method come to the rescue.
The code shared so far has one more module than the Block__element\u2013 identifier,<\/strong>  in fact a more recent declination called ABEM<\/a> (*) allows us a further classification and greater flexibility.
A (tomic) BEM defines the type of block with a prefix of a single letter, while the classes atomic<\/em> allows the use of global styles, limiting the known problem of  stiffness of the original system.
Our pure BEM react component could have looked like this:<\/p>\n\n\n\n
<div className={`l-header l-header--$ {modifier || ''}`}><\/code><\/pre>\n\n\n\n
instead we have chosen to free the modifier class from the constraint of the containing block.<\/p>\n\n\n\n
<div className={`l-header $ {modifier || ''}`}><\/code><\/pre>\n\n\n\n
In this way, we can also dynamically manage state classes or helpers better described below.<\/p>\n\n\n\n
Selector specificity<\/h3>\n\n\n\n
The ABEM structure is extremely interesting thanks to the openness of the atomic classes but it\u2019s not close enough to the desired solution.  For our structure is ideal to use the self explanatory nomenclature prefix as suggested in this article<\/a><\/strong>. We can distinguish the type of block in order to recognize the genre of our selector:<\/p>\n\n\n\n