Sass-architecture of your project
There are different approaches for organizing sass-architecture, whichever you choose, the main thing is that it should be.
I treat the organization of sass as an instrument, in the first place, it should not interfere and slow down the train of thought. Therefore, when starting a project, I do not know what the architecture will turn out to be, it will settle down in the course of work and take the form suitable for the requirements of the project.
Bem, Smacss, Oocss, Organic-css should give you the flexibility of thought to build your project.
I always start a project with a standard file organization for myself:
')
All I know is 100% that the core daddy will be useful to me, where the project settings, general rules, helpers will lie, let's go through the main ones:
core / _core.sass
It serves to connect all files from the core folder, you can connect the compass here if it is used on the project.
core / _mixins.sass
I try not to carry with me a bunch of mixins from a project to a project, this file is surrounded by them as needed, but by default I use a couple of mixins: em, cp, reset-btn.
core / _reset.sass
I didn’t get accustomed to normalization, I use reset in my projects to equalize styles in browsers.
core / _settings.sass
This file collects the settings for the entire project: font sizes, colors, maximum width, etc.
core / _base.sass
Serves for the general rules on the project, body I make the font-size equal to the specified variable, so that later it is convenient to calculate em with the help of the eponymous mixin, before I made this font-size equal to 62.5% so that 1em was 10 pixels.
After that, I try to just typeset without paying special attention to the architecture, sometimes even in a single file. But for the entire time of the project, the points come when the future architecture begins to appear, and then, I put everything on the shelves, as the project requires, not inventing the limitations for myself ahead of time, this results in completely different forms of organization:
For example, the site of my small project did not require a special organization, by the way, the source code can be viewed on github: github.com/omelniz/block-flute
One-page site, divided into blocks, smgomsk.ru
Public Speech is already a bigger site and demanded a more flexible architecture from itself. theps.ru
Large projects should have stricter rules, although they can start their own way as well. The rules should be supported by someone else, the project will turn into a pumpkin, perhaps in a couple of months.
This is my personal experience in organizing sass-architecture projects, it is interesting to me to think with my head, and not blindly use existing methodologies, although sometimes this is exactly what is needed.
I treat the organization of sass as an instrument, in the first place, it should not interfere and slow down the train of thought. Therefore, when starting a project, I do not know what the architecture will turn out to be, it will settle down in the course of work and take the form suitable for the requirements of the project.
Bem, Smacss, Oocss, Organic-css should give you the flexibility of thought to build your project.
I always start a project with a standard file organization for myself:
')
All I know is 100% that the core daddy will be useful to me, where the project settings, general rules, helpers will lie, let's go through the main ones:
core / _core.sass
It serves to connect all files from the core folder, you can connect the compass here if it is used on the project.
core / _mixins.sass
I try not to carry with me a bunch of mixins from a project to a project, this file is surrounded by them as needed, but by default I use a couple of mixins: em, cp, reset-btn.
core / _reset.sass
I didn’t get accustomed to normalization, I use reset in my projects to equalize styles in browsers.
core / _settings.sass
This file collects the settings for the entire project: font sizes, colors, maximum width, etc.
core / _base.sass
Serves for the general rules on the project, body I make the font-size equal to the specified variable, so that later it is convenient to calculate em with the help of the eponymous mixin, before I made this font-size equal to 62.5% so that 1em was 10 pixels.
After that, I try to just typeset without paying special attention to the architecture, sometimes even in a single file. But for the entire time of the project, the points come when the future architecture begins to appear, and then, I put everything on the shelves, as the project requires, not inventing the limitations for myself ahead of time, this results in completely different forms of organization:
For example, the site of my small project did not require a special organization, by the way, the source code can be viewed on github: github.com/omelniz/block-flute
One-page site, divided into blocks, smgomsk.ru
Public Speech is already a bigger site and demanded a more flexible architecture from itself. theps.ru
Large projects should have stricter rules, although they can start their own way as well. The rules should be supported by someone else, the project will turn into a pumpkin, perhaps in a couple of months.
This is my personal experience in organizing sass-architecture projects, it is interesting to me to think with my head, and not blindly use existing methodologies, although sometimes this is exactly what is needed.
Source: https://habr.com/ru/post/249047/
All Articles