sass 模块化开发

sass
sass语法
Sass-嵌套
#main p {
color: #00ff00;
width: 97%;

.redbox {
background-color: #ff0000;
color: #000000;
}
}
Sass-变量定义
$width: 5em;
#main {
width: $width;
}
Sass-判断语句
p {
@if 1 + 1 == 2 { border: 1px solid; }
@if 5 < 3 { border: 2px dotted; }
@if null { border: 3px double; }
}
Sass-循环语句
@for KaTeX parse error: Expected '}', got '#' at position 30: …gh 3 { .item-#̲{i} { width: 2em * $i; }
}
Sass-mixin函数
@mixin large-text {
font: {
family: Arial;
size: 20px;
weight: bold;
}
color: #ff0000;
}
模块化开发
为了让一整个庞大的项目看起来整整齐齐，规规整整而出现的模块化管理，我们常见的三种模块化管理的库： requireJS、seaJS、commonJS规范 ( 注意，这里的commonJS不是一个库，而是一种规范) 逐渐的在我们日常的开发中出现。 同时依赖于 这三类规范而出现的一些构建工具
1-1、模块化第一阶段
在这个阶段中，我们常常会把非常多复杂的功能 封装成一个个的函数：
但是当 整个项目变大了以后，就会遇到很多问题，都是定义的全局变量，形成了比较严重的污染，还有可能会出现因为重命名导致的各种问题。所以这些是需要进化的。所以就会进入到模块化的第二阶段： 对象。
1-2、封装到对象
到了第二个阶段为了避免全局变量的污染，我们会将单个模块封装到一个对象内部。
这样我们就没个模块定义一个对象，在需要的时候直接调用就好了，但是这样也会存在一个问题 这样写的话会暴露全部的对象内部的属性，内部状态可以被外部改变
1-3、 对象的优化
后来，聪明的人类就想到了利用 立即执行函数 来达到 不暴露私有成员的目的
通过立即执行函数，让外部根本没有时间从外部去修改内部的属性，从而达到一定的防御作用。
CommonJS
CommonJS 的出发点： JS 没有完善的模块系统，标准库较少，缺少包管理工具。（虽然这些东西，在后端语言中已经是 早就被玩的不想玩的东西了） 伴随着 NodeJS 的兴起，能让 JS 可以在任何地方运行，特别是服务端，以达到 也具备 Java、C#、PHP这些后台语言具备开发大型应用的能力，所以 CommonJS 应运而生。
CommonJS常见规范
- 一个文件就是一个模块，拥有单独的作用域

• 普通方式定义的 变量、函数、对象都属于该模块内
• 通过 require 来加载模块
• 通过 exports 和 module.exports 来暴露模块中的内容
  总结 ： 通过这样的一个对比的例子就可以比较清晰的对比出 exports 和 module.exports 的区别: 1、当 exports 和 module.exports 同时存在的时候，module.exports 会盖过 exports 2、当模块内部全部是 exports 的时候， 就等同于 module.exports 3、最后 我们就可以认定为 exports 其实就是 module.exports 的子集。
  AMD 的 RequireJS 和 CMD 的 SeaJS 的差异
  > AMD推崇依赖前置，在定义模块的时候就要声明其依赖的模块. CMD推崇就近依赖，只有在用到某个模块的时候再去require.