背景概述
公司主要客户为医院，医院环境基本为内网环境，无法直接访问外网资源。在此背景下，组件系统的设计需要考虑内网部署的特殊性。
el-select, el-dialog -> popover.js vxe -> vxe-ui 远程组件 -> npm -> 等后续稳定-> 远程组件
共享js问题
组件加载会导致首屏慢
idea不友好
DraggableTable -> ElDIalog b -> ElDialog
ElDialog -> 使用项目/组件库全局注册
发包-》组件库整包
- [x]补充测试用例
- [x][]react+shadcn
- [x]react+antd
- [x]vue+antd-vue
组件库，到底是放在第三方，还是项目里 推送-》cicd->生产（内网）-》去某环境拉
问题分析
🔴 问题一：远程组件跨网发布繁琐
当前状况
- 组件采用远程组件方案
- 需要跨网络发布到内网环境
- 部署过程涉及接口上传和下载操作
具体问题
发布流程复杂 - 需要将组件从开发环境上传到发布服务器（已通过打包脚本解决） - 需要从发布服务器下载到内网环境 - 涉及多个网络环境的切换 - 发布过程容易出错
部署效率低下 - 跨网络传输需要额外时间 - 网络不稳定时可能导致发布失败 - 需要人工干预和验证
维护成本高 - 每次组件更新都需要重复跨网发布流程 - 多个医院环境需要分别部署 - 版本管理困难
影响评估
- 开发效率: 组件发布流程影响开发迭代速度
- 运维成本: 需要额外的网络配置和维护
- 用户体验: 组件更新延迟影响用户使用
🔴 问题二：静态资源方案仍存在的缺陷
当前优化方案
将接口请求改为纯静态资源请求，以简化部署流程。
仍存在的问题
1. 组件提示不友好
问题描述:
- 静态资源模式下，开发环境缺少类型提示
- IDE 无法正确识别组件 API
- 缺少自动补全和文档提示
具体表现:
typescript
// 开发时无法获得类型提示
import RemoteComponent from '@/components/RemoteComponent'
// ❌ 无自动补全
<RemoteComponent prop1={...} /> // 不知道有哪些 props影响:
- 开发体验差
- 容易写错 API
- 需要频繁查阅文档
- 降低开发效率
2. 外部依赖不可复用
问题描述:
- 远程组件内部使用的依赖库无法被主应用复用
- 导致同一个依赖库被多次打包
- 增加了打包体积
具体表现:
主应用: react@18.2.0 (100KB)
组件A: react@18.2.0 (100KB) // 重复打包
组件B: react@18.2.0 (100KB) // 重复打包
总大小: 300KB (实际只需要 100KB)影响:
- 打包体积增大: 每个组件都包含完整的依赖
- 加载时间增加: 用户需要下载更多重复代码
- 内存占用增加: 运行时可能存在多个依赖实例
- 缓存效率低: 无法利用浏览器缓存共享依赖
3. 外部依赖版本冲突
问题描述:
- 不同组件可能使用不同版本的同一依赖
- 静态资源模式下无法统一管理依赖版本
- 可能导致运行时错误或功能异常
具体表现:
主应用: react@18.2.0
组件A: react@18.1.0 // 版本不一致
组件B: react@17.0.0 // 版本不一致
可能导致:
- React Hook 规则冲突
- Context API 不兼容
- 性能问题影响:
- 兼容性问题: 不同版本间可能存在 API 差异
- Bug 风险: 版本冲突可能导致难以调试的问题
- 维护困难: 需要同时维护多个依赖版本
- 升级障碍: 依赖升级需要考虑所有组件的兼容性
4. 代码分割和按需加载困难
问题描述:
- 静态资源模式下难以实现代码分割
- 无法按需加载组件代码
- 影响首屏加载性能
影响:
- 首屏加载时间长
- 资源利用率低
- 用户体验差
5. 开发环境与生产环境不一致
问题描述:
- 静态资源请求方式与开发环境不一致
- 开发时需要模拟静态资源环境
- 调试困难
影响:
- 开发体验差
- Bug 难以定位
- 测试覆盖率低