PaulChess/MyBlog

前端物料平台搭建(调研)

Opened this issue · 6 comments

PaulChess commented
前端物料平台搭建(调研)
PaulChess commented

bit.dev 流程

  1. 跑通流程 -- 列举流程中哪些是我们要的，遇到什么问题?
    https://docs.bit.dev/docs/tutorials/bit-vue-tutorial
    https://juejin.cn/post/6844903872108953607
  2. 物料平台私有化部署 & 接口服务部署
PaulChess commented

京东羚龙的文档: https://jdw.jd.com/docs/widget_develop, 这篇文档可以作为物料平台搭建细节和流程的参考。

PaulChess commented

字节Arco调研
Arco Design 基础组件库
Arco Material Market 物料平台
Arco Cli 物料脚手架工具
Icon Box 一站式图标平台
Arco Pro 后台开箱即用解决方案
Design Lab 风格配置凭条
Palette 色彩配置工具

PaulChess commented

LowCode 平台内需要支持:

  1. rem
  2. light / dark
  3. 同花顺金融体等特殊字体
  4. reset样式文件
PaulChess commented

整套物料体系应包括:

  1. 组件仓库架构: 例如采用单包单仓库架构，还是多包单仓库架构架构，还是多包多仓库架构。
  2. 组件脚手架: 包含创建、发布等在内的全套流程
  3. 物料展示页面

仓库架构

单包单仓库适用于基础组件库，其最终打包的时候是将所有的组件打到一个包里，需要提供的是组件的按需加载;
多包多仓库成本有点高，一个业务组件一个仓库，还需要为每个组件申请用于发布的容器，且很难管理公共依赖的引入及升级；
综合考虑，尝试用主流 monorepo 架构先试一下，这里面的技术选型目前包括:

  • lerna + yarn workspace
  • yarn + yarn-plugin-babel-release-tool (babel 用的是这套架构)
  • pnpm workspace ( vue、varlet-ui、vant 都用的是这套架构)

实践过后我会再写一篇具体阐述其中的技术细节 🚧。

物料形式

物料的定义: 物料，指在产品制造过程中，列入生产计划的一切物的总称。
按照上述定义，前端生产过程中会用到的自研物料大致可以划分如下:

  • 基础组件库
  • 业务组件
  • 区块 (业务组件 + 基础组件 组成可复用区块)
  • 页面 (区块 + 业务组件 + 基础组件 组成可复用页面)
  • 基础函数库
  • 公用组合式函数 composables，原子类 / 可复用样式，公用 vue 指令、过滤器等 (这些也可以考虑划分到基础组件库里去)

上述物料形式中的 基础组件库、基础函数库 以及最后列举的那些可复用单元是否要整合进物料仓库中需要团队内再讨论权衡一下 🚧。其优势在于例如在开发业务组件的时候用到了基础ui组件或基础函数就可以直接在该项目的 workspace 中安装对应的依赖；而劣势还是上面说的仓库体积过大，会带来开发上的一些干扰。

物料展示页面

目前调研了三款产品的物料展示页面:

从体验感上来讲，个人感觉美创意要优于下面两个企业产品，从首页的组件列表就可以看出每个组件的 banner 展示图都很清晰，甚至可以说是精心设计过的，而且支持 gif 动图，再结合简洁的组件标题和描述，不用点进去看详情我们就可以直接凭直觉知道这个组件的作用是什么、UI 风格是什么样的、是否是我们现在需要的组件。
image

见过一些比较粗糙的物料平台，它们的 banner 都是直接从 demo 截图截下来的，一般都是白底，显得内容比较小，在物料平台上展示的时候甚至还会出现压扁等情况，这就使得大家无法凭直觉判断出上述所说的那些要素，于是再点进详情页里面寻找更多线索，最后发现不是自己想要的再退出来重新找再重新进详情页，反反复复，增加了使用者的心智负担，大家自然就不再想要去用这个平台了。所以每一个组件都匹配一个高质量的 banner 对于物料展示平台来讲是非常重要的事情。我们需要采用一些技术手段来帮助大家很方便地为自己的组件产出清晰、优质的 banner。

banner 只是其中一点，从 banner 可以延伸出其他一些重要的物料信息，总结如下:

  1. banner
  2. 组件标题 (见名知意)
  3. 组件描述 (简洁清晰)
  4. 组件标签 (尽可能要细致些: 包括技术栈、组件类型(业务组件/区块/页面...)、部门(F10、手炒...)) 标签的选择可以集成在脚手架中。
  5. 开发人员信息 (要方便用这个组件遇到问题的时候可以方便地找到组件的当前维护者)
  6. 清晰的README文档. (包括CHANGELOG、安装方式、api说明、常见问题...)
  7. 可访问、精致的 demo 页面
  8. 可调试的在线编辑器(可选)

如何确保上传的物料信息的规范性，促进优质物料上传、流通，提高平台的可持续性发展能力我觉得是物料平台搭建过程中最重要的的环节，可以结合脚手架(技术层面) + 部门审核/平台审核(约束层面) + 开发激励(心理层面) 等多方面的措施来促进正向循环。这一部分也需要重点讨论一下实现细节。🚧

有了物料以后，平台初步要做的事情比较简单，列举如下:

  • 组件展示列表 (建议可直接参考美创意)
  • 展示非常清晰、可读性很强的组件详情描述页
  • 分类列表，可以查看某个分类下的物料 (但是要考虑标签管理，比如页面上展示了 50 个标签，对开发也会带来筛选信息的负担)
  • 强大的搜索功能 (可结合组件名、描述、标签等关键词信息快而全地搜索到自己需要的组件，这一点非常关键！)
  • 评分、排名机制
  • 组件生命周期管理，比如 (正常、废弃等. 这个功能可以后面做)
  • 组件下架(删除)

🍪 (这是张饼) 如果物料平台可以做成类似于浏览信息的 feed 流，像 GitHub 的优质项目推荐或者说像小红书一样让大家可以在里面没事刷一刷，发现其他同事写的好东西，同时刺激自己产出就可以形成物料仓库的正向循环。

参考资料

  1. 字节 ADFE 团队: Monorep 下的模块包设计实践
  2. 使用 lerna 管理项目中的业务组件
  3. pnpm monorepo demo
PaulChess commented

组件命名规范、团队命名空间
README 规范
需要处理的问题:
物料之间的依赖关系、公用复用单元的使用
发布. npm cdn => 还要上传到lowcode平台去用

脚手架: 集成各种规范 比如 eslint、husky 等

做好搜索、banner、标签、标题(组件名)、描述、分类、组件信息。
减少物料重复建设，比如同一个部门出现多个及其类似的物料，就属于重复建设，我们要尽一切可能减少物料仓库的复杂度。精简化非常重要。

解耦
仓库组织

下午跟刘帅聊的:

  1. 这件事情最大的意义在于哪儿
  2. 是否可以在 lowcode 平台上集成这样一个在线的组件开发、调试、发布环境

hxm-cli => 分装了一套规范
hxm-cli create
A => Re A publish => materials/packages/A
B => Re B
C => Re C

pipeline => materials A npm run build

  • 开发流程
    发布

===== materials 仓库