组件库

作者：京东批发 佟恩 本文介绍，如何应用 NutUI 组件库，搭建一套为专属业务格调的业务组件库。 NutUI 是一款京东格调的挪动端组件库。NutUI 目前反对 Vue 和 React技术栈，反对Taro多端适配。当下的实现形式个别组件库，都会给用户提供批改主题的形式。比方在 NutUI 组件库中，给用户提供了两种形式： 批改CSS变量，NutUI 组件库反对通过全局配置组件 ConfigProvider 组件实现主题定制；const customTheme = { nutuiBadgeBorderRadius: '12px 12px 12px 0',}<ConfigProvider theme={customTheme}> <Badge value="NEW"> <Avatar icon="my" shape="square" /> </Badge></ConfigProvider>通过SCSS 变量，NutUI 组件库提供通过编写一套自定义主题的款式文件，间接笼罩现有款式文件，实现主题定制。// 新建一个 SCSS 文件 custom_theme.scss 进行自定义// 主色调$primary-color: #478EF2;$primary-color-end: #496AF2;// vue 版本{ test: /\.(sa|sc)ss$/, use: [ { loader: 'sass-loader', options: { // 留神：在 sass-loader 不同版本，这个选项名是 是不一样的，具体可参考 sass-loader对应的版本文档 data: `@import "@/assets/custom_theme.scss";@import "@nutui/nutui-react/dist/styles/variables.scss";`, } } ]}以后问题与解决思路以上两种形式，对于咱们实现单个我的项目来讲，还是比较简单的，然而如果咱们业务条线下的每一个我的项目都须要这样接入，那这个接入形式就会显得蠢笨起来。 那咱们怎么能力优雅的接入呢？ 咱们的思路是，NutUI 与业务侧一起，独特输入一套属于本人业务格调的组件库。 其中，NutUI 提供组件库反对主题定制的配置和编译能力，业务侧输入交互与视觉标准，共同完成组件库的适配计划，输入定制化组件库的 NPM 包，进而在业务我的项目中提供反对。 ...

老早就晓得 Storybook 这个用于开发组件库生成文档的工具，但始终未在生产环境实际过，上面讲一下我最近遇到的一个问题根本介绍、装置过程暂且不谈，可去官网理解Storybook 根底介绍中文文档、最新文档 问题：docs 文档不显示因为我是接手的他人的我的项目，这个我的项目的 storybook 均已初始化结束，但有一个问题是 docs 菜单不显示内容，这就带来了一个问题：就是我在 storybook 找到了我须要的组件然而我却无奈间接复制只能去源码找到相应代码而后拷贝下来其过程非常苦楚繁琐 解决问题的步骤 一度认为是控制台的那个报错影响的不展现，就玩命的搜寻这个报错的起因，但怎么都找不到答案，而后看到storybook有个docs的插件-@storybook/addon-docs，装置应用也是杯水车薪，docs 菜单怎么也搞不进去而后想到初始化一个最简略的 storybook 我的项目看一看它与现有我的项目中的配置哪里不统一，而后利用 npx sb init 文档初始了一个我的项目，这里多说一句，官网文档指明 sb init 不针对一个空我的项目，而是一个曾经应用框架的我的项目而后启动发现 docs 菜单是能失常显示的，配置文件 main.js 也没有装置 @storybook/addon-docs 该插件而后我就把现有我的项目的 storybook 的配置文件 (.storybook 目录) 删掉，所有依赖 package.json 的货色全删掉，而后在根目录执行 npx sb init执行 yarn storybook 而后奇观产生了，docs 目录呈现了 ，合乎预期，但因为我的项目中应用 tailwindcss，storybook 中的组件的款式全都失落了又去搜寻 storybook + react + tailwindcss 如何组合应用，找到了这篇文章 解决了我的问题，docs 菜单菜单呈现了 残缺的配置如下 // .storybook/main.js const path = require('path')module.exports = { stories: ['../src/**/*.stories.mdx', '../src/**/*.stories.@(js|jsx|ts|tsx)'], addons: [ '@storybook/addon-links', '@storybook/addon-essentials', '@storybook/addon-interactions', '@storybook/addon-storysource', // 用于底部菜单栏呈现 story 选项 '@storybook/preset-create-react-app', ], // tailwindcss 与 storybook 配合应用 webpackFinal: async config => { config.module.rules.push({ test: /\.css&/, use: [ { loader: 'postcss-loader', options: { ident: 'postcss', plugins: [require('tailwindcss'), require('autoprefixer')], }, }, ], include: path.resolve(__dirname, '../'), }) return config }, framework: '@storybook/react', core: { builder: 'webpack5', },}参考文章storybook中文文档基于 Storybook 5 打造 Style 组件库开发与文档站建设小结Storybook 入门指南

首先咱们咱们的这个ui组件库是开发的vue版本，如果须要变通其余版本的话，就把vue相干的编译器移除，其余相干的编译器加上就能够了(例如react)，打包构建形式是通用的。组件库的组织发版和我的项目是不太一样的，这里提下思路。首先咱们要确定咱们做的库要满足的需要： 反对全副加载反对按需加载ts的补充类型反对同时反对cjs和esm版本晓得了咱们要反对的需要之后，要确定一下咱们最初包的目录构造是什么样的，如下：这简略形容下为何是这样的构造，首先index.esm是 咱们整全量的包，外面蕴含了所有的ui组件，还有一个index.cjs版本，在打包工具不反对esm时会应用cjs版本，两个版本能够更好的反对不同的打包工具。 lib下放的是咱们单个组件，用来联合 babel-plugin-import 来做按需加载。这里先简略做一个概括，后续实现的时候会做具体的解释。 好了，理解了 咱们最初的我的项目构造，就要开始ui库的搭建了，后续所有的操作配置，都是为了在保障程序健壮性通用性的根底上来打进去咱们最初要公布的这个包的构造。 设计及流程代码的组织形式MonorepoMonorepo 是治理我的项目代码的一个形式，指在一个我的项目仓库(repo) 中治理多个模块/包(package)，不同于常见的每个模块建一个repo。例如： ├── packages| ├── pkg1| | ├── package.json| ├── pkg2| | ├── package.json├── package.json这样的构造，能够看到这些我的项目的第一级目录的内容以脚手架为主，次要内容都在 packages 目录中、分多个package进行治理。 一些出名的库例如vue3.0和react都是采纳这种形式来治理我的项目的。后续咱们会依据这些packages里的小包，来生成按需加载的文件。 包的管理工具采纳yarn,因为咱们要用到它的workspaces依赖治理如果不必workspaces时，因为各个package实践上都是独立的，所以每个package都保护着本人的dependencies，而很大的可能性，package之间有不少雷同的依赖，而这就可能使install时呈现反复装置，使原本就很大的 node_modules 持续收缩（这就是「依赖爆炸」...）。 为了解决这个问题在这里咱们要应用yarn的workspaces个性，这也就是依赖治理咱们为什么应用yarn的起因。而应用yarn作为包管理器的同学，能够在 package.json 中以 workspaces 字段申明packages，yarn就会以monorepo的形式治理packages。应用形式详情能够查看它的官网文档 文档 咱们在package.json开启了yarn 的workspaces工作区之后，以后这个目录被称为了工作区根目录，工作区并不是要公布的，而后这会咱们在下载依赖的时候，不同组件包里的雷同版本的依赖会下载到工作区的node_modules里，如果以后包依赖的版本和其余不一样就会下载到以后包的node_modules里。 yarn的话突出的是对依赖的治理，包含packages 的相互依赖、packages 对第三方的依赖，yarn 会以semver 约定来剖析dependencies 的版本，装置依赖时更快、占用体积更小。 lerna这里简略提一下lerna，因为目前支流的monorepo解决方案是Lerna 和 yarn 的 workspaces 个性，它次要用来管理工作流，然而它个人感觉如果你须要一次性公布packages里的所有包时，用它会比拟不便，咱们这里没有过多的用到它。 Storybook开发阶段的调试组件成果的调试和应用介绍咱们通过Storybook来进行治理，这是一个可视化的组件展现平台，它能够让咱们在隔离的开发环境 交互地开发和测试组件，最初也能够生成应用阐明的动态界面，它反对很多框架例如：vue.react,ng,React Native等。 jest单元测试单元测试的话咱们应用Facebook的jest plop创立雷同模版咱们包的构造是这样的,例如avatar： ├── packages| ├── avatar| | ├── __test__ //单元测试文件| | ├── src //组件文件| | ├── stories //storyBook 开发阶段预览的展现，扫描文件| | ├── index.ts //包入口| | ├── LICENSE| | ├── README.MD| | ├── package.json├── package.json每个UI组件的构造根本都是一样的，所以在这里咱们选用plop来对立生成模版，plop次要用于创立我的项目中特定文件类型的小工具，相似于Yeoman中的sub generator，个别不会独立应用。个别会把Plop集成到我的项目中，用来自动化的创立同类型的我的项目文件。 ...

业务组件库必要性我的项目通过长期保护之后往往会积淀出很多公共组件，当一个组件编写实现之后，其余维护者想要应用这个组件，理解这个组件是做什么的，应该怎么用，必须再去翻看源码，或者没有压根儿留神到这个组件导致重发开发。这个时候一个欠缺的组件库就很有必要了，能够保障开发者之间进行良好的合作。 组件库能够帮咱们解决以下问题： 业务组件跨我的项目复用，晋升开发效率对立代码实现，对立代码品质保障组件库文档提供清晰的应用形式和直观的展现成果组件库的组成 业务组件形成 业务组件库是基于根底组件库进行编写的，根底组件库是应用antd。咱们会对根底组件针对不同需要进行封装，达到能够间接援用无需二次开发的目标(比方：下拉抉择组件，咱们会将接口申请数据、选项含糊查问、多语言等封装到组件外部，无需二次开发，接口申请也不须要再散落到各个页面中)。 指标引⼊即可使⽤，⽆需⼆次开发欠缺的文档和组件成果演示，反对代码一键拷贝良好的代码品质：应用Jest进行单元测试，保障代码品质良好的编码标准和代码提交标准：ESLint、Husky、commit-lint等工具进行校验和拦挡依据代码提交主动生成ChangeLog组件成果演示反对编辑实时渲染(在文档中编辑组件，实时变更展现成果)开发计划 组件库开发周期 筹备组件库文档选型评审首批组件梳理开发本地预览调试本地构建Jest + @testing-library目录构造标准本地开发环境构建代码标准校验代码提交标准校验CR和公布标准TypeScript反对单元测试组件开发组件库文档生成首次公布公布和应用首次版本迭代降级在线拜访业务组件新增业务组件迭代组件库文档托管可视化构建页面区块和页面

前言 在《GrowingIO Design 组件库搭建之开发工具》一文中介绍了搭建组件库的起因和应用的开发工具，这篇文章就来介绍组件库的配角：组件。先从组件的定义说起。 组件的定义 组件是标准化的、可调换的 UI 模块。它们封装了 UI 局部的外观和性能。想想乐高积木。乐高积木可用于建造从城堡到宇宙飞船的所有货色，组件能够拆开并用于创立新性能。组件通过将状态与应用程序业务逻辑隔离来实现互换性。这样，你能够将简单的屏幕分解成简略的组件。每个组件都有定义明确的 API 和可被 Mock 的系列状态。这容许组件被拆开和重组，以构建不同的 UI。 组建驱动 UI 后面明确了组件定义之后，如何从一个个组件构建出残缺的 UI。过程如下： 一次构建一个组件：隔离构建每个组件并定义其相干状态。从小处着手。组合组件：将小组件组合在一起以解锁新性能，同时逐步减少复杂性。组装页面：通过组合复合组件来构建页面。应用 Mock 数据模仿页面的难以达到状态和边缘状况。集成到我的项目中：通过连贯数据和连贯业务逻辑，将页面增加到您的应用程序。组件驱动 UI 的益处： 品质: 通过隔离构建组件并定义其相干状态，验证用户界面在不同场景中工作。耐用性: 通过在组件级别进行测试，将缺点准确到细节。它比测试屏幕工作更少，也更准确。速度: 通过重用组件库或设计零碎中的现有组件，更快地组装 UI。效率: 通过将用户界面分解成离散的组件，而后在不同的团队成员之间分担负载，并行化开发和设计。接下来就得介绍如何用代码实现组件了。但在此之前，先说说代码仓库的事。 代码仓库 从代码仓库的格调说起：Monolithic Repo（简称 Monolith）、Monorepo 和 Multirepo。 Monolith：所有代码都寄存在一个仓库中。Ant Design 组件库应用的就是此种形式，所有组件都在 components 目录下，每个组件独自目录。Monorepo：也是将所有的代码都寄存在一个仓库中，然而它能够蕴含 Monolith（比方一个目录对应一个 Monolith）。组件库中应用此种形式的是 Material Components for the web，所有组件都寄存在 packages 目录下，每个组件都是一个 package，并且对立发版。Multirepo：将代码分成多个局部，寄存在不同的仓库中。此种形式的代表是 react-component，每个组件都是独自仓库，每个组件都可独自发版。对于 GrowingIO Design 来说，一方面是做不到 Material Design 那样对立发版，有些简略组件开发完后会长工夫不更新；另一方面是组件太多，应用 Multirepo 形式，导致仓库很多，保护老本太大。所以，GrowingIO Design 采纳了常见的 Monolith 格调，用一个仓库，不同组件放在不同目录下，并且最终只有一个 package。 组件目录 上一节中代码仓库格调抉择了 Monolith，也明确了不同组件放在不同目录下，思考到组件会随着迭代越来越多，有必要提前标准一下组件的目录构造，明确一下一个组件至多应该蕴含哪些文件。 ...

在理论我的项目中，咱们经常会遇到这样的一些场景：比方当初须要做一个下载报表的性能，而且这个性能在很多页面都有，下载的也是同类型的报表，如果在每个页面都去写反复性能的代码显得特地冗余，可不将其封装成一个组件多出调用呢？只不过这个组件跟咱们常见的一些根底组件有些区别，次要区别在于这个组件外头蕴含了业务逻辑，咱们称之为“业务组件”，这类组件是专门为了进步开发效率衍生进去的一种计划，这个组件库可能由专门保护组件库的人来保护，也可能是单个项目组本人的业务组件库。废话不多说，咱们来着手实操一下： 初始化我的项目应用lerna初始化工程，Lerna 是一个优化应用 git 和 npm 治理多包存储库的工作流工具，用于治理具备多个包的 JavaScript 我的项目。 将大型代码库拆分为独立的独立版本包对于代码共享十分有用。 然而，在许多存储库中进行更改是麻烦和难以跟踪的事件。为了解决这些（和许多其余）问题，一些我的项目将它们的代码库组织成多包存储库。 像 Babel、React、Angular、Ember、Meteor、Jest 等等。 首先应用 npm 将 Lerna 装置到全局环境中： 举荐应用 Lerna 2.x 版本。 npm install --global lerna接下来，咱们将创立一个新的 git 代码仓库： git init pony-bre-component && cd pony-bre-component并与github近程仓库关联 get remote add origin xxx当初，咱们将上述仓库转变为一个 Lerna 仓库： lerna init另外，我的项目须要装置react、react-dom、typescript、@types/react、@types/react-dom yarn add typescript react react-dom @types/react @types/react-domnpx typescript --init 在根目录生成tsconfig.json你的代码仓库目前应该是如下构造： pony-business-component/ packages/ 寄存每一个组件 package.json lerna.json lerna配置 tsconfig.json typescript编译配置文件lerna.json： { "packages": [ "packages/*" ], "version": "0.0.0"}package.json: ...