当前位置: 首页 > 科技观察

做好这三个关键点才能更好的实现前端业务组件库

时间:2023-03-19 01:52:31 科技观察

对于前端同学来说,业务组件库绝对不陌生,很多前端团队都会选择搭建业务组件库来解决跨项目复用业务组件,同时统一代码实现,统一代码质量,提高业务开发效率。但是我发现,在明确了需求之后,在开始调研技术方案的时候,很多同学并不清楚要调研哪些技术点,具体方向如何找到解决方案,找到解决方案后要尝试哪些case,如何去解决。实施这些解决方案。整合等等。其实你不需要想的那么复杂,只需要按照以下三个技术的要点去做就可以搞定。第一步:“打基础”——业务组件库的整体架构设计第二步:“搭建主体结构”——业务组件库的基础技术设计第三步:“粉刷门面”——业务组件库你一定觉得这三点太宏观了,不好理解,那么接下来,我就来介绍一下这三个重点是什么。可以参考这些重点进行相关的技术研究1.业务组件库的整体架构设计对于业务组件库的整体架构设计,核心问题是如何组织和管理业务组件库的代码.首先,我们构建代码库。业界普遍以单体仓库的形式维护同类型的组件库,将组件开发成npm包。这里的关键点是,你应该考虑将所有组件打包成一个大的NPM包,或者拆分成一个独立的小NPM包。**不要小看这个问题。这两种选择都会造成仓库目录结构的很大差异,进而影响后续组件的开发、构建、发布和实施。技术设计的单包架构是怎样的?如果选择Treatallcomponentsasawhole并将它们打包在一起发布。这称为单包架构。单一仓库,单一包裹,统一维护,统一管理。比如Antd最大的优势就是可以通过相对路径实现组件和公共代码之间的引用。缺点缺点是组件完全耦合在一起,必须作为一个整体进行封装。即使只是更改了一个组件的很小的功能,也必须为整个包发布更新。比如antd,就是作为一个整体来管理的。如果选择使用单包架构,那么必须提供按需加载的能力,以降低用户的成本。可以考虑支持ESModules的Treeshaking功能,实现按需加载的能力。当然,你也可以选择另一种解决方案,称为“多包架构”。多包架构是各个组件相互独立,单独打包发布,多个包在一个仓库,统一维护,单独管理。.├──lerna.json├──package.json└──packages/#所有的子repo目录都会存放在这里├──project_1/#Component1package│├──index.js│├──node_modules/│└──package.json├──project_2/#packageofcomponent2│├──index.js│├──node_module/│└──package.json...代码优势它最大的优点是组件发布灵活,并且天然支持按需使用,缺点是组件之间存在物理隔离。对于相互依赖、公共代码抽象等场景,只能通过npm包引用来实现。--这些场景统一发布开发相对不方便。多包架构在业界被称为“Monorepo”。在前端领域,我们一般使用第三方库Lerna来维护这样的架构。针对存在依赖关系的场景做了一些特殊的优化。在开发模式下,它会将所有依赖包以软链接的形式连接在一起,方便本地开发和联调。所以这就需要你考虑清楚组件库中的组件是否相互依赖。如果是这样,你可以通过Lerna来处理它。如果专门验证组件之间的依赖关系,也可以选择“单包架构”2.业务组件库的基本技术能力确定了整体架构后,就可以着手具体功能点的实现了。业务组件库需要整体框架提供五种基本技术能力1.构建能力这需要我们提供构建产品的能力。这里有很多选项,你可以选择Webpack,RollupGlupGrunt....构建组件库推荐使用Rollup。推荐使用Webpack来构建项目。这里需要特别注意产品的格式要求,比如我们常用的cjs、esm、umd格式。比如你的组件考虑支持node环境,比如SSR,你需要把代码打包成cjs格式。如果你的组件考虑支持