内容简介:其实好久之前就想写一些东西了,从大二开始就'入坑'了前端,这样算来都有4年多了。话说刚入前端时,还是一个切图仔,什么是切图仔呢?就是在那个前后端未分离,jquery还是1.x,php还是最受欢迎语言的时代,你只需要将设计图还原成静态页面,然后在适当的位置留下替换符,就可以交给后端去处理上线发布了,真的是相当happy,没有这么多花里胡哨的东西。当时市面上流行着不少的前端UI库,比如最著名的bootstrap,由于当时接触了一个有大量冗余类名的bootstrap项目,导致一直对bootstrap有心理阴影(面
其实好久之前就想写一些东西了,从大二开始就'入坑'了前端,这样算来都有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
高阶组件,负责将数据层组件映射到显示层组件中,起到连接作用。
以上所述就是小编给大家介绍的《Re从零开始的UI库编写生活之规范制定》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 如何制定理想IaaS协议
- [译] 为复杂产品制定设计规范
- 超过制定宽度(或行数)显示...(或省略)
- 如何制定 Java 性能调优标准?
- 制定测试计划也要清楚项目范围
- “刷脸”支付强化安全管理 标准制定中
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
他们以为自己很厉害:12个企业管理陷阱
[法] 克里斯蒂娜•凯德朗 / 王倩 / 人民邮电出版社 / 2018-11 / 69.00元
本书讲述了震惊世界的150个企业管理失败案例,并从产品与服务定位、技术 创新、广告与营销策略、跨文化发展、融资战略到企业文化与员工管理等众多角度, 揭露了商场各种败局的内幕。作者以风趣的笔触讲述了国际知名企业和商界精英们 的惨痛教训,又以专业角度解读了这些失利背后的经济学和管理学因素,给读者带 来了启示。一起来看看 《他们以为自己很厉害:12个企业管理陷阱》 这本书的介绍吧!