B端大仓文档

Appearance

模板开发说明 ​

考虑现有B端系统拥有一致的认证鉴权体系和统一的Layout外壳，在大仓v0.1.10中已进一步封装，抽离了统一的@fs/micro-app模板，适用于绝大部分B端系统。

使用 ​

bash
# 创建项目
fs-cli init

# 选择 vue3-admin-lib-template

# 启动
pnpm run dev

模板如何产生 ​

在我们阅读vue官方文档时，按如下操作可以得到一个极简的vue3示例应用，

bash
# 创建
pnpm create vue@latest
# 启动
pnpm run dev
# 构建
pnpm run build

vue

通常我们开发一个新项目时，会基于上述得到的官方模板，然后不断开发适用于具体业务的模块。

比如常见的鉴权处理，路由处理，ui组件库处理，vite插件处理等，然后再一步开发layout部分，再进一步编写常规的CRUD管理模块。

通常针对公司早期只有一个项目按上述处理是丝毫没有问题的，无论是效率还是维护难度，开发体验都有保证，比如早期的Service系统就是典型的大而全的应用。

那上述大而全的应用，随着时间的拉长，业务不断扩张，会带来一些列的问题，

比如，随着需求不断迭代，内容会越来越多，项目也会越来越复杂，维护难度也会不断上升，直到有一天变成难以维护的巨石应用，启动时间，构建时间不断变长，往往害怕牵一发而动全身这种问题出现，开发者都会继续实现需求，而不会适时优化，适时丢弃无用代码，然后又进一步导致项目维护难度增大，总之开发体验毫无保障，也很难应对不断的业务迭代。

业内为了解决上述问题，避免系统不断膨胀，臃肿，技术栈老旧难以维护的问题，也有较多的探索与尝试，最后大家熟知的微前端方案脱颖而出，它能够很好的规避上述问题。

微前端的概念里会阐述，每一个应用都可以独立部署，独立访问，任何应用都可以作为主应用，也可以作为子应用。也就是各系统完全的独立。

但是，比较适用于企业内的解决方案，还是基于基座模式的微前端设计。

微前端的设计理念很简明，但实现却需要开发者仔细斟酌，不断探索，需要保证独立开发部署，也要保证开发体验一致，进而保证开发效率，以及团队规范的统一落地。

想一想我们这一路怎么摸索过来的就能发现问题，进而解决问题。

  1. 初期我们期望项目快速启动，快速落地，快速上线推向市场，会用一个仓库不断开发迭代，形成了我们的Service系统
  2. 后面我们发现这种巨石应用带来一些列的问题，探索了微前端的解决方案，从而保证各业务系统独立开发部署，如SSO集成平台下面的相关业务系统
  3. 在后面组件库搭建以保证各UI交互与表现行为一致，避免重复的处理样式与交互问题，基于此又搭建了业务组件，进一步保证统一UI交互的落地以及开发效率的提升
  4. 为了减少手动拷贝项目进行删减，我们有脚手架工具可以辅助创建新项目，避免手动拷贝带来的不稳定，不一致

上述一步步走来，解决了很多问题，每次用fs-cli init选择项目模板，能够很快的创建一个应用，但是这个应用里存在大量通用能力没有抽离，

fs-cli

bash
mkdir test-app && cd test-app

fs-cli init

code ./

打开这个test-app，只是一个纯静态模板，并未达到我们之间开发业务逻辑的目的，我们还需要开发认证模块，要改造外壳，再编写具体的业务逻辑，处理一些CRUD，针对单个项目来看似乎没什么问题，但是A项目，B项目，C项目，每增加一个项目都要开发上述的功能，如果是从别的项目复制过来，一来丢失cli自动化处理的作用，二来不可控还需要调试，更重要的是不可长期维护，长期扩展，也不具备较强的应变能力，

比如在将UUMS认证改为SSO认证的时候，需要侵入每一个项目单独修改， 在兼容微前端场景的时候，也是要单独侵入每一个项目做isMicroApp的判断，假如未来还有变化，又将如何应对。

对应的我们梳理通用模块，开发了统一的认证体系，权限体系，这种通用服务，再结合统一的UI交互行为我们开发了表格表单等通用业务组件，但似乎还有通用部分没有抽离，比如要处理微前端场景时需要再业务系统中处理layout是否显示，用户信息获取来源等，比如1.x的wms系统。

至此，发现共用部分存在于layout中，既然存在共用部分，考虑复用，我们自然是要进一步抽取的，所以形成了@fs/micro-app模板。

使用fs-cli init时，选择vue3-admin-lib-template模板即可，

pnpm run dev启动后即为一个完整应用，会内置layout，认证处理，权限处理，sentry处理等通用能力，业务开发时可直接添加路由，此应用可独立部署独立访问，也天然支持mom场景和sso集成平台场景。比如2.x的wms系统，现在的文控系统，工时系统等。

上述封装虽然极大的简化了开发方式，但是通常针对以下场景我们需要思考如何应对。

  • 绝大部分项目都是统一的外壳，所以我们必然是要抽离这部分通用模块。但总有些项目定制化程度比较高，统一的layout并不是适用，此时就需要我们自定义编写模板(PS:可以参考1.0的wms系统，是业务内处理layout)。
  • 新项目都会接入权限平台权限，但有些项目由于历史原因需要暂时接Service的权限数据，比如工时系统2.0，此时我们应该如何做，还要考虑未来工时系统也接入权限平台数据，如何快速适配(PS:可以参考工时系统2.0，接入的是Service权限数据)。

如何开发模板 ​

基于上述，我们明白了如何通过官方提供的模板快速开发一个纯净的vue应用pnpm create vue@latest，也明白了如何通过fs-cli init快速创建一个适用于企业内部的完整vue应用。

那针对不一致的layout我们需要开发适用于本项目的模板，如果此模板未来也适用于其他应用，就应该进一步从业务系统中抽至大仓，整个过程是和共建通用组件是一致的，适用于业务就在业务系统里面定制开发，若识别到其他应用也会使用，就应该考虑抽离，统一维护了。

  1. 使用fs-cli创建常规vue3-admin-lib-template应用，如test-app
  2. 复制fs-web-library/apps/micro-app/src至test-app/app/src中
  3. 将test-app/src/main.ts中的import startApp from '@fs/micro-app'改为成本地的import startApp from '../app/src'

自定义模板

此时项目layout使用的即为本地的内容，可以将test-app/app中的内容完全重写，以满足具体场景。

如何将上述在业务系统内开发的模板迁移至大仓，供其他业务系统使用？反向复制过去就行了。

  1. 将业务仓库中的test-app/app/src复制到fs-web-library/apps/xx-app/src中
  2. 补全私有包信息及打包配置即可，可以把fs-web-library/apps/main-app/中的package.json,tsconfig.json,vite.config.ts三个文件复制过去，改掉package.json中的name字即可
  3. 如何调试，将fs-web-library/playground/src/main.ts中的import startApp from '@fs/micro-app'更改为import startApp from '@fs/xx-app'即可
  4. 调试结束，提交fs-web-library/apps/xx-app，并发布版本即可在业务系统中体验

关于模板扩展 ​

若有H5项目，需要接公司内部完整的认证流程以及权限，可直接复用大仓内的Passport和User相关模块，因为认证流程和权限一般都是一套接口，不用二次开发处理认证相关。

其他说明 ​

凡是能抽出来的东西，都只是考虑普适性，若不能满足时，则需要自定义相关模块。

  • 如果layout不适用当前业务，就自定义实现模板App
  • 如果认证体系不是公司内部统一的sso，那就自定义实现PassportService
  • 如果表格，查询表单，表单，与统一UI交互大相径庭，那就使用原始的开发方案，即@fs/smart-design中的form，table开发对应逻辑
  • 如果真有所有都不适用的场景，那就用官方的模板pnpm create vue@latest创建空白应用，从零到一的开发