Open PaulChess opened 2 years ago
京东羚龙的文档: https://jdw.jd.com/docs/widget_develop, 这篇文档可以作为物料平台搭建细节和流程的参考。
字节Arco调研
Arco Design 基础组件库
Arco Material Market 物料平台
Arco Cli 物料脚手架工具
Icon Box 一站式图标平台
Arco Pro 后台开箱即用解决方案
Design Lab 风格配置凭条
Palette 色彩配置工具
LowCode 平台内需要支持:
整套物料体系应包括:
单包单仓库适用于基础组件库,其最终打包的时候是将所有的组件打到一个包里,需要提供的是组件的按需加载;
多包多仓库成本有点高,一个业务组件一个仓库,还需要为每个组件申请用于发布的容器,且很难管理公共依赖的引入及升级;
综合考虑,尝试用主流 monorepo 架构先试一下,这里面的技术选型目前包括:
lerna + yarn workspace
yarn + yarn-plugin-babel-release-tool
(babel
用的是这套架构)pnpm workspace
( vue
、varlet-ui
、vant
都用的是这套架构)实践过后我会再写一篇具体阐述其中的技术细节 🚧。
物料的定义: 物料,指在产品制造过程中,列入生产计划的一切物的总称。
按照上述定义,前端生产过程中会用到的自研物料大致可以划分如下:
上述物料形式中的 基础组件库
、基础函数库
以及最后列举的那些可复用单元是否要整合进物料仓库中需要团队内再讨论权衡一下 🚧。其优势在于例如在开发业务组件的时候用到了基础ui组件或基础函数就可以直接在该项目的 workspace 中安装对应的依赖;而劣势还是上面说的仓库体积过大,会带来开发上的一些干扰。
目前调研了三款产品的物料展示页面:
从体验感上来讲,个人感觉美创意要优于下面两个企业产品,从首页的组件列表就可以看出每个组件的 banner 展示图都很清晰,甚至可以说是精心设计过的,而且支持 gif 动图,再结合简洁的组件标题和描述,不用点进去看详情我们就可以直接凭直觉知道这个组件的作用是什么、UI 风格是什么样的、是否是我们现在需要的组件。
见过一些比较粗糙的物料平台,它们的 banner 都是直接从 demo 截图截下来的,一般都是白底,显得内容比较小,在物料平台上展示的时候甚至还会出现压扁等情况,这就使得大家无法凭直觉判断出上述所说的那些要素,于是再点进详情页里面寻找更多线索,最后发现不是自己想要的再退出来重新找再重新进详情页,反反复复,增加了使用者的心智负担,大家自然就不再想要去用这个平台了。所以每一个组件都匹配一个高质量的 banner 对于物料展示平台来讲是非常重要的事情。我们需要采用一些技术手段来帮助大家很方便地为自己的组件产出清晰、优质的 banner。
banner 只是其中一点,从 banner 可以延伸出其他一些重要的物料信息,总结如下:
如何确保上传的物料信息的规范性,促进优质物料上传、流通,提高平台的可持续性发展能力我觉得是物料平台搭建过程中最重要的的环节,可以结合脚手架(技术层面) + 部门审核/平台审核(约束层面) + 开发激励(心理层面) 等多方面的措施来促进正向循环。这一部分也需要重点讨论一下实现细节。🚧
有了物料以后,平台初步要做的事情比较简单,列举如下:
🍪 (这是张饼) 如果物料平台可以做成类似于浏览信息的 feed 流,像 GitHub 的优质项目推荐或者说像小红书一样让大家可以在里面没事刷一刷,发现其他同事写的好东西,同时刺激自己产出就可以形成物料仓库的正向循环。
组件命名规范、团队命名空间 README 规范 需要处理的问题: 物料之间的依赖关系、公用复用单元的使用 发布. npm cdn => 还要上传到lowcode平台去用
脚手架: 集成各种规范 比如 eslint、husky 等
做好搜索、banner、标签、标题(组件名)、描述、分类、组件信息。 减少物料重复建设,比如同一个部门出现多个及其类似的物料,就属于重复建设,我们要尽一切可能减少物料仓库的复杂度。精简化非常重要。
解耦 仓库组织
下午跟刘帅聊的:
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 仓库
bit.dev 流程