随着“微前端”概念的不断酝酿，越来越多的团队开始将自己的业务处理成不同的组件，并排列成一个业务页面，因此组件的维护会变得越来越复杂。更重要。针对大多数前端在组件开发中会遇到的问题和痛点，本文将分享笔者对组件开发的一些思考，以及如何维护自己的组件库。背景2019年6月左右，我发表了一篇文章《Bit 初体验》。在整理这篇文章的过程中，我可以说对比特提出的概念和实践有了深刻的体会。就像在我心里种下了一颗种子。起初我以为这没什么。还记得第一次跟同事分享的时候，他说：emm，虽然说了那么多，但我觉得好像不是……肉体上的？感觉没用？啊，emm，既然你说了，就像你说的。我想如果我们现在引入bit，会不会给我们的日常工作带来很多额外的工作量。这种反应是正常的。2018年初在Vue官网看到bit，当时点进去粗略看了下。我当时的感觉是没什么用，无非就是“前端垂直领域的git”。国内支持情况不好，连个像样的中文文档都找不到。在我们团队直接转bitworkflow确实不现实。公司里有那么多基础设施不知道bit。不过bit的方法和理念很有价值，可以借鉴！所以，我想做一件事，一步一个脚印，用大家熟悉的方式介绍bit的玩法，甚至延伸出来，让大家认可它的好处和价值。理解组件随着近几年“微前端”概念的不断酝酿，越来越多的团队开始将自己的业务处理成不同的组件，然后通过一些微前端的方式编排到一个业务页面中。那么部件的维护就会变得越来越重要。那么，我们先来看看现在大部分团队是如何维护组件的！大库类型，Antd，Element标准大库类型一次性类型，完整的业务组件，高复用类型，一次使用后不再维护，见应该单独打包给其他人使用，如：视频播放器项目fusion类型，和业务项目一起，mixedstore，不管你我，我暂时能想到这些类型的组件，如果你的团队也在维护自己的一套组件库的话，应该很容易明白我上面说的。我相信，既然这样做了，那一定有这样做的理由和好处。没有人会闲着，惹是生非。那么这些做法的好处和痛点是什么？我将从几个方面来分析它们。方便快捷的组件，当然是运行的最快，看到的效果最方便。对此，有没有比在业务项目中直接拉取组件更快的方法呢！？现在用一个显示面板，马上去components目录下拉一个。数据？没有商店吗？介绍了就拿到数据了！所见即所得，修改后立即在页面上看到效果！无法反驳。。从这个角度来看，开发这个组件确实很快，但是从整个业务需求实现的角度来看，这样做真的是最快的吗？如果这是最快的方式，为什么那么多团队强调沉淀、封装和抽象？事实上，很多组件看起来只可能使用一次，没有包装。但是往往当交互稿过来的时候，你会发现这个风格好像是我见过的地方。然后翻遍了各种商业项目，哇，终于找到了，复制下来发现各种爆款，仔细一看，店？？？所以，聪明的团队已经看到了这一切，让我们把所有的组件都维护到同一个地方，然后大家写好文档，用到的时候，从库中取出即可。如有BUG统一修复。伟大的！可维护性，于是大家如火如荼地开始了组件抽象和组件整改。巨大的工程。一开始，团队里通常会有一个比较靠谱有能力的小伙子（嗯？为什么是我？）整合Webpack，Babel，TypeScript，Sass\Less，目录结构，单元测试结构，代码规范，Review规范，整理好发布规范，写一个标准的组件，最后强调大家一定要按照规范认真维护组件，写文档，写单元测试。在可维护性方面，大家把组件写在一个库里，然后直接导入到自己使用的项目中。业务问题逐渐分为组件问题或项目问题，甚至有些需求可以在组件库中使用这种交互。里面有类似的东西，就用那个组件来反驳产品和设计吧#128527;。就在大家玩得开心的时候，有一天我发现，啊，我们的组件库怎么打包成10M了😱！然后找个靠谱有能力的（没错，又是我）就去查了下，这个库是谁介绍的？这个组件不是已经有了吗？这不是lodash的用法！这个组件是做什么的，为什么没有文档？面对上百个业务组件，只能感叹业务迭代真快。所以大库维护肯定有大库维护的好处和适用场景。大家能有这样的抽象思维，已经是技术上的突破了。现在我们又遇到了另一个问题。解决这个问题！组件大小和加载性能与Webpack的一些外围工具，如分析器，可以很容易地找出是什么包“占用”了这么多流量。发现原来的组件包里还有一些组件，好像不应该在大库里维护，比如那些一次性组件和二次包组件。因为这类组件可能会引入较大的第三方依赖，比如视频播放器、BannerSwiper等，对于这类组件，最好的处理方式应该是创建一个独立的仓库。打包完成后，编写README发布到内网NPM，供业务项目使用。但是你知道，这样做的成本太高了，如果你有时间，我肯定......balabala......（一般来说，如果你告诉一个程序员一个更好的解决方案，除非他参与解决方案设计，不然大部分回复都是这样的🙄）当然组件大小也可以通过很多其他方式解决，比如：异步加载、引入NPM、按需加载等等……那么，说到这里是另一个非常重要但容易被忽视的部分。ComponentDescriptionandIndexability老大，我们今年积累了200+个组件，其中有几个写得特别好，支持了20+个项目。哇，太棒了！来给我看看你写的组件长什么样？啊，这个，来看看我们制作的页面吧。这个页面用到了这些组件，balabala...设计：听说你存了200+个组件，能给我们看看有哪些组件吗？我们可以在接下来的设计中参考这些组件进行输出，减少沟通成本。前端：@Everyone我们库里有这个组件吗？是的，级联选择。哦，怎么用呢？有文档吗。。。。看源码。嗯……😅组件的描述性和可索引性其实仅次于组件的可用性，甚至更高。想象一下，如果你今天写了一个巨型组件，复用性、界面设计、交互设计都很好，但是你有没有渠道让大家一下子知道？你想为每个人开个会吗？?今天来占用大家宝贵的1小时时间，介绍一下我今天写的巨牛组件。🤕另一方面，如果我写的是组件，反正我的组件没什么亮点，别人估计也不会用，所以我也不需要补文档，谁也不会知道。哦，好吧，Wandan🙃index元器件，给大家分享一张图：如果有一天你们团队的元器件库也能这样，有图有真相，一目了然，那该多开心多好啊！我也知道很好！谁不知道！如果我有时间，我一定会....balabala...所以你的意思是我们每次写一个组件，不仅要补充文档，还要补充使用说明，还需要截图！？是的，你需要构建一个单独的库，你还需要考虑配置Webpack、Babel、TypeScript、Sass\Less、目录结构、单元测试结构、代码规范、审查规范、发布规范，这些😎bestpractices说了这么多，主要是想带读者一起思考，也是我的写作风格（喜欢讲故事）。大部分内容其实都是前端er会遇到的问题。接下来，进入正题。说了一大堆问题，总得有办法解决吧！我们来看看bit是怎么做到的。首先，bit具有一定的编译能力，内置了Webpack和一些插件加载器，解决了React、Vue等编译问题。我们团队用的是React，所以先从一个编译React的脚手架开始吧。如果每个组件都作为一个单独的NPM项目发布，首先要考虑的是一系列的前端编译环境。如果我有N个前端组件项目，每个前端组件库的webpack和babel都需要反复配置，这真是一件大事。我只是想写一个组件，为什么要考虑这些。所以我们的脚手架首先要有一些基本的编译命令。哦，对了，脚手架还没有名字，暂且叫它：comp😷compnew:process根据模板创建一个新的标准组件初始化一个标准组件工程结构，allaccessallcomp命令初始化Git仓库初始化CI/CD云构建配置compstart：处理日常开发，增加个别组件展示和调试能力compwatch：处理babel和scss监控编译，用于npm链接场景compbabel：处理编译npm包compdev：处理监控编译umd包，用于代理调试compbuild：处理最终编译过程webpack编译UMD包babel包CI\CD过程自动截取CI过程中的组件\CD过程自动生成READMEOtherHookcomptest:processjestunittest然后组件初始化后，目录结构是这样的：项目中没有webpack\babel配置结构。当然，如果你有特殊的配置需求，可以创建comp.config.js进行配置（这里借鉴了很多已有的cli处理方式）。这种方式的好处是项目初始化后，用户看到的目录结构非常清晰，项目中允许配置的地方不多，基本可以保证所有组件的编译环境是统一的.这些都是非常基本的功能，当然也是必不可少的部分。这些基本命令我就不详细介绍了，重点放在后面。通过这些问题来介绍功能：你平时开发组件的流程是怎样的？通常，一般是按设计稿划分成部件。然后创建组件，最后通过项目引入，边看边开发。你在开发组件时如何验证你提供的Props？最简单的方法就是给一个mock看看效果。或者写一个单元测试？写mock的过程算作写使用吗？嗯，应该算了，但是这些都是分散在各个项目中的，有的mock验证后就删掉了。谁可以在开发过程中随意将这些添加到README中？他们为什么不写文件？不用说？因为他们懒惰？那你为什么不写？emm，那是因为……写文档不一定有人看，还需要时间！业务需求非常多！如果我有时间，我一定会....balabala...好，那我们看下一题。一个好的组件文档需要哪些部分？开发组件背景、注意事项等。这个其实不是必须的，有些组件如果需要就加，如果不需要就不用加。主要需要的一些介绍是：用法，Props入口参数，最好有截图，如果有Demo就完美了！还要有安装、开发、编译命令的介绍。如果是锦上添花，最好有几个徽章。先介绍下源码是TypeScript，下载量有多少。但是补充这些文件太麻烦了。有必要一一整理。道具信息可以在组件中找到。我有一些注释和类型定义！完成一轮的精神折磨后，你会发现，在整个组件的开发过程中，开发者自己之所以对这个组件如此的清楚，是因为开发者居然给自己写了一个README。使用方法：需要在组件开发过程中看到效果。写了一些mock数据之后，你就已经知道传入什么样的props，会产生什么样的效果了。Props入参：组件有哪些props，代表什么，每个props的入参类型是什么，在TypeScript的Interface和注释中都有体现。截图：我有mock数据，不知道长啥样？我已经看过很多次了。Demo：根据用法和组件定义，开发调试为Demo。有了这四个最重要的介绍，相信大部分开发者也能知道这个组件是怎么回事了。那么，如果我们能够收集到以上所有数据，是否可以使用脚本自动生成README文档呢？Usage/用法收集usage其实很简单。如果组件有独立开发的能力，可以保留。Usage的Mock数据是否可用？有些人可能不理解我所说的“独立开发组件的能力”是什么意思。我解释一下：我们通常开发一个组件，通常把这个组件放在某个页面上。一次又一次地调试页面和调试组件。独立开发组件就是直接启动一个页面，可以看到组件长什么样，这个页面展示了组件周围的所有信息。所以在脚手架中，只要将需要调试的组件相关的mock数据写在docs.ts中，页面就可以展示组件的外观，并且这些mock数据可以保留为README文档数据。exportdefaultfunction(Component:typeofIComponent,mountNode){/**DOCS_START请在以下block中编写Demo生成方法生成README和Riddle**/ReactDOM.render(
