What is the question?
Hello everyone, today I want to share with you my personal experience in writing styles, or more simply put my vision on the problem of writing css for sites.
It would seem that in the age of technological development, when every day we are faced with new and new frameworks, preprocessors, template engines and other things, problems should not arise at all. Smart developers have come up with a bunch of cool "features" for the convenience of creating powerful and expandable sites. But how to use these tools correctly in CSS? And what are the difficulties?
I will try to answer these and other questions by suggesting my methods and approaches to solving some problems.
Harsh reality
It will not be a secret for anyone that beginner and experienced frontend developers are often given ready-made projects in which you need to make edits, remake the design, and so on. In my practice, there were a lot of such tasks when you work with someone else's code, which you need to understand and understand. And if a ready-made site fell into your hands, by opening a stylesheet, be prepared to see several thousand lines of code .
Of course, you as an experienced developer will open it in some kind of IDE, like Visual Studio Code and with a slight wave of your hand through the search and replace function, you can easily find and rewrite any class.
But if you need to make a decent amount of edits by integrating part of the new design for some sections there, how much time will you spend on this ?
I think a lot . And all that you do will be mildly "useless." Imagine a situation when the site you redone is transferred to another developer or after a while you are told to make new changes there .
SASS will solve our problems
After digesting all this information, a typical web developer will say that he is out of the situation: use CSS preprocessors. There and modularity and comfort and all.
Of course! But any tool in the hands of an inexperienced programmer loses all meaning. Sometimes you open the site’s styles and behold, the treasured folder with the name “sass”. Expecting a miracle most often you get only disappointment.
Breakdown of styles into separate files: header.sass, main.sass, animation.sass, etc. How "brilliant" it is. And not effective. Opening the next such file you come across the same bunch of style lines.
What are the alternatives?
It is better to keep silent about how developers call their classes sometimes, as well as about the chains of nesting of styles. I think everyone who has turned around in this area has heard anything about BEM and understands the importance of correctly naming classes. With this, it’s worth starting to solve all the problems.
I offer you a special approach, a special methodology for developing your styles, but not without the help of preprocessors. There are several stages to implementing this methodology:
- The first , as you already understood, is the proper naming of your classes.
- The second is to get rid of nesting styles. Here BEM methodology will help us. Having familiarized yourself with the basics of this wonderful documentation, you can proceed to the next.
- SASS - without this tool in any way. It is he who guarantees the modularity and power of your project.
- Assembly of the project. I think you have heard a lot about modern assemblers (there is a lot of information on building a project on the Internet). Gulp will help us here .
Now you are ready.
Now essentially
In the modern interpretation of the frontend, you can find quite a few javascript frameworks. Most of them divide the site into smaller parts, components. I suggest you do the same when you think about how to write styles. Each button, menu item, beautiful link, picture, and even plain text can be a component.
For example, on this form of entering the site, we can distinguish several components:
- Login form itself
- Input fields
- Submit button
- Checkbox
And as practice shows, in addition to the submit button on the site there will be many more of these buttons and it would be logical to keep all the styles for them in one place. The same can be said about the input fields, they can be in different places on the site, repeating their appearance.
Based on this, it will be logical to create a separate folder for each component and keep the styles there only for it, which will allow to implement a modular approach. But that is not all.
Component internals
As I said, there can be many buttons on a site, with different colors, different indents, all this is data and it’s very clever to separate this data from styles. Which I propose to do.
I propose to present each component in the form of three entities: vars, maker and creater. In simple terms, it is data, an action creator (methods for managing this data), and a style creator. Now, first things first.
- Data or vars. These include: button text color, button background color, padding, border-radius, font size, etc. All this data is written in the form of variables or an associative array in a separate file.
- Action creator or maker. It contains various functions or mixins that will take data as arguments and generate styles from them.
- Style maker or creater. Actually here we import data and methods for ourselves and bind them to each other as we need.
The following diagram shows the interaction of all three entities.
Is it hard to put all this into your head? Consider the example of creating the basic component of a button - “button”. We will use SCSS as a preprocessor.
As you already understood, in the new button folder we create three files: _vars.scss, _creater.scss, _maker.scss.
_vars.scss
$button_size:( sm:5px 20px, md:15px 20px ); $button_color:( white:#ffffff ); $button_back:( blue: #00e5e5 ); /* This is component config, it must be below other variables */ $button_config:( padding:$button_size, color:$button_color, background:$button_back );
As we see the data are presented in the form of an associative array. All individual styles are included in the main button_config set. In order to create new styles, the developer only needs to create a new array, fill it with the necessary values and connect it to button_config.
_creater.scss:
@import "vars"; @import "maker"; .button{ @include InitialComponent($button_config); }
Here we import data and action creator. Then, through the InitialComponent mixin which is registered in maker, we initialize all styles by passing the button_config variable. And here is the magic. All necessary classes are created in accordance with BM naming.
The result of the execution will be the styles:
.button_padding_sm { padding: 5px 20px; } .button_padding_md { padding: 15px 20px; } .button_color_white { color: #ffffff; } .button_background_blue { background: #00e5e5; }
And what is success here?
The advantage of this approach is not immediately felt. But as the project grows, you understand the convenience of such a methodology. If you need to change the color of several buttons on different pages, you do not need to look for classes in a bunch of styles. All that is needed is to open the button folder and accordingly the data file and replace the desired style there.
And if you need to create a new button?
Then it’s even easier, we write the necessary styles into an already prepared array or create a new one and connect it there in the config and the classes are created.
All this is very convenient, especially when you transfer your components from project to project and the speed of writing styles increases several times, leaving only a feeling of comfort and satisfaction that the project is in full order.
This approach has been successfully tested on many projects and the implementation of this methodology will soon be freely available with documentation in Russian and English.