(this post has bee update in a new series of articles, to CSS Architecture for Multiple Websites)
My name is Elad Shechter and for the last 5 years I have been working at Walla! News web development team. Walla! is one of the most well-established news website and mail provider in Israel, as it provides also many other products.
Over the last few years we have done major code refactoring to some of our most important products. Upgrading code, servers and creating numerous levels of abstraction. This was preformed in order to save costs and make day to day operations much easier, during which, the platform keeps on developing and growing rapidly.
In this article I would like to share our thoughts and work when designing our cross products CSS architecture.
It’s All About the Layers
Starting a big project, requires thinking global, and what things we have in common. It starts with the little things, like normalize, mixins, common icons and others(commons: elements, components and more).
After you understand this principle, you can begin making a basic global layer. This is the starting point of all layers of a project.
Achieving good framework requires arranging your projects in thin layers.
Here’s a good diagram that demonstrates our company needs.
The Layer Structure
In our architecture, each and every layer has at least 3 files; 2 private files (local, config) and one public file (main layer file).
The configuration(_config.scss) file of the layer (contains mostly variables), the second (_local.scss) is the file that includes the components which acts as a kind of controller or a package manager for the layer, and the third includes the first two files together (layer-name.scss).
Another principle that we set to our-self is to Try and divide everything to the smallest parts (small files) as possible, this principle will become very handy when refactoring is needed.
From every layer we need to compile only to root SASS file(layer-name.scss).
It’s independent, even if there isn’t such project.
Example of layer structure:
How it looks in the folders
Let’s assume we want to create a project from the base layer, we have to build a parallel folder with the project’s name. In the following example, we called it inherit-project.
The project has at least one _config.scss, one _local.scss and a main layer sass file named inherit-project.scss, the same as in every layer, except the name of the layer.
All layers/projects sit in the root folder of SASS.
The _config.scss of the layer imports the upper layer _config.css and can override the config variables from the upper layer or add its own new variables.
Here’s an example of the config file from the inherit-project:
We will do the same for the main components (local file) files of the layer.
This is the way to build a new layer that has its own style as we inherited in the base layer.
This layer has its own main CSS file named inherit-project.css .
Override variable in inner layer
Overrides variable is very easy when working in the layers method.
Let’s say we have variable of $base-color in the base layer and the color is blue. ($base-color:blue;)
Overriding this variable requires updating its value in the local _config.scss of your local layer. Update the value color in the local _config.scss, let’s say to red ($base-color:red); And now all the components that we inherit from the upper layer and the local layer, that are using this variable, will have updated the color according to the value of the variable in the local layer/project.
There are parts/components that don’t fit with the layer scope. If you update the main layer, unnecessary code will be added. That code is trash and it doesn’t have any function in most of the layers/projects that will inherit it.
In order to solve this problem, we chose to create the global _components concept.
The concept is that global components will be placed in the root folder outside of any layer, and work independently.
Example of separated components is illustrated in the following diagram:
Every layer can call single or multiple components, if necessary.
Example to folder that has global components:
local.scss file view of — import global component:
Few extra outlines
- You should be well organized. Organize your project all the time to answer your needs and maintain the best order.
- Don’t work too hard. You can import components of layers just by @import them directly. For example, let’s say there are some components that are published in the sports(project). Those components are relevant for the news site (another project). We can just @import those components to the news site.(site = layer = project)
- Make your job easier. Use code editor that can make refactor easily, without causing errors or bugs.
- Make sure you don’t break anything while you work. Compile all root SASS files while working and refactor the code to see that nothing is breaking constantly.
That’s all. I hope you enjoyed the article and learned from our experience.
If you liked this article you may like :
Responsive Design Best Practices for Big Projects