大家好，今天很高兴能够参加百度外卖与IT168联合举办的百度外卖技术分享季主题活动。 今天我是第一期，后面还有其他百度外卖技术专家来分享。 关于前端、测试等一系列技术话题，也欢迎您继续关注我们的百度外卖技术分享季。 话不多说，让我们进入今晚的主题吧。
今天我们聊的话题是从零到一的组件库的设计与实践。 这个话题你应该很清楚。 作为后端工程师，平时的开发都离不开组件库。 像Ant Design、Element这样的组件库大家都很熟悉，但是如何自己设计一个组件库，或者说最佳实践是什么，今天我就借这个机会跟大家分享一下我在百度外卖的经验。
我先自我介绍一下。 我叫朱崇宇，来自百度外卖商业平台部。 以前在百度地图做后端相关工作，现在从事商业平台相关的后端开发和技术监督工作。
这是我们实现的基于Vue的github组件库。 这是地址。 如果您有兴趣，可以看一下。 虽然是在github上维护的，但是我们内部基本上都是使用的，所以对外并没有做太多的事情。 多宣传。
这个组件库目前的情况是，PC端组件有30多个，对应了大概有十几个朋友对这个库做出了相关贡献，仅此而已。
回到我们明天的主题，如何从零到一建立一个自己的组件库，这是我们明天的具体内容，首先是认知和目标，组件库规划，具体的架构设计和实践，最后是组件化的设计思想。
首先从认知和目标开始。 首先，要做组件库，我们首先要明白我们具体是做什么的。
这一部分具体包括什么是组件库，组件库的概念是什么，我们为什么做这个组件库，具体的利润有哪些，因为你们都是在公司，做的相关的事情也形成为公司带来一定的利润，具体能不能做到，或者说我们需要做什么，怎么做，什么时候，什么时候完成。
首先回到组件的话题，很多朋友在平时开发的时候可能会写一些组件。 我们将此类组件称为单一组件。 主要特点是没有任何限制。 比如我们的组件分为html、js、css这几块，如果你自己写一个组件，不需要太多的限制，但是如果你想实现一个组件库，你就需要知道整个组件库，长什么样子，相关的命名，一些开发规范，一些视觉交互的疗效以及具体的使用方法，都需要统一或者整体的考虑。
有的同学可能会说我直接开始写代码就可以了，但是上面需要指出的是，组件库不仅是技术性的，更是方法论性的，这一点极其重要。 接下来这个方法论我会详细给大家讲解一下。
我们后台可能有一句话。 当一个新的轮子落下时，前端必须再次实现已经实现的东西。 这是为了追溯一些历史。 最早，你需要使用一些相关的DOM操作。 库来满足后端需求，现在一些MVVM框架，比如我们的Vue、React等相关框架来实现这个，现在FRP在这些编程上可能有一些相应的做法，但是FRP这个块是否可以成为标准中的未来还需要时间的考验。 无论如何，在任何阶段，我们都需要实现N次某件事，这可能是组件。 组件可以提高我们具体的开发效率，但是对于任何具体的框架而言，组件都是必不可少的。
我们先开始讲上面提到的方法论相关的东西。 重要的是在正确的时间做正确的事。 为什么这么说？ 当您第一次考虑构建组件库时，您必须三思而后行。 大家应该很容易理解。 比如技术栈的生命周期以及发展趋势。 比如我可能不会基于Backbone构建组件库，它已经过时了，或者比较落后，或者不太流行。 此外，还要考虑我们业务的需求。
现在我们做这种组件来反馈业务。 如果行业或者相关社区已经有了优秀的轮子，你重复轮子或者你做出来的东西还是和别人不一样。 ，你的投入就会变成没有具体的产出，另外就是团队的构成，比如朋友是否掌握了具体的相关技术，或者团队朋友对一些技术栈的喜好等等，这些东西对我们来说也很重要。 具体执行此操作会产生影响。
我们具体的目标，我们在做具体的组件库的时候，目标一定要明确，内容是一个基础的组件库，就是它没有任何业务相关的逻辑，因为我们做组件库是为了指出复用，业务逻辑时时变化，但基础组件的交互却相对固定。 另外，组件的数量，整个库的容量，具体的形式，分布，以及提供给用户的方法，用户是可以使用其他一些复制或者在线资源的方法，另外就是维护人类的过程。
接下来我们先来说说在这之前如何对组件库做一个规划。
当我们说规划的核心是什么的时候，其实两个字就是选择。 选择是做什么、不做什么，工作如何划分，具体时间如何安排。
我们的组件库是技术组件库，不是业务组件库。 我们是做高频元件的，我们必须考虑为我们的业务开发高频元件。 它在商业上可能相对不受欢迎。 这种情况下你不会选择开发，也没有框架依赖，比如jquery等。 。 为什么没有框架依赖？ 相关框架会减小我们系统的规模。 另外，组件库本身不应该有特定的倾向，因为它是给开发者用的。 如果组件库有相关倾向，很可能会对开发者造成一些混乱。
再说说分工吧。 我们的组件库是一个团队合作项目。 这个组件库是集中在几个人身上还是你们每个人都有这样的情况？ 首先我们认为有必要结合一些业务项目。 ，我们不可能专职做这个事情，我们通常有业务发展，我们要保证投资，通过一些相关的设计方法我们会在质量上做出差异，我们必须执行具体的规范。
那么接下来就是具体规范的实现了，所以我给大家分享一下我们相关组件库的规范。 这件事对于组件库来说变得尤为重要，因为组件库可能是团队合作的产物，或者组件库本身是一个整体，必须有相关的规范。
我们感觉组件库的规范有很多。 我们来总结一下。 比如审查规范，组件库应该是什么样子，API应该如何设计，或者属性相关的东西应该如何设计，审查规范，另外就是代码规范，应该是什么代码，什么内容一种要遵循的代码规范，还有开发规范，大家开发的模型都是一样的，最后放到这个规范上，因为组件库本身就是一个生态，肯定离不开维护。 相应的维护也有系统的规范。
首先，这是一个基本规范。 可以看上一页的图片，代码规范和开发规范。 这部分是在组件库本身维度前面的。 我们可以对其进行一些限制。 首先，在我们的开发规范上面，具体我们是使用ES6来做的。 ESLINT 使用我们来自百度的特定代码规范。 你可以在百度FEX的github库中搜索相关的东西，做一些标准的检测。 我们最终的CSS语言是The LESS，说到规范，可能有朋友知道有一些规范，比如OOCSS和BEM。 社区中对于这个规范的意见并不是很统一。 现在的框架，比如Vue，可以通过作用域来隔离组件CSS与外部，或者可以使用CSS IN JS等相关技术来隔离这些CSS污染，比如BEM规范，这实际上会减轻一些相关的负担开发，因为它是与组件本身并行的状态。
从命名规范上来说，我们的组件库有可能有具体的组件名称，具体API相关的也会涉及到命名。 其实这也是一件比较困难的事情，因为首先你需要简洁明了。 要统一，相对来说，各个并行的组件，相似的名字一定要统一，一定要语义化，便于开发者理解，紧密遵循我们原来的相关命名。
贴一些案例，就是你可能能看到一些，比如我们列出的一些好的案例和不好的案例，你可以看一下。
对于组件库来说，它是基于一个框架的。 例如Ant Design就属于React相关的组件库。 Element是基于Vue开发的。 首先，框架本身的思想不一样。 相关的开发范式也不同，这些也是框架的不同规范。
比如你对Vue中定义的一些数据做了一些简单的处理，如果表达清楚的话，就没有必要去估计代码中写的属性/方法。 这也是我们推荐的形式。
最后是开发规范。 当然，有些朋友喜欢使用html/css/js这三个文件。 我们统一文件的格式。 首先它可以很好的用webpack做相应的分析。 我们这些底层具体来说，就是使用webpack来进行打包或者相关的开发。 另外webpack 文件结构，我们不会在Vue中编写样式分离。 我们将样式单独分离出来，这样可以更统一的使用一些相关的LESS变量。 方便，我们还需要统一一些工具库，DOM操作，以及一些通信相关的库。 我们会统一具体的动画库。 Vue上的动画库是transition。 我们还需要统一开发环境和展示站，最终的维护由我们提交。 这些相关的工作流程正在使用github。
上面可能说了很多跟规划、规范有关的东西，有一些跟我们之前提到的方法论有关。 下面重点给大家介绍一下具体的架构设计和工程内容。
您可以打开它并查看这张图片。 这就是我们具体的结构设计。 可以看到下面白色的部分是我们具体组件的容器，包括我们的Assets，比如图片字体等。 静态资源，DEMO是专门写组件文档的，对于每个组件来说都是一个单文件的Vue，我们的CSS只是说已经分离出来了，一些相关的工具库和一些相关的Mixins，左边的就是一个单文件页。 我们的组件必须有一个单页的显示站。 我们的开发环境和我们的文档是统一的，肯定离不开给这个组件库写文档。
但在开发过程中，却离不开例如调试。 我们将这两个过程结合起来。 这一切都是通过webpack完成的。 你可能很熟悉它。 发布方面，发布到特定的NPM。 我们开始做吧。 最右边这块是持续集成，就是我们提交代码的时候，不需要自动构建dist。 这是我们打包完成后提供给用户的一个具体文件。 我们不希望每次构建都是自动的，另外你在展示站上改了一个文档，希望你能手动更新。 这也是一个持续集成的工作。
我们来谈谈我们的 CSS 架构。 首先，我们已经提到我们是用这些语言编写的。 预处理首先需要具有环境适应性。 目前仅在组件内部生效，不会被其他组件使用。 事物被污染了，具体相关的相互作用必须统一。 我们的主题是可以更换的。 此外，还有一些其他高级定制。 本节提到了一个Bootstrap，你非常熟悉。 可能很多朋友还没有深入使用过他的实践。 这个库的内部实现相对微妙。 具体来说，我建议你看一下这个反码。 我们的实现也参考了Bootsrap。 有同学会问为什么不直接基于Bootstrap来做。 一开始我们就是基于这个来做的。 是的，但是你之前实际上会发现一些问题。 例如，如果您自己的站点最初广泛使用 Bootstrap，您可以为此做出一些定义。 比如btn-info这样的类名可能会被进行一些定制，如果我们直接在上面使用这个类名，肯定会被污染。 至于我们详细的样子，很大程度上是由我们的CSS决定的。 如果你是从组件库开始的，如果你是后端或者非常擅长设计的朋友，你可以自己制作一个，但是对于很多不懂设计语言或者其他情况的前端工程师来说，最好参考一些业界现有的语言，比如Material Design、Ant Design等设计语言。
你可以打开这张图片来看看。 这是CSS的具体结构。 首先，左边是与基础相关的。 可能是一些CSS。 例如Noramlize和Reset做了一些基础工作。 我们定义相关的颜色。 字体、图标、网格相关的东西。
中间可能会有一些Mixin，这是处理一些兼容写法的比较简单的方式。 在最左边，我们定义了一些转换。 这些类型包含与大多数组件相关的动画。 在 Vue 上，这是一个过渡，在 React 上。 也会有相关的动画组件方案，主要是我们的transition，定义了几个阶段。 例如，进入和离开类似于特定的阶段，做特定的事情。
颜色方面，必须为组件库定义一个主颜色，另外一个颜色是info，表示消息传输，success，表示信息或操作成功，warning，表示警告，error，表示错误。错误操作，相似的基本颜色必须明确定义。 在我们定义的从黑到白的一些颜色中，比如灰度，可以实现相关性较小的功能。
另外，左边这个是根据你的主色调来的。 您可以通过这些相关的表单对其进行一些操作。 这样，就会具体衍生出一些颜色。 具体的颜色就是他可以用这种东西来改变皮肤，也就是主题颜色的改变，可以简单的理解。 如果我们改变主颜色，所有组件的颜色都会相应改变。
我想先谈一个关于图标的问题。 LICENSE 非常重要，要看它是否来自 MIT。 如果是一些付费或者商业用途，个别图标是不允许你使用的，虽然我们是在做内部组件库。 ，我们在github上做这个，所以我们使用一个开源的图标库。 二是字体资源的包装或分散。 例如，您应该熟悉字体。 目前的图标字体都会有一些 svg, woff , ttc, 这样类似的文件，可以说这些文件就是你要加载的，具体去中心化社区有相关的方案，将所有图标一一分散到js文件中，当然上面是Svg，在这种情况下，如果你说的是单个组件，可以单独发布使用，用最小的体积将其分散的解决方案也是很好的。
说到动画，各个组件的动画行为在组件库的维度上可能会有所不同。 例如，当您将鼠标悬停在带有工具提示的某个元素上时，工具提示和弹出窗口可能会立即下降，但弹出窗口会较慢。 动画中会有一些差异，这可能是定义不同参数来做某些事情的有用函数。
本片我们使用了24个网格，在控制上相对来说更加精细。 （中文）现在我们的网格系统也支持FLEX-BOX，但是这个专门使用了LESS循环，这是非常可比的高贵实现。
但是我们的开发可能离不开组件库的文档，但这就是为了给你展示你的组件是什么样子，你的不同形态，在不同的应用场景下是什么样子。 另外，你的文档系统需要把代码贴出来，你的组件怎么用，你的组件实现你的疗效的源码是什么，组件的props属性是什么，API是什么，这是文档系统要做的事情对于组件库来说也是至关重要的。 这里我们使用自定义的vue-loader，它会同时显示我们的DEMO和代码，并在vue文件中写入markdown。 我们实现了一个开发环境、调试环境、展示站都有统一的效果。 另外，业界很多文档系统都是基于md的。 为什么我们要基于vue来做呢，因为md的代码上写vue没有高量提示。 这对于开发体验来说会有些混乱。 当然基于md的文件系统的复用性更好。 例如，如果使用react组件库，也可以使用文档系统作为基础设施。
大家可以看一下我们上面的具体源码，是这样写的，以及具体的代码编写形式。
文档系统主要使用markdown解析引擎和prismjs，用于高亮显示。 与highlightjs不同的是，它是运行时高亮，prism将markdown解析为特殊的html，我们编写相关的CSS。 可以很好的展示我们亮点的疗效。 还做一些正则化。 比如双括号需要做一些特殊的处理，Vue解析模板时会替换相关的解析结果。 ，这个不太好，有一些常规方面的一些处理。
我们来说说具体的工程，组件是怎么提供给用户的，给用户提供什么方法，组件是怎么做的，持续集成是怎么做的。
有两种方式向用户提供组件。 单一组件面临着如何处理公共资源的问题。 例如，如果您不分散ICON，则必须在组件中依赖ICON并比较版本。 问题是你整个组件库提供的版本和你单个组件的具体版本升级，如何处理这样的版本问题，组件之间相互依赖的问题，一个组件依赖于另一个组件，依赖的组件是升级后的版本，但依赖组件的依赖关系与之前的旧版本有很大不同，但整个库被打包并作为 JS 和 CSS 提供。 好处是你的整个组件库都是某个版本的。 在这种情况下，版本控制的压力较小，但您要处理的问题是代码大小。 整个组件库中有几十个组件。 你如何根据需求做到这一点？ 我只需要加载某个组件。
我们这里的选择取决于我们具体的使用环境。 我们主要的用户，因为是内部的组件库，所以我们主要的运行环境是内部的平台。 在内部平台上，内部PC平台上，在这种情况下，我们的组件，比如说压缩之后，在带宽或者加载速度上不会有什么困难，所以最终我们把它们封装成这样的形式整个图书馆。
对于使用webpack的项目来说，提供源码是最好的选择，因为它可以让开发者看到你的源码是如何实现的。 比如说你做一些点播是非常方便的，但是对于我们的FIS，朋友们可能不知道有没有听说过。 它是百度内部完整的后端解决方案。 可以说它和webpack的一些功能有重叠或者竞争，但是两者的封装是不同的。 一定有区别。 FIS上也有一些按需解决方案，但有时使用起来不如webpack方便。 所以我们内部大部分都是FIS，也有一些同时使用fis和webpack，我们以包的方式提供给用户。
持续集成我们的项目在github上维护。 我们使用circleCI。 这样的系统相当于写了原来的代码，一些输出和一些显示站，并且组件库的输出会被手动更新。 这里我们有一个帐户，而不是一个具体的实体，因为在这种情况下，这种代码不是有意义的代码。 机器人就是这么做的。 在github的一些统计中，我们会避免一些不必要的事情，似乎很多情况下，比如代码提交，工作都交给了机器人的账户。
因为这一次已经有点结束了，接下来就是跟大家分享一些我们组件设计相关的想法。
首先看一下这张图，从基础组件到上半部分的分包。 比如看具体的反例就更容易理解了。 一个Input需要一个Icon，例如一个X。你可以使用这个如果清除了上面的其中一项，它可以演变为InputNumber，Suggession，Select，Datepicker等。所以这些基本组件对于一个组件库来说是必不可少的，因为如果不做基础组件的话，比如两个朋友直接开发一个select和一个datepicker。 这样的话，两个人写的输入就会持续很长时间。 这是最直观的痛点。 另外就是两个人输入自己的一些props，API也不同。 这样的话我们后期维护的成本就比较高，所以这是定义基础组件。 这个非常重要。
接下来是一些通用解决方案的分包和参考。 原来动画是静态的，接下来就是popper弹出层了。 可以使用许多组件。 我们最终选择了popper.js的方案，它可以说是位置引擎，比如中间的tooltip，黑色的提示，如果他遇到了屏幕的左边，他就会手动估计位置并将他塑造到相反的位置webpack 文件结构，即右侧。 例如，当您滚动群组屏幕时，右侧的选择会手动移动到前面，因此体验会更好。
另外，基于Vue本身，我们与VM有很多打交道。 我们使用这些插件，熟悉Vue的同学可能都知道，它是插件的形式，使用起来非常方便。 如果在我们的根节点APP上以插件的形式引入组件库，就会有挂载示例的方法。
比如分散数据的方法，上下两种形式，如果我可能是这样的话，就是像前面那样直接一个select，我用这个数据就可以了，比如LI模拟了option的方法，这样的话就是说我添加了自定义的能力，比如我想对上面的选项做一些样式处理，或者做一些数据处理，我就做不到，所以如果是这个的话上面提供的第一种方式比第一种定制方式更强。
这也意味着通过拆分组件来增加耦合，这是通过槽的方法来实现的。
以下是昨天的内容的总结。
首先，技术和方法论都在组件库里。 需要具体、深入的考察才能做出一些选择。 相关规范必须对团队的相关成员施加一些约束，相关的工作流程和团队成员必须做一些培训。
组件库的坑比较大。 除了我们纯粹写组件，一些文件系统，持续集成，还有我上面提到的，比如测试一些相关的工具链和一些国际化相关的东西，如果你想要创建一些非常大的开源组件库，这是不可避免的。 例如对于一些附加资源，它可以反馈一些UI设计。 可以参考这些组件库的相关交互。 今天的大致内容就这些了，一集，我们现在正在紧急招聘订餐后端，而且我们还在使用行业内比较新的技术，比如vue、react、react-native、nw.js等。等等，而且我们技术氛围很浓，你可以想一下，这是我的邮箱，我给你推荐一个公众号，百度外卖技术团队的公众号，你可以扫描二维码关注，还有我会不定期发一些技术资料，您可以关注文章。
发表评论