[散修弟子]JS-1721|2018年12月01日的日报-技能树.IT修真院

发表于： 2018-12-01 22:29:25

1 804

今天完成的事情：看了一些CSS架构的知识点

明天计划的事情：（一定要写非常细致的内容）
遇到的问题：（遇到什么困难，怎么解决的）

收获：触及到了前端人员灵魂之一，尽可能的“懒”。（提高代码的重用性）方法太多，就说其中两种：

1.CSS样式分离之再分离

组成CSS通用样式库

“CSS样式分离之再分离”表型上的两个特点为“分离”和“命名”，掌握与理解其深层次思想的关键是思维方式的转变，这包括“CSS库概念”意识。举个例子吧，依照现在主流的写法，下截图所示的灰色背景的框框命名与样式可能如下：

.topic_edit_box{display:inline-block; border:1px solid #ddd; background:#f7f7f7; padding:20px 40px;}

如果您有强烈的分离意识，尤其在大型的项目中，这段样式可能会是这个样子（注意命名）：

.dib{display:inline-block;}
.bdd border:1px solid #ddd;}
.bgf7{background:#f7f7f7;}
.p20_40{padding:20px 40px;}

字面上很容易理解，就是把这段样式分离成一个一个单独的样式。当然，这只是表象，要想让样式再分离发挥其最大的功效，对其精髓思想有着较为深入的理解是很必须的，否则，您可能会用的很痛苦，或是滥用而产生其他一些问题。

2.使用一致的类命名空间

CSS 对类名及其他标识符（如 ID、动画名称等）都有一个独立扁平的命名空间。就像过去在 PHP 里，其社区想通过简单地使用更长且具有结构性的名称来处理这个问题，因此就效仿了命名空间（BEM 就是个例子）。我们也想要选择一个命名空间规范，并坚持下去。

比如，使用 myapp-Header-link 来当做一个类名，组成它的三个部分都有着特定的功能：

myapp 首先用来将我们的应用和其他可能运行在同一个 DOM 上的应用隔离开来
Header 用来将组件和应用里其他的组件隔离开来
link 用来为局部样式效果保存一个局部名称（在组件的命名空间内）

作为一个特殊的情况，Header 组件的根元素可以简单地用 myapp-Header 类来标记。对于一个非常简单的组件来说，这可能就是所需要做的全部了。

不管我们选择怎样的命名空间规范，我们都想要通过它保持一致性。那三个类名组成部分除了有着特定功能，也同样有着特定的含义。只需要看一下类名，就可以知道它属于哪里了。这样的命名空间将成为我们浏览项目样式的地图。

原文地址：8 simple rules for a robust, scalable CSS architecture
原文作者：Jarno Rantanen

看了上面这两种方法我觉得可能有些地方不兼容，也可能会有人早就已经把他们融合至一体并用的很好，作为一个小白我只能选择其一，并把对自己确定有用的知识点吸收，下面就是我觉得非常好的。

总是类名优先

这是显而易见的。

不要去使用 ID 选择器 (如 #header)，因为每当你认为某样东西只会有一个实例的时候，在无限的时间范围内，你都将被证明是错的。一个典型的例子就是，当想要在我们构建的大型应用中修复任何数据绑定漏洞的时候（这种情况尤为明显）。我们从为 UI 代码创建两个实例开始，它们并行在同一个 DOM，并都绑定到一个数据模型的共享实例上。这么做是为了保证所有数据模型的变化都可以正确体现到这两个 UI 上。所以任何你可能假设总是唯一的组件，如一个头部模板，就不再唯一了。顺便一提，这对找出其他唯一性假设相关的细微漏洞来说，也是一个很好的基准。我跑题了，但这个故事告诉我们的就是：没有一种情况是使用 ID 选择器会比使用类选择器更好，所以只要不使用就行了。

同样也不应该直接使用元素选择器（如 p）。通常对一个属于组件的元素使用元素选择器是可以的（看下面），但是对于元素本身来说，最终你将会为了一个不想使用它们的组件，而不得不将那些样式给撤销掉。回想一下我们的主要目标，这同样也违背了它们（面向组件，避免折磨人的层叠（cascade），以及默认局部化）。如果你这么选择的话，那么在body上设置一些像字体，行高以及颜色的属性（也叫可继承属性），对这个规则来说也可以是一个特例，但是如果你真正想做到组件隔离的话，那么放弃这些也完全是可行的（看下面关于使用外部样式的部分）。

所以在极少特例的情况下，你的样式应该总是类名优先。

组件代码放在一起

当使用一个组件的时候，如果所有和组件相关的资源（其 JavaScript 代码，样式，测试用例，文档等等）都可以非常紧密地放在一起，那就更好了：

ui/
├── layout/
|   ├── Header.js              // component code
|   ├── Header.scss            // component styles
|   ├── Header.spec.js         // component-specific unit tests
|   └── Header.fixtures.json   // any mock data the component tests might need
├── utils/
|   ├── Button.md              // usage documentation for the component
|   ├── Button.js              // ...and so on, you get the idea
|   └── Button.scss

当你写代码的时候，只需要简单地打开项目的浏览工具，组件的所有其他内容都唾手可得了。样式代码和生成DOM的JavaScript之间有着天然的耦合性，而且我敢打赌你在修改完其中一个之后不久肯定会去修改另外一个。举例来说，这同样适用于组件及其测试代码。可以认为这就是 UI 组件的访问局部性原理。我以前也会细致地去维护各种独立的镜像文件，它们各自存在 styles/、 tests/ 和 docs/ 等目录下面，直到我意识到，实际上我一直这么做的唯一原因是因为我就是一直这样做的。

网站通用小图标样式集

小图标的样式合并是普遍处理的较好的，由于其规律可循，所以经常在CSS文件较上的位置看到有关小图标的CSS合并样式，这在SNS网站中很是常见。一般合并样式部分样式为{background:url(xx.png) no-repeat;}，分离部分的样式是{background-position:x, y;}，就实现而言，我觉得没有多少说头，只是命名有些自己的见解。在小图标样式命名的时候，我的建议是不要关联图片的内容，比如说一个相册的下图标，不应该使用iAlbum这样的命名。原因有三：

1. 思考图片的命名杀死n多脑细胞
2. 命名较长，占用字节数，也就是CSS文件大小
3. 也是最重要的，后期的维护。设想下，如果日后相册的图标不再被使用了，原来相册图标的位置可以被其他小图标（如RSS小图标）替换吗？理论上可以，实际上，我们除了必要的html替换，还需要重新修改图标样式的命名，即iAlbum→iRss的命名，而往往取而代之的做法是直接在后面添加新的图标。

我目前的做法是使用一个不常用的标签作为网站的小图标专用标签，例如s标签，或是u标签，我习惯将小图标单独为一个小图标Sprite，每个图标放在20*20像素的格子中。在这种情况下，我都是使用矩阵命名法。命名只关联位置，例如，我使用u标签作为整个网站的小图标专用标签，则按照图标的位置（假设一行20个图标），我会依次命名为：u00,u01,u02…u019,u10,u11,…u119…。这种命名的好处是不用关心到底哪个位置是那个图标，不用担心命名冲突，在小图标位置以及内容更换的情况下也无需重命名。