Modulare Praxis der CSS-Vorverarbeitungssprache

Das Schreiben von CSS ist eine häufige und häufige Aufgabe bei der Frontend-Arbeit. Da CSS keine Sprache ist, wirkt die Programmierung etwas grob. Bei kleinen Projekten ist die Menge an CSS nicht riesig und das Problem wird nicht hervorgehoben. Wenn Sie jedoch ein größeres Projekt entwickeln und verwalten möchten, müssen Sie CSS verwalten und standardisieren, da sonst irreparable Konsequenzen auftreten (Wen versuchen Sie?). Angst?

Hintergrund

Im vorherigen Abschnitt [Diskussion über die Modularität von CSS] haben wir die Art und Weise, wie CSS geschrieben wird, durch standardisierte Einschränkungen optimiert und verbessert, um eine nachhaltige Entwicklungsroute zu bilden. Aber eines bleibt: Redundanz. Obwohl wir durch die Definition von öffentlichen Modulen und privaten Modulen beschönigend die gemeinsame Menge teilen, ist die gemeinsame Menge immer noch zu groß, und aus gestalterischer Sicht sollten wir so viele öffentliche Module wie möglich verfeinern, um eine bessere Wiederverwendung zu erreichen. Im Idealfall sind alle Module in einer gemeinsamen Bibliothek gespeichert und können direkt aus der Bibliothek dorthin übertragen werden, wo sie benötigt werden. Dieser schöne Wunsch ist nicht unerreichbar. Mit Hilfe der Vorverarbeitungssprache können wir dies leicht erreichen.

Die Vorverarbeitungssprache ist eine CSS-ähnliche Sprache. Wir wissen, dass CSS selbst keine Sprache ist und die Vorverarbeitungssprache entwickelt wurde, um diesen Teil der Sprachfunktion zu erfüllen. Es implementiert die Definition von Variablen, Funktionen und Mischungen sowie die Funktionen Dateireferenz, Zusammenführung und Komprimierung, wodurch CSS objektorientiert ist und komplexe und große Unternehmen bewältigen kann.

Derzeit gibt es zwei beliebte Vorverarbeitungssprachen: less und sass. Für das Studium können Sie mit beiden beginnen, und für die Arbeit sollten Sie versuchen, mit einem davon vertraut zu sein. Ich verwende Sass häufiger, daher wird der folgende Inhalt mit Sass als Basissprache eingeführt. Die beiden weisen viele Ähnlichkeiten in den Funktionen auf, sodass Sie sich keine Sorgen über große Unterschiede in der Implementierung machen müssen.

sass

Sie können die grundlegende Grammatik auf der offiziellen Website (Englisch) oder im w3cplus-Sass-Leitfaden (Chinesisch) lernen. Wir werden hier nur kurz darauf eingehen und auf einige der Inhalte eingehen, die wir verwenden müssen.

Sass hat zwei Suffixdateinamen: Einer hat den Suffixnamen sass und verwendet keine Klammern und Semikolons; der andere ist die hier verwendete SCSS-Datei, die dem CSS-Dateiformat ähnelt, das wir normalerweise schreiben, mit geschweiften Klammern und Semikolons. Alle in diesem Tutorial erwähnten Sass-Dateien beziehen sich auf Dateien mit dem Suffix scss. Es wird außerdem empfohlen, Dateien mit dem Suffix scss zu verwenden, um Fehler aufgrund der strengen Formatanforderungen des Sass-Suffixes zu vermeiden. ——Auszug aus dem w3cplus Sass Guide

1. Verschachtelung (sehr wichtige Funktion)

In Sass gibt es zwei Arten der Verschachtelung: Die eine ist die Verschachtelung von Selektoren, die andere die Verschachtelung von Attributen. Worüber wir normalerweise sprechen oder was wir verwenden, ist die Verschachtelung von Selektoren. ——Auszug aus dem w3cplus Sass Guide

Selektorverschachtelung Die sogenannte Selektorverschachtelung bezieht sich auf die Verschachtelung eines Selektors in einem anderen Selektor, um eine Vererbung zu erreichen und dadurch die Struktur und Lesbarkeit der Sass-Datei zu verbessern. Bei der Selektorverschachtelung können Sie & verwenden, um den Selektor des übergeordneten Elements darzustellen. ——Auszug aus dem w3cplus Sass Guide

// index.scss

.g-index {
  ...

  .g-hd {
    ...

    .m-nav { ... }
  }

  .g-bd {
    ...

    .m-news { ... }
  }

  .g-ft {
    ...

    .m-copy_right { ... }
  }

  .m-dialog {
    display: none;

    &.z-active {  // 留意此处&的用法
      display: block;
    }
  }
}

Nach der Zusammenstellung:

/* index.css */

.g-index { ... }
.g-index .g-hd { ... }
.g-index .g-hd .m-nav { ... }

.g-index .g-bd { ... }
.g-index .g-bd .m-news { ... }

.g-index .g-ft { ... }
.g-index .g-ft .m-copy_right { ... }

.g-index .m-dialog {
  display: none;
}

.g-index .m-dialog.z-active {  // 留意此处&的编译结果
  display: block;
}

Ist es nicht cool? Es besteht keine Notwendigkeit, viele Selektoren immer wieder zu kopieren und zu ändern, und es ist nicht erforderlich, die Beziehungen zwischen ihnen zu sortieren. Sie müssen sie nur verschachteln, und alle Beziehungen sind so einfach und klar wie ein Blick auf das DOM direkt! Befreien Sie Ihre Hände, befreien Sie Ihre Augen und steigern Sie gleichzeitig die Effizienz. Es ist erwähnenswert, dass wir beim Schreiben von Sass versuchen sollten, die Verschachtelungsreihenfolge von Sass mit dem DOM konsistent zu halten. Beachten Sie, dass die Verschachtelungsreihenfolge konsistent ist, nicht die Ebene, da nicht alle Elemente im DOM formatiert werden müssen.

Lassen Sie uns ein anderes Szenario erwähnen, um zu veranschaulichen, dass die verschachtelte Schreibmethode von sass einfach zu warten ist. Angenommen, es gibt ursprünglich ein Modul m-article_box unter g-bd. Jetzt möchten wir m-article_box von g-bd nach g-hd migrieren. Natürlich ist diese Anforderung etwas unvernünftig~), schauen wir uns den Originalcode an:

<!-- index.html -->

<!DOCTYPE html>
<html>
<head>
  <title>index</title>
</head>
<body>
  <p class="g-index">
    <p class="g-bd">
      <p class="m-article_box">
        <p class="hd">
          最新文章
        </p>
        <p class="bd">
          <p class="list">
            <p class="item">
              <img class="cover" />
              <p class="info">
                <p class="title">
                  <a href="#">文章标题</a>
                </p>
                <p class="desc">文章简介</p>
              </p>
            </p>
          </p>
        </p>
        <p class="ft">
          <p class="page">
            <a href="#" class="pg">1</a>
            <a href="#" class="pg">2</a>
            <a href="#" class="pg">3</a>
            <a href="#" class="pg">4</a>
          </p>
        </p>
      </p>
    </p>
  </p>
</body>
</html>

.g-bd { ... }
.g-bd .m-article_box { ... }
.g-bd .m-article_box .hd { ... }

.g-bd .m-article_box .bd { ... }
.g-bd .m-article_box .bd .list { ... }
.g-bd .m-article_box .bd .list .item { ... }
.g-bd .m-article_box .bd .list .item .cover { ... }
.g-bd .m-article_box .bd .list .item .info { ... }
.g-bd .m-article_box .bd .list .item .info .title { ... }
.g-bd .m-article_box .bd .list .item .info .desc { ... }

.g-bd .m-article_box .ft { ... }
.g-bd .m-article_box .ft .page { ... }
.g-bd .m-article_box .ft .page .pg { ... }

Gemäß der CSS-Methode müssen wir alle Teile, die sich auf m-article_box beziehen, von g-bd nach g-hd kopieren. Dies gilt immer noch unter der Bedingung, dass das Schreiben des Moduls nicht den Spezifikationen entspricht und nicht alle Strukturen unter der Klasse m-article_box hängen bleiben Aber jetzt, wo wir sass verwenden, müssen wir nur noch den gesamten Block von m-article_box von g-bd nach g-hd schneiden (um den hohen Arbeitsaufwand der Änderung hervorzuheben, habe ich speziell die gesamte Modulstruktur geschrieben – nicht nur zum Erstellen). die Wortanzahl... ):

// 修改前
.g-hd { ... }

.g-bd {
  .m-article_box {
    .hd { ... }
    .bd {
      .list {
        .item {
          .cover {
            ...
          }

          .info {
            .title {
              ...
            }

            .desc {
              ...
            }
          }
        }
      }
    }

    .ft {
      .page {
        .pg { ... }
      }
    }
  }
}

// 修改后
.g-hd {
  .m-article_box {
    .hd { ... }
    .bd {
      .list {
        .item {
          .cover {
            ...
          }

          .info {
            .title {
              ...
            }

            .desc {
              ...
            }
          }
        }
      }
    }

    .ft {
      .page {
        .pg { ... }
      }
    }
  }
}

.g-bd { ... }

Sehr komfortabel und weniger fehleranfällig.

2. Variable

Gehen wir direkt zum Code:

// index.scss

$fontSize: 16px;
$grey: #ccc;

.m-nav {
  font-size: $fontSize;
  color: $grey;
}

Kompilierungsergebnis:

/* index.css */

.m-nav {
  font-size: 16px;
  color: #ccc;
}

Jeder, der Code geschrieben hat, ist mit der Verwendung von Parametern vertraut. Ich möchte nicht zu viel sagen.

3. Funktion

// pixels to rems

@function rem($px) {
    @return $px / 640 * 16rem;
}

Es ist zu einfach und direkt. Ich möchte es nicht zu viel sagen.

4、混合（mixin）

混合，顾名思义，就是混合的意思。。。也就是我们可以事先定义一段代码块，在需要使用到的地方，直接引用（include），而在引用之前，这段代码都不会出现在编译文件中，也就是不会生成任何内容。

这也是非常重要的一个特性！我们知道common的体积非常大，而体积大的根本原因是它存放了许许多多的模块。我们设想一下，如果将每一个模块都打包成mixin，那common不就减肥成功了？！多年的顽疾终于看到希望，没有比这更让人惊喜的了！我们这就上车：

/* common.css */

.m-nav { ... }
.m-news { ... }
.m-copy_right { ... }

改造后

// common.scss

@mixin m-nav {
  .m-nav { ... }
}

@mixin m-news {
  .m-news { ... }
}

@mixin m-copy_right {
  .m-copy_right { ... }
}


// index.scss

.g-index {
  @include m-nav;
  @include m-news;
  @include m-copy_right;
}

5、import

这个属性很眼熟？没错，事实上，css本身就有这个属性实现，我们可以在css文件中直接使用import来引入其他文件。那么css的import和sass的import有什么区别？从含义和用法上来说，没有区别，区别在于工作原理。css的import是阻塞的，而sass的import在编译后，其实是合并文件，最后只产出一个css文件，而css则没有合并，该多少个文件就还是多少个文件。

注意：

1. 只有import一个.sass/.scss文件的时候，才可以省去后缀名，如果是直接import一个.css文件，要补全文件名；

2. 
   

3. import之后的分号;不要漏写，会报错；

4. 
   

5. sass如果import的是一个.css文件的话，那它的作用就跟css原生的import作用一样，只有import一个sass文件的时候，才是合并文件。

如下：

// index.scss
@import 'common';
@import 'a.css';

编译结果：

/* index.scss */

.m-nav { ... }
.m-news { ... }
.m-copy_right { ... }

@import url('a.css');

css的import之所以没有被普遍使用是有原因的。我们可以大概猜到它的工作原理：a.css import b.css以后，当浏览器加载到页面中的a.css的时候，已经准备按照a.css的内容来渲染页面了，刚解析到第一行，发现a.css居然还import了一个b.css，于是它不得不先放下a.css（既阻塞a.css），去加载b.css，直到b.css加载完，并且优先解析它，然后才开始回来解析a.css——鬼知道b.css会不会又import了c.css……这直接导致了渲染工作滞后，引发性能问题。

说实话我还不如直接用两个link标签去同步加载a.css和b.css，效率会高一些。

所以css的import基本是被抛弃了的属性。

sass的import主要的好处就是把文件合并了，减少了请求。原本需要link好几个css文件的页面，现在只需要一个。

模块化

终于要开始干点正事了，首先我们来回顾一下，上一节我们以规范为基础构建的模块化项目，遗留了一些什么问题。

1. 冗余 体积庞大的common；

2. 
   

3. 使用cm-模块区别m-模块，使得后期开发过程中，m-模块向cm-模块转变过程比较繁琐；

……

好像，问题也不是特别多，我们一个一个解决。

为了方便，在这里我们把每个页面所对应的scss文件叫做 页面scss；把变量、函数、混合等（没有被引用或者执行的情况下）编译后不产生实际内容的代码叫做 定义类代码 ，那么相对应的其他内容就是 实际内容代码。

1、mixin.scss

我们知道，一方面，在common中过多地添加模块最终会导致common的体积过大，使得资源冗余，另一方面，为了方便维护，我们又希望尽量多地把模块公有化。

这是一对矛盾，仅靠css本身是无法解决的，但sass可以！如果我们使用mixin来代替直接书写模块，由于mixin并不直接生成代码，而是通过主动引用，才能生成对应内容，那么理论上，common就可以无限多地存放模块而不必占用一点空间！

（注意，这里说的是理论上，实际应用中，文件太过庞大的话，免不了还是要受到命名冲突的限制的，不过这问题不大。）

说干就干，我们把common中的模块全部打包成mixin：

/* common.css */

.m-nav { ... }
.m-news { ... }
.m-copy_right { ... }

改造后

// common.scss

@mixin m-nav {
  .m-nav { ... }
}

@mixin m-news {
  .m-news { ... }
}

@mixin m-copy_right {
  .m-copy_right { ... }
}

调用方式如下：

// index.scss

@import 'common'; // 记得先引入common

.g-index {
  @include m-nav;
  @include m-news;
  @include m-copy_right;
}

原本我们会在每个需要用到公共模块的页面中，先引用common，然后再引用页面css，而现在，我们只需要在页面scss中直接@import common;就可以了。

使用common：

<!-- index.html -->

<!DOCTYPE html>
<html>
<head>
  <title>index</title>
  <link rel="stylesheet" type="text/css" href="./style/common.css">
  <link rel="stylesheet" type="text/css" href="./style/index.css">
</head>
<body>
  ...
</body>
</html>

改造后：

// index.scss
@import 'common';

<!-- index.html -->

<!DOCTYPE html>
<html>
<head>
  <title>index</title>
  <link rel="stylesheet" type="text/css" href="./style/index.css">
</head>
<body>
  ...
</body>
</html>

很完美，——至少目前为止是这样。

我们思考一个问题，common除了存放模块之外，还有没有其他内容？答案是肯定的，大家一定知道有个东西叫做css reset（或者normalize.css），这肯定是全局的；另外，如果是做后台管理系统的话，可能还会有bootstrap。当然，还有一些自定义的全局的样式，比如常见的.clearfix，等等。

这些东西目前我们也堆积在common当中，而且合情合理，因为它们都是全局的样式。但是对比起mixin来说，这些实际内容代码显得很少量，有种被淹没的感觉，使得整个common看上去就像只有mixin。但是这些实际内容代码的作用却又非常重要。为了使common的构成更加直观，我们把mixin全部都抽离出来，单独存放一个叫做mixin.scss的文件中，然后在common引用它，这样，mixin的管理更加的规范，而且common的结构也更加清晰了。

抽离mixin还有另外一个重要原因，后面会讲到的，我们希望mixin作为一个纯粹定义类代码文件，随处可以引用而不会生成多余的代码。

原本我们会在每个需要用到公共模块的页面中，先引用common，然后再引用页面css，而现在，我们只需要在页面scss中直接@import mixin;就可以了。

使用mixin：

// index.scss
@import 'common';  // 引入common，如果有需要，common里一样可以引入mixin
@import 'mixin';  // 引入mixin

.g-index {
  ...
}

<!-- index.html -->

<!DOCTYPE html>
<html>
<head>
  <title>index</title>
  <link rel="stylesheet" type="text/css" href="./style/index.css">
</head>
<body>
  ...
</body>
</html>

2、common.scss

好，抽离了mixin之后，我们现在来重新看回common，common里应该是些什么样的内容。上面的内容我们稍稍提到了一点，我们来展开一下。

2.1、css reset(normalize)

我们知道浏览器千差万别，各浏览器的默认样式也是不尽相同，最常见的比如body的默认内边距，p标签的默认内边距，以及ul/ol等等。这些不统一的默认样式经常让我们感到头疼，所以就有人提出一开始写样式就先把它们消除的想法，于是就催生了后来非常流行的reset.css。

起初的reset.css很简单，大概是这样的：

html, body, h1, h2, h3, h4, h5, h6, p, dl, dt, dd, ul, ol, li, p {
  margin: 0;
  padding: 0;
}

没错，就是把几乎所有会用到的标签都给去了内边距和外边距，简单粗暴，这样所有的标签就都统一了，而且在不同的浏览器下也是统一的。

其他的部分每个人有各自的补充，比如有人会把h1～h6的所有字号给定义一遍，以保证在不同浏览器下他们有统一的大小；有人会给a标签设置统一的字体颜色和hover效果，诸如此类等等。

很好，没毛病。我们把这些统称为css reset，然后再统一封装到一个叫做reset.css的文件中，然后每个页面都引用。

这种方式一直以来都挺实用，而且大家也都这么用，没出过什么问题。只是后来有人提出，这种方式太过粗暴（居然还心疼浏览器了）。。。而且会降低页面渲染的性能，最重要的是，这使得我们原本设计出来的表达各种含义的标签儿们，变得毫无特点了。。。

说的好有道理，如果你家里所有人名字不一样但是都长一个样，还有啥意思。

于是，就出现了normalize.css，normalize的目的同样是为了统一各个浏览器下各不相同的默认样式，不过它并不是简单粗暴地全部抹平，而是根据规范，来人为地把那些不符合规范的默认样式“扶正”，从而达到统一各个浏览器默认样式，同时保留各个标签原有特点的目的。

我们不能说reset与normalize这两种思想孰好孰坏，只能说各有各的特点和作用，它们的存在都是为了解决同样的问题。

2.2、插件

一般来说，一个ui插件都会至少包括一个css文件，像bootstrap、datepicker等等。假设我们项目中需要以bootstrap为基础框架，实现快速开发，那么这时候我们就需要在项目中全局引入bootstrap.min.css，当然，还有bootstrap.min.js。说到全局暴露，我们第一时间想到的是common，没错，我们可以在common中引入。

有人问，插件的.css文件怎么import？额，改一下扩展名为.scss就可以了，scss是兼容原生css语法的～

所以最终，我们的common大概是这样子的：

// common.scss

@import './reset';
@import './bootstrap.min';
@import './mixin';

事实上，如果我们不需要使用到 mixin.scss 中的变量和mixin的话，我们可以不引用它。

那么我们的页面scss应该是这样的：

// index.scss

@import './common';
@import './mixin';

.g-index {
  ...
}

干净，整洁。

3、mixin编写规范

每添加一个新角色，我们就要及时给它设置规范，好让它按照我们的期望工作别添乱。我们接下来来归纳一下mixin的书写规范。

Szenario 1: Es gibt drei Dateien im Projekt: mixin.scss, a.scss (vorausgesetzt, es handelt sich um eine bestimmte Funktionsdatei) und index.scss. In mixin sind eine Variable $fontSize: 16px; ist in a. definiert: #ccc;, wir referenzieren diese beiden Dateien gleichzeitig im Index, dann können wir die beiden Variablen $fontSize und $color direkt im Index verwenden – ich meine, obwohl wir es nicht sehen der Index zur Deklaration und Definition dieser beiden Variablen, aber sie existieren einfach.

Ist das eine gute oder eine schlechte Sache? Mein Bauchgefühl sagt mir, dass möglicherweise etwas nicht stimmt. Ja, ähnelt das der Umweltverschmutzung, die wir zuvor besprochen haben? Nachdem wir zuvor auf common verwiesen hatten, waren viele Modulnamen im Index belegt, bevor etwas geschrieben wurde. Da wir nun auf andere Dateien verwiesen haben, waren viele Variablennamen im Index belegt. Darüber hinaus ist dies aus Wartungssicht problematisch. Wenn ich es Ihnen nicht im Voraus sage oder Sie das Mixin und a nicht im Voraus lesen, wissen Sie, woher die $color im Index kommt? ? Angenommen, wir benötigen die Schriftgröße. Wissen Sie, welche Datei geändert werden soll? Wie stellen Sie außerdem sicher, dass es beim gleichzeitigen Verweisen auf mixin und a möglich ist, dass zwischen ihnen eine Variable mit demselben Namen vorhanden ist? Wer deckt also wen ab? Diese Probleme mögen klein erscheinen, aber wenn der Umfang Ihres Projekts groß ist, kann dies eine irreversible Katastrophe sein (wem machen Sie Angst???).

Szenario 2: Angenommen, unser Projekt hat eine Designfarbe. Der Rahmen, der Tab-Hintergrund, der Navigationsleistenhintergrund, die Schriftfarbe usw. sind alle diese Designfarben. Aus Gründen der Benutzerfreundlichkeit möchten wir nicht immer den Farbwähler verwenden Holen Sie sich den Wert, also definieren wir eine globale Variable $color: #ff9900 im Mixin, und dann können Sie sie problemlos überall verwenden!

Nachdem die gesamte Website entwickelt war, kam der Designer einen Monat später plötzlich zu Ihnen und sagte zu Ihnen: „Der Chef sagte, dass diese Themenfarbe geändert werden muss. Sie ist etwas erdig. Ändern wir sie in leuchtendes Rot.“ Zögernd, aber heimlich mit Freude im Herzen, änderte den Wert von $color in leuchtendes Rot und sagte dann stolz zum Designer: „Zum Glück habe ich es vorbereitet, und es ist fertig. Schauen Sie es sich einfach an.“ Öffnen Sie die Seite und sehen Sie, dass der Designer und Ihr Gesicht grün geworden sind. Warum ist die Seite ursprünglich so hässlich, aber der Hintergrund war rot, aber jetzt, nachdem er geändert wurde, wurde der gesamte Block rot , und der Inhalt war ursprünglich schwer zu erkennen, aber die Schriftart ist die ursprüngliche Designfarbe, aber jetzt wurde sie geändert und der Rahmen und die Schriftart sind rot geworden.

Designer: „Nein, nein, nein, ich möchte nur die Hintergrundfarbe ändern.“ Sie: „Haben Sie nicht gesagt, dass Sie die Designfarbe ändern sollen? Das sind alle Stellen.“ Designer: „Nein, ändern Sie einfach den Hintergrund.“
Sie: „Auf keinen Fall...“
Designer: „Warum nicht? Warum nicht einfach die Hintergrundfarbe ändern? Ändern Sie sie einfach wieder entsprechend Ihrer Einstellung.“ Sie: „Es ist nicht so einfach, wie Sie denken...“

……

Okay, ich bin nur hier, um dir Angst zu machen. Wenn du wirklich gut darin bist, wird das keine große Sache sein.

Wir müssen also (globale) Variablen verwalten, genau wie wir es mit Mixins getan haben. Wir können sie nicht überall definieren, noch können wir eine globale Variable jederzeit ändern:

Globale Variablen werden nur im Mixin definiert. Variablen, die in anderen SCSS-Dateien definiert sind (unabhängig davon, ob sie global oder lokal verfügbar sind), werden nur als lokale Variablen betrachtet und nicht außerhalb der aktuellen Datei verwendet (auch wenn auf sie verwiesen werden kann, vermeiden Sie die Verwendung).

2. 
   

   Importieren Sie Mixin direkt dort, wo globale Variablen benötigt werden

4. 
   

   Im Allgemeinen sollten globale Variablen mit Vorsicht definiert werden und die Anzahl globaler Variablen sollte so gering wie möglich sein > Wenn sich die Anforderungen ändern, fügen Sie bitte eine globale Variable hinzu, um die zu ändernden Teile schrittweise zu ersetzen

5. Verwenden Sie keine zu allgemeinen Substantive wie Farbe. Es wird empfohlen, die Beschreibung des Farbwerts direkt zu verwenden, z. B. $orange: #ff9900. Dies erleichtert uns die Pflege und Erweiterung des Farbwerts Es muss geändert werden, dies ist jedoch nicht der Fall. Alle Stellen müssen geändert werden. Anschließend können wir eine neue Variable definieren, um sie zu erweitern, z. B. $red: red.

6. 
   Diese Punkte klingen etwas unberechenbar. Tatsächlich ist es wirklich schwierig zu erklären, warum wir dies tun sollten. Schließlich handelt es sich bei allen um Zusammenfassungen von Erfahrungen. Sie sollten sich also lieber eine Zeit lang mit der Verwendung von Sass vertraut machen, bevor Sie darüber nachdenken diese Themen im Detail.

Beachten Sie, dass es sich bei den oben genannten Regeln nicht um starre Regeln handelt. Irgendwann muss diese Spezifikation basierend auf tatsächlichen Projekten angepasst werden, wie beispielsweise dem SPA, über das wir später sprechen werden. Es gibt kein perfektes Projekt und auch kein Entwicklungsmodell, das auf alle Projekte anwendbar ist. Nur durch die Anpassung der Maßnahmen an die örtlichen Gegebenheiten können wir Probleme besser lösen. Darüber hinaus ist keines der bisher genannten Probleme schwerwiegend. Die schwerwiegenden Probleme konnten bei der Formulierung der Spezifikationen im vorherigen Abschnitt vermieden werden.

7. Modul aufrufen

Frage, wo soll das Modul aufgerufen werden?

8. Antwort, Seite scss.
   

   在页面scss中调用模块是一个好习惯，它使得我们在每个页面所用到的模块既是一致的又是互相隔离的，不像在common中直接引用模块那样，使得一个页面scss还没有内容的时候就已经被很多模块名污染了。

   再提个问题，在页面scss的哪里调用模块？

   例一，根类外：

   // index.scss
   
   @import './common';
   @import './mixin';
   
   @include m-nav;
   @include m-news;
   @include m-copy_right;
   
   .g-index {
     ...
   }

   例二，根类内：

   // index.scss
   
   @import './common';
   @import './mixin';
   
   .g-index {
     @include m-nav;
     @include m-news;
     @include m-copy_right;
   
     ...
   }

   目前为止，这两种方式都是可以的，至于我为什么用“目前为止”这个词，那是因为我们后面将要讲到的SPA，如果用例一的方式是有问题的。所以我比较鼓励使用例二的方式。当然，我说了，目前为止例一也是没问题的。

   性能优化

   目前为止，我们的模块化工作已经算是完成了，其实已经可以收工了。不过我们还是可以稍微做一下优化。

   1、缓存

   我们需要考虑一个问题：缓存。

   缓存是我们web开发中最常见的情况之一，很多时候我们都需要跟缓存打交道，特别是在做性能优化的时候。

   一般来说，静态资源在被加载到浏览器之后，浏览器会把它本地缓存下来，以便下次请求同个资源的时候可以快速响应，不需要再去远程服务器加载。

   我们就css来说，假设我们按照原来的方式，使用多个link去加载reset、bootstrap、common、index这几个文件的话，这几个文件都会被缓存下来，以使得下次再访问这个页面，这个页面的加载速度会快很多。

   如果是从index页面跳转到about页面呢？你会发现也很快，因为about页面的全局css（reset、bootstrap、common）和index页面是一样的，而它们在你访问index的时候，已经加载过了，得益于缓存的作用，之后的页面打开都快。

   我们现在的方式是，一个页面所用到的所有css文件都被合并成一个，也就不存在相同的文件可以利用缓存这样的优势了。

   那我们有办法改进吗？有的！我们只需要把common独立出来，那么common就可以做为被缓存的公共文件了。最终我们从一个页面只引用一个文件变成了一个页面引用两个文件，即common和页面css：

   // common.scss
   
   @import './reset';
   @import './bootstrap.min';
   @import './mixin';

   // index.scss
   
   @import './mixin';
   
   .g-index {
     ...
   }

   注意，不同于之前，我们这里的index.scss不再引入common.scss，所以我们最终是得到了两个css文件，而common.css是在所有页面中通过link标签引入的。

   如此一来，我们就实现了既能够合并文件，减少请求数，又可以利用缓存，提高加载速度。

   2、压缩

   代码压缩是优化工作中最基本的一步，css的压缩空间是很大的，尤其是我们这种 垂直的书写方式 ，压缩起来是相当高效的。

   在sass中这很简单，sass在编译的时候提供了几种模式，其中的compressed模式是最高效的压缩模式，记得在编译打包的时候选择compressed模式就行了。

   总结

   总的来说，预处理语言在使我们编程更加美好的同时，也使得规范更加的完善。在css本身无法实现的情况下，我们通过工具来完成了模块化开发。

   我不会讲如何去安装和配置sass环境，因为这些w3cplus sass guide有详细的介绍了，建议使用nodejs的方式，不会捣鼓nodejs/npm的前端不是好前端。

   最后，我们回到一开始提到的问题——为什么要模块化？现在我们可以先从css的工作来回答，从某种意义上讲，模块化提高了我们编程能力和解决问题的能力，使得构建一个庞大而可扩展可维护的项目成为可能，使得我们能够以架构的思维和眼光去搭建整个项目。

Das obige ist der detaillierte Inhalt vonModulare Praxis der CSS-Vorverarbeitungssprache. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!