菜单

有关前端组件化开采的一点商讨

2019年5月2日 - JavaScript

前端 UI组件化的部分心想

2017/04/10 · 基础才干 ·
组件化

原来的小说出处: 王一蛋   

新近商家推起了共用 UI 组件化的大潮,创设了一个新的 Repo 来放置共用的 UI
组件,比方下拉菜单等。出于对历史版本的表单组件的缺憾,作者从两周前起初踏上了谐和的
React
表单组件制作之路,踩了成都百货上千坑也有了成都百货上千清醒,之后也会写1篇文章关于自个儿是怎样写那几个组件的(对
React 感兴趣的能够点这里
Hyo
华语文档)。之后公司群里分享了那样1个演说录制:Best
Practices on building a UI component library for your company (David
Wells) – FSF
2016

,看完之后感触良多,本文算是该发言内容的三个大要与探求。

回去正题,倘诺您在2个重型集体育专科高校业,或许你的营业全数不少部门,你们该如何落成全局
UI
组件来赶过各类板块的界限?想象3个景色,假如您的全方位公司都在利用同一段
UI
代码处理公共组件,财务工具在采取它,博客工具在选取它,在线聊天工具在运用它,且不论在移动端,桌面端还是web
端都能收看它,那该有多方便?无需累赘而复杂地2次又3回达成效益看似的表单,按键或是列表。那是三个相对能够的装置,因为不论是你在何地你都只需求维护一个代码库,且具备全局财富也都在同三个地点,开辟者们得以便宜地找到所需的代码并对其进献。同时,共享
UI
组件同事也会给你的用户带来相容的经验,无论她在浏览或选取哪个工具,移动端或是桌面端,他的所见所感都以相平等的。注意的是同步这一概念,对于有着不少成品的集团来讲若是共享
UI ,这就表示三次 UI
进级总体集团的出品都会受其震慑。那从半数以上含义上的话是一件善事,但有时候又会带来大多麻烦,之后会谈到。同时你的机件也相应是万事俱备的,不与任何你所在团队所使用的第2方包相顶牛。综上,怎么着陈设你团队产品的
UI
架构,使得其具备上述优点的还要还有卓绝的可扩展性与脾性,是大家前几天所要切磋的重要。

在本文中,大家首要利用 React 作为UI组件化的例子,将页面细分组件化是
React 的主干工学,大家得以相当便利的将本文中的观念引进个中。

大家先来看贰个有关 UI 设计指南标准的例证,这是 Salesforce 的 UI 库
Lightning Design
System
,他给了越发详细的
UI
规则,各样产品的页面、组件应当如何被管理,万分值得大家学习与借鉴。先来看二个style guide 应当有些什么内容:

  1. 文档 由你团队成员所写的,若是利用 React 你能够直接通过注释
    Proptypes 的措施,通过 React-docgen 生成文书档案。
  2. 代码预览
    你应有提供1个能够让开拓者实时调节和测试代码的地点,使其余这几个零件的使用者能够更加好地通晓各样props
  3. 运用实例 提供一些怎么着将其数量导入 UI
    的实例代码,使别的开荒者能够越来越快上手与她们的应用状态。
  4. 相容性
    譬如怎么样使用警告、载入新闻等额外内容的正统,来提供用户相平等的体会。

那么,如何搭建三个组件库呢?为了酬答这几个难点我们能够将其细分为如下多少个小步骤:

  1. 将一体化的难点拆开成细目。
  2. 什么样管理 CSS ?
  3. 怎么将资源如变量,Logo等公有化?
  4. 怎么样将其包装,便于使用?
  5. 始发从中获得受益!

首先,大家现讲如何将难点拆解,我们应有将页面上显示的整个看作是组件。也正是说每当你得到设计员的稿子,第2件事应该就是讲页面上任何你所能看到的元素翻译成无数个小组件,那也是
React 的理念:复用组件。

图片 1

下一步,我们再将小组件组合成为很大的零件。这里不得不提到 Brad Frost
所提议的 Atomic
Design
。它所阐释的眼光与本文所要说的观点相似,即由“原子”组成“分子”,“分子”构成“组织”,从而产生模板,进而生成页面。看下这一个事例,标签,输入,按键各是叁个“原子”,合在一同即成了二个“分子”。

图片 2图片 3

其次, CSS
一向以来都以二个充足讨厌的标题。我们应该如何管理类名争辨?如何利用第1方库的
CSS 文件?怎么着确认保障与 CSS
文件不争执?怎么着保管相互独立?对于这个标题将来早就有了重重缓慢解决方案。

大卫 韦尔斯 在演说中提到的与我们公司前几日所选取的都以通过 PostCSS + CSS
modules的缓和方案。关于 CSS Modules 搭配 React
的用法,这里有个很好的事例:Modular CSS with
React

。具体来讲能够见此用例:

JavaScript

/* Thumbnail.jsx */ import styles from ‘./Thumbnail.css’; render() {
return (<img className={styles.image}/>) }

1
2
3
4
5
/* Thumbnail.jsx */
import styles from ‘./Thumbnail.css’;
render() {
  return (<img className={styles.image}/>)
}

JavaScript

/* Thumbnail.css */ .image { border-radius: 3px; }

1
2
3
4
/* Thumbnail.css */
.image {
  border-radius: 3px;
}

Hash 后转换的 HTML tag 与 CSS 看起来会是那般:

JavaScript

/* Rendered DOM */ <img class=”Thumbnail__image___1DA66″/>

1
2
/* Rendered DOM */
<img class="Thumbnail__image___1DA66"/>

JavaScript

/* Processed Thumbnail.css */ .Thumbnail__image___1DA66 {
border-radius: 3px; }

1
2
3
4
/* Processed Thumbnail.css */
.Thumbnail__image___1DA66 {
  border-radius: 3px;
}

这里将要大家 Thumbnail.jsx 文件中通过 CSS modules 引入 CSS
文件,再经过引进的 style 变量获取 hash 后的 CSS 类名。

这里提到的另1个工具 PostCSS
会将您的css文件全加上前缀名以适应不相同浏览器,化解 CSS 四 的包容性难点。

于是你真的须要利用 PostCSS 和 CSS Modules
么?你可以问本身如下难题:你在二个团队江西中华南理历史大学程企业作么?你使用第1方库的 CSS
文件么?你的成品在第贰方景况中运转么?你想要你的制品在别的条件中感受一致么?借令你回答是,那你能够选择尝试这一方案,因为这1缓慢解决方案基本减轻了类名争辩与浏览器包容的主题材料。

第三,关于如何管理共享财富。对于全局变量与 mixin ,我们提出通过几个PostCSS
的插件来化解,而非使用sass等预管理器语言。能够由此二个轻便易行的Postcss
config来讲解:

JavaScript

var vars = require(‘postcss-simple-vars’); var mixins =
require(‘postcss-mixins’); var postCSSConfig = [ mixins({ mixins:
require(‘./mixins’) }), vars({ variables: require(‘./variables’) }), ]

1
2
3
4
5
6
7
var vars   = require(‘postcss-simple-vars’);
var mixins   = require(‘postcss-mixins’);
 
var postCSSConfig = [
  mixins({ mixins: require(‘./mixins’) }),
  vars({ variables: require(‘./variables’) }),
]

此间我们从多个 mixins.js 文件中提取全局mixin,3个 varibles.js
文件中领到全局变量,他将会在您有所通过 PostCSS 编写翻译的 CSS
文件中生效。实际使用中与less和sass十三分相似,见例:

JavaScript

.hyo { @mixin MarsPower; /* 在 mixin.js 文件中定义 */ color: $MarsRed;
/* 在 variables.js 文件中定义 */ }

1
2
3
4
.hyo {
  @mixin MarsPower; /* 在 mixin.js 文件中定义 */
  color: $MarsRed; /* 在 variables.js 文件中定义 */
}

对于图标,由于其轻量型与便利性大家一般采纳svg。基本的干活流程是由设计员营造 svg ,在你的 JS 代码中引进 svg ,通过
’webpack-svgstore-plugin’ 优化 svg 并生成 sprite ,将 sprite 注入 DOM
。此处我们能够行使 svg use 标签,格局如:

XHTML

<svg><use id=“icon-aaa”></svg>

1
<svg><use id=“icon-aaa”></svg>

第4步,也是最终一步,我们应当怎么样搭建以及包装?

率先,大家有那二个多的工具来驱动开拓 React
组件变得令人心情高兴,推荐多少个常用的第2方库:
carte-blanche
那是个越发牛b的 React 开拓工具,只需简单几步就可已在浏览器中测试你的
React 组件,同时还协助随机生成 prop 来测试你的组件会不会应为 prop
万分而夭折。
react-storybook 那是三个 carte-blanche
11分相似的精选,也是自己用来开采
Hyo
的工具。
react-docgen
文书档案生成工具,你能够平素导入三个react文件夹,假若你在proptype中谢了疏解它将会自动为您转移文书档案。

在本子更新时,注意利用语义化版本。每当你要起首写2个新的营造时,能够先在
Github 上搜求一下先行者的达成格局,站在圣人的双肩上干活才会一箭双雕。

最后,关于怎么样打包,DW 推荐的艺术是之类文件结构:

图片 4

对此小编表示非常的赞同。分开打包每种小的零件入口,扁平化你的文本结构,组件之间能够相互信赖使用,对于开荒成效与增添化才具尤其有帮扶。

稍许时候很难去查看你在哪个页面使用了哪些组件。这里您能够选拔四个监视器组件来查询你利用的机件。那在多数时候特别便宜,譬如你想升官某贰个零件,你会想去明白如何页面或是组件正视了那几个组件从而进行改换,DW
提供了2个完成,我们可以根据大家的供给来兑现和睦的 Monitor Component。

图片 5

提及底的最后,小结多少个开荒 React 组件中常遇见的难题。(至少作者是赶过了-
-)首先,做事先想明白要完结的
Feature,与设计员探究并写下团结的须求,市面上是不是有可用的代替品,尽只怕不要定义过多的
prop,不然在今后维护会相当麻烦。其次,尽大概地给予使用者客制化的权利,譬如内容什么渲染,排序如何进展等,最棒开放二个api
使得使用者可以友善定义,因为您永恒无法预测并满足全体使用者的急需。第二,在装有浏览器上拓展测试,沉滓泛起了但偶尔依旧会忘。最终,从初叶便定义好
lint 的规则并依照它,能够参考
AirBnB
的布置作为起初点。

啰里啰嗦写了这么多,希望我们都能从中能收获些许。最终再安利一下
Hyo,也总算自己的率先个认真做的开源项目,希望大家多多点星!
|
Demo点这里
|
文书档案点这里
|

1 赞 1 收藏
评论

图片 6

前端开荒与其余程序开垦的共性在于,同样供给“高内聚,低耦合,易读写,可复用”。

“高内聚”是指就要逻辑上能够分类为1个单元的代码封装在协同,尽量有限支撑1块代码集合首要化解3个须求,在前端开辟中,最广泛的就是将一个逻辑单元的代码应用IIFE函数实行包装。

能够说,有限支撑代码高内聚即在料定程度上满意了代码“低耦合”的渴求,因为低耦合正是供给二个逻辑单元的代码块在转移时,不会产生任何逻辑单北齐码块的改变,在前端开辟中,便是须求各代码块不要过多共享某变量或对象,在不足以的动静下,一定要清楚注释。

“易读写”是指保持代码的可读,可修改性,即在一定时期后,后来的开采者还是能够借助阅读代码的点子,掌握您的编制程序思路,并基于新的急需,修改你留给的代码。这里牵扯到理想的代码缩进,命名标准,注释等。

“可复用”是指处于节省技士生命的目的,遵从D福睿斯Y原则,在3个类型中,抽象出效益看似的职业要求,通过组件化的点子编写代码,完成只写二回,到处使用的令人高兴的目标。


组件的组合:

  一. 代码层面: HTML(结构)+ JS(逻辑) + CSS(样式)

  二. 采取范围: 必要铺排参数 + 实例化相应组件对象

上边贴一张本人自己总结的有关组件化开荒的脑图:

图片 7

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图