Re从零开始的UI库编写生活之规范制定

前言

其实很久以前就想写一些东西了，从大二开始就'入坑'了前端，这样算来都有4年多了。话说刚入前端时，仍是一个切图仔，什么是切图仔呢？就是在那个先后端未分离，jquery仍是1.x，php仍是最受欢迎语言的时代，你只须要将设计图还原成静态页面，而后在适当的位置留下替换符，就能够交给后端去处理上线发布了，真的是至关happy，没有这么多花里胡哨的东西。

当时市面上流行着很多的前端UI库，好比最著名的bootstrap，因为当时接触了一个有大量冗余类名的bootstrap项目，致使一直对bootstrap有心理阴影（面对一大堆不知道什么意思的css类简直头痛）。

想法 SluckyUI

编写一个具备易记，易用，易开发等特色的高效UI库，其中这个UI库又细分为样式库和组件库，但愿这样将样式层解耦出来以后能在面对复杂的需求时表现得更加灵活。

这个UI库会整合各类优秀案例，好比参考bootstrap的命名方式并进行优化，参考各类优秀的想法并加以实践。

这个UI库就称为SluckyUI，引用自small-lucky，但愿能让你感到小幸运。

但愿达到的程度

样式方面尽最大可能与js解耦，能使用样式解决的地方就不用js，让写样式再也不成为负担，同时又具有必定的跨平台性质，减轻框架切换带来的负担，让开发者能专一于业务逻辑。

例如一个按钮，直接用样式去控制就可以知足绝大部分的需求，因此将经常使用的部分的样式进行整合就能够了，不必必须写成一个组件。

肯定样式库规范

样式方面将使用sass进行管理

命名空间

命名空间是一个样式库的重要根基，最出名的是BEM命名方式，但一味地使用BEM命名是难以知足全部需求的，到最后你会发现这html里全都是一串串难以记忆的字符串，会对后续的维护构成很大的挑战。咱们的命名须要知足易记，简洁，易用，规范这几点要求，咱们将所用到的样式类分为如下大概的几个类别。

基础样式-可以直观表达所需的样式

这类型的基础样式是咱们平时用得最多的样式，凡须要布局的地方就要用到，属性和值都很是重要，缺一不可，不然会严重影响可读性，因此采用这种对属性和值进行简写的命名方式。

.pt16{
    padding-top:16px;
}

.ta-c{
    text-align:center;
}

.d-f {
    display: flex;
}
...
复制代码

功能样式-特殊的构造或一些hack样式

这类型样式的特色就是将某一种功能封装成一个类，但这个功能用基础样式的方式去命名又不能直观表达，这个时候用所对应的功能去命名就再合适不过了。

//文字超出长度后显示省略号
.ellip {
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: nowrap;
}
//出现滑动条
.limit-screen {
    max-height: 700px;
    overflow-y: scroll;
}
复制代码

状态样式-涉及到组件状态的样式，如表示成功，失败，默认的状态

状态样式由属性/模块+状态组成，咱们的关注点是something & status

//普通状况
.c-success{
    color:green;
}
.c-fail{
    color:red;
}
.bg-warn{
    background-color:yellow;
}

//多状态的状况，可参照BEM规则
.color-警示状态-偏黑色{
    ...
}
.c-hint-b{
    color:#666;
}
.color-成功状态-偏绿色{
    ...
}
.c-success-g{
    color:green;
}

复制代码

模块样式

对于定制化程度很高的模块，则应该使用BEM命名

//如自定义的checkbox样式模块（为了方便使用了sass编写）
.checkbox-box-normalize {
    ...
    & .checkbox-hook {
        ...
    }
    & input {
        ...
    }
    & label {
        ...
    }
}
复制代码

组合样式

以上一种或几种样式的组合，但这种状况比较少，好比功能样式类.square，咱们一般会有好几个不一样size的square，因此能够根据size的不一样去命名这些异构的类，命名成.square36，.square72，.square96等等

肯定组件库规范

这里只是粗略地概括一下，详情会在《Re从零开始的高效React+Redux项目架构》中讲到。咱们的UI库暂时先仅仅关注显示层组件。

Display component

显示层组件，这一层的组件复用性最高，与业务的耦合程度最低。接收来自数据组件提供的数据，只关注UI与交互。

Data component

数据层组件，这一层组件与业务紧密关联，在项目中的复用性较低，但在项目间拥有较好的复用性，例如常见的登陆业务，彻底能够将登陆的业务逻辑封装成一个组件供咱们在不一样的项目中使用。

Highorder component

高阶组件，负责将数据层组件映射到显示层组件中，起到链接做用。

结尾

在规范的思想范围下就能够不断地添砖加瓦了。已经整理好的组件和文档已经更新在 SluckyUI 上，可能有些地方有更好的实现方案，或者须要斧正哈哈，在接下来的时间里会不断地更新与维护。

---

如下是本系列的编写计划

• 《Re从零开始的UI库编写生活之规范制定》
• 《Re从零开始的UI库编写生活之按钮》
• 《Re从零开始的UI库编写生活之表单》
• 《Re从零开始的UI库编写生活之表格》
• 《Re从零开始的UI库编写生活之加载进度条》
• 《Re从零开始的UI库编写生活之分页》
• 《Re从零开始的UI库编写生活之菜单导航栏》
• 《Re从零开始的UI库编写生活之消息弹窗》
• 《Re从零开始的UI库编写生活之步骤管理器》
• 《Re从零开始的UI库编写生活之面包屑》
• 《Re从零开始的webpack4实用向全实践》
• 《Re从零开始的高效React+Redux项目架构搭建》
• Re从零开始的后端学习之配置Ubuntu+Ngnix+Nodejs+Mysql环境