前言

其实好久之前就想写一些东西了，从大二开始就'入坑'了前端，这样算来都有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环境