面向未来的全新组件交互设计 - Hi-kits UI组件库

前言

你是否曾经需要一组可重用的UI组件，可以直接将它们加入应用程序，并获得惊人的体验？

你是否曾经创建自己的组件并在公司里分享，包括那些使用不同前端框架的团队？

你是否曾经要实现品牌体验或设计语言，比如微软的Fluent UI或谷歌的Material Design？

你是否曾经想要缩短应用程序的启动时间、提升渲染速度或减少内存消耗？

你是否想过基于原生Web组件构建应用程序，而不受现代JavaScript前端环境的影响？

你是否为项目中多团队高频迭代开发核心组件的质量和稳定性后知后觉而焦虑？

背景

智能运营团队在活动可视化配置项目中，创建活动300+，上线的半年时间内访问量1800W+，每天的PV突破10W+ ，每天登陆用户数4W+。可视化配置工具细分的业务场景也越来越多，有H5可视化、APP可视化、小程序可视化等多类业务，覆盖到**各端。

我们平台运营团队负责运营活动、APP配置等任务，提供平台能力支持业务线发展，智能运营平台本身是一个平台业务，还承担着新业务发展平台的角色，这意味着想要支持好平台业务的发展是一件非常有挑战的事情。

发展路线

以APP可视化为例，在数字化转型初期，APP页面可视化配置对接了两个APP的诉求和使用 场景有很大的不同，经过多个版本的迭代APP可视化配置存在着业务互斥和优先级的关系。业务方急需在短期内快速更新迭代来验证业务方向。因此APP开发复杂度和协作成本是极高的，同时带来迭代边际效应越来越低。由于不同团队/人员缺少统一、标准的开发规范和风险意识，体验和稳定性难以保障，严重影响用户增长和业务发展。

面临的问题

1. 组件在多个业务上无法复用。
2. 类似的组件在各端展示风格上不统一，差异较大。
3. 开发复杂度高，公共能力提取困难。
4. 团队间无法协同工作。

解决问题的思路

我们公司甚至其他公司各个团队搭建都分别使用着不同的框架及对应的组件库产品，以满足各自的业务诉求，提升研发效能。这些组件库体系各自独立维护，彼此割裂。随着各业务的规模不断扩大，这种割裂局面愈发严重。

而且当不同小组的业务需要合并、复用，或者人员变动的时候，切换到新的框架，带来的成本非常高昂。其中有一部分原因是当框架切换的时候，UI库也必须同步切换。

目前看到的组件库没有特别全面的，大都是按照ant design、 element ui，这种细较粒度的拆分来做的，正是因为拆分太细，导致几乎都不带什么逻辑，所以大都是带样式的元素这种形态，其实和使用CSS样式库没什么区别，反而会因为需要先运行js注册组件而导致页面渲染阻塞。

在这个过程中，我们结合组件化思想，以及 Web Components 规范辅助理解。Web Components 规范是 W3C 推出的一套用于封装具有复用性、互动性前端组件的技术规范，旨在提供一种标准的组件化模式。

目前流行的几个前端框架（ Vue / React / Angular ）都在一定程度上遵循了这套规范，自定义组件使用的是 Shadow DOM，这项技术是 Web Components 规范的一部分。

整体数据

下图显示了customElements.define至少调用一次的页面加载百分比（在 Chrom e 中）

我们可以看到，在 Chrome 浏览器中查看的所有网站中，超过 15% 的网站至少注册了一个自定义元素。相比之下，根据 w3techs.com 的数据，只有 2.3% 的网站使用 React。

那么，使用 Web Components 带来了哪些改变？我们来举个。

以前：

A：我造了一个Vue3的轮子，是关于身份信息卡片的。

B：正好，我需要我试试。wtf 是vue3的啊，我vue2用不了。

C：好可惜，我是react框架，也用不了。

D：啊！我是angular，也用不了！

E：老jq项目能不能用？

F：我引入了，但是和我目前项目的逻辑冲突了！

假如基于 Web Components 构建：

A：我造了一个Web Components的轮子，是关于身份信息卡片的，引入标签就能用了。

B：正好，我需要我试试，好像可以，用起来好简单！

C：我是react框架