• CSS Architecture for Multiple Websites
  • Original post by Elad Shechter
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Baddyo
  • Proofreader: Xionglong58, LGH757079506

CSS architecture for multi-site projects

CSS Architecture — Part 3

Complex CSS architectures are not something you learn in college.

My fourth job in the Internet industry was as a CSS/HTML expert in one of China’s leading media news companies, where my main responsibility was to develop reusable and extensible CSS architectures for multiple websites.

In this article, I will share my knowledge and experience in the field of building multi-site architectures.

Side note: Nowadays, CSS preprocessors are used in formal projects. In this article, I’ll use the Sass preprocessor.

This is the third article in a series I’ve written about CSS architecture. The second article in this series, CSS Architecture: Folders and File Structures, is recommended to help you understand this article better.

Build the world with layers

Before embarking on a large project, we should look at the big picture and distill out what multiple sites have in common. The building starts brick by brick, and the building blocks are formalized, Mixins, common ICONS, and local modular layers (elements, components, graphic logic, entities, pages… And so on.

To make multiple projects (that is, multiple sites) work, we must decide which styles are common and which are proprietary — common styles are written in the base layer, and proprietary styles are written in their corresponding layers. It is a road of trial and error. It’s not unusual to have to shuffle the style code layer by layer every time we think about it differently until it feels right to us.

With this principle understood, we can start building the global layer as the foundation. This global layer is the starting point for the entire multiple project (multiple sites).

The following example diagram illustrates our project requirements at that time.

Keep the base layer light, containing only CSS initialization, basic SASS mixins, common ICONS, common fonts (if needed), and function classes, and if some grid layout works for all sites, add it to the base layer as a common grid. In the _partials.scss layer (elements, components, etc.), we mainly use the _elements. SCSS layer, which contains local modules such as common pop-ups, common forms, and common titles. What we should add to the base style is what all (or most) of the underlying styles have in common. (For more details on folder and file structure, see my last article)

How do YOU organize multiple layers

In our architecture, each layer contains at least three files: two private files (local style files and configuration files, called private because they are not compiled into a CSS file) and one public file (the main file for this layer). The configuration file _config.scss for each layer usually contains variables. The _local. SCSS file contains the content style and acts as a controller or package manager for the current layer. The third file (layer-name.scss) calls the first two.

Layer – name. SCSS document:

@import "config";
@import "local";
Copy the code

Another rule we set for ourselves is to break each document into the smallest possible pieces (small files). This principle makes refactoring very convenient.

In each layer, make sure that only the layer-name.scss file is compiled, even if some layers represent a “virtual project” (such as the “base layer framework” in the example figure above).

For private files that will not be compiled as separate files, we prefix their file names with an underscore (_). The underline here indicates that the file cannot exist alone.

** Note: ** When importing private files, we can write their names without prefix underscores.

Example layer architecture:

The folder structure looks like this:

sass/ 
 |
 |- base-layer/
     |- config/     
     |- local/ | - _config. SCSS | - _local. SCSS | - base - layer. The CSS (compiled layer style) | - base - layer. The SCSSCopy the code

inheritance

Suppose we want to create a project from the base layer. We need to copy the internal structure of the Base-Layer folder with the name of the new project. In the following example, we will call this new project Inherited – Project.

Tip: Put all layer directories and project directories in the root of Sass.

The project contains at least one _config. SCSS file, one _local. SCSS file, and the core Sass file for this layer — in this case, inherited-project.scss.

All layers and projects are located in the root directory of Sass.

sass/ 
 |
 |- base-layer
 |   |- config/     
 |   |- local/ | | - _config. SCSS | | - _local. SCSS | | - base - layer. The CSS (compiled layer style) | | - base - layer. The SCSS | | - inherited - project | - config/ |-local. / | - _config SCSS | - _local. SCSS | - inherited - project. CSS (compiled layer style) | - inherited - project. SCSSCopy the code

The inheritance-Project configuration file imports the configuration file in the Base-layer. In this way, we can add new variables or overwrite existing ones in the base-layer.

The following is an example of inherited-project/_config. SCSS:

/* Load base-layer configuration information */ @import".. /base-layer/config.scss"; /** Local Config layer (add or overwrite variables as needed)**/ @import"config/directions.scss";
Copy the code

Iinherited -project/_local. SCSS

/* Import base-Layer local components */ @import".. /base-layer/local.scss"; /* local font */ @import"local/font-almoni.scss"; /* Local component */ @import"local/elements.scss";
@import "local/components.scss";
Copy the code

If you are creating a new layer that has both generic and unique styles, it is appropriate to inherit the base layer style from the Base-Layer folder.

This layer creates a CSS file named inherit-project. CSS.

Overwrites variables in the inner layer

Overwriting variables in a “layer” manner is very simple.

For example, in the base layer there is a variable called $base-color that has a value of blue ($base-color: blue;). . To override this variable, you need to update its value in the local file _config.scss. Now, all components that use this variable — whether inherited from the base layer or defined locally — update the color value of the corresponding variable.

Global Story Global

Some modules are not used in all layers, so if you define them in the base layer, other projects will import redundant code. To solve this problem, I went the other way, using the concept of a global module.

The concept is to place modules that are only used for certain layers in a new root directory (_partials) that is outside all layers. Any layer can then import the required modules from the global directory _partials.

The following figure shows an example of separating modules:

Each layer can call one or more modules as needed from the global directory _partials.

Global directory_partialsExample:

sass/ 
 |
 |- _partials/ 
 |- base-layer/ 
 |- inherited-project/
Copy the code

from_partialsImport the module local. SCSS file:

/* Import local components in base-layer */ @import".. /base-layer/local.scss"; /* Local component */ @import"local/partials.scss"; /* Add global module */ @import".. /_partials/last-connection";
Copy the code

A little extra advice

  • Be organized. Always remember to plan your project in a way that meets your needs and maintains the best structure.
  • Don’t make the same mistakes. Use only@importYou can easily import components from another layer. For example, some components defined in one “sports” project are associated with a “news” site in another project. So we can just take these components@importGo to the “news” website. (Site = layer = project)
  • Take advantage of IDE shortcuts. Choose an editor that is easy to refactor without causing errors or failures.
  • Be new and not old. During development and subsequent refactorings, all Sass root files should be compiled together each time to avoid disconnection between the old and the new.

conclusion

In this article, I show you how to build a CSS architecture for multi-site projects based on my years of knowledge and experience.

This article is the third in a series of CSS architecture articles that I will share with you every few weeks.

If you find this article interesting, feel free to follow me on Twitter or Medium.

My CSS architecture series:

  1. Normalize CSS or CSS reset? !
  2. CSS Architecture – Folder and file architecture
  3. CSS architecture for multi-site projects

conclusion

Well, that’s it for now. I hope you enjoy this article and learn from my experience. If you enjoyed this post, please like it and share your thoughts with us, I would appreciate it. : -)

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.