小程序现有的开发模式是基于已有的小程序基础库提供的组件，通过自定义业务的样式实现自定义化和功能。
随着生态的逐渐丰富，一些企业会沉淀出自己的组件库。不过，对于组件来说更多的体验直接围绕着可视化，比如 像图片，视频，可直接运行的示例代码。下面会分析一下，现有小程序生态的现状和未来可以走的方向。
组件生态分析
一个可使用的开源库的发展路径如下：
- 模块包文件(比如像 lodash 基本处理工具) =>
- 单一组件使用( flex-scroll 组件) =>
- 整体组件 UI
主要限制条件在于：marginal revenue === marginal cost（边缘投入产出比）. 上面不同开源库的拥有者，通常是由 个人 到 企业，因为库的工作投入量是递增的(可以理解为成本)，但是个人或者小范围的 group，他们的 marginal revenue 是有限的（当然，如果基于整个生态开发者来说，就不在这个讨论范围内）。由于增加人数和组件产出增量是 边缘递减的, 所以, 只有在一些人力调整灵活的企业中，诞生最终形态组件库的几率更大，比如现有大型组件库 ElementUI, AntDesign, WeUi 等。
上面说的大型组件库常常具有下面几个特点：
- 规范的组件规范, 文档
- 组件生态工具
- 可视化展示
- 丰富的 example
- 可用的 boilerplate
- 下载 —> npm
- 测试 —> jest
- 组件生态社区: 有 PR，有 issue 反馈
受众分析和需求分析
小程序架构和开发方式，就已经决定了小程序面向的开发群体和受众：具有一定 Web 开发经验的开发者。所以，组件化生态一般是对齐 Web 的组件生态，比如像 React、Vue 等组件开发框架。现有 Web 组件化生态具备的要素有如下几个：
- 组件规范和文档
- 可视化展示和运行 demo —> codepen、codesandbox
- 下载工具 —> npm
- 自动化测试 —> jest headless chrome
参照一个比较成熟的 elementUI 库，对比上面 Web 组件化生态库的标准要素，应该会更好理解。该库的标准应该算是很高，在拥有上面标准外，还有其他的内容：
- international
- CHANGELOG: 描述版本的更替和 commit 内容
- YML CI: 能让其它 contributor 在流水线上运行和发布该版本
- eslint: 组件库的代码规范
- …
对比上面 Web 组件化的标准，小程序组件化生态所欠缺的
- 下载工具：现有的做法是直接依赖 Web 生态下的 npm 工具。不过，由于开发差异，这里并不能直接通用，还需要在开发者工具上手动转一遍。优化预期，能否提供其他的 cli，实现可以直接 install 的体验性。
- 自动化测试: 因为小程序是双线程运行，已有的 headless chrome 不适合用来作为基础测试底层。june 曾写过 simulate 来简单运行小程序代码工具，不过体验有待加强。
- 可视化展示和运行 demo: 对标 codepen，提供原始代码并且能够配合文档直接预览 ，现在是空白滴。随着后面，PC 端的加入，这块的需求其实更重要。
tips: 最近听说 PC 小程序已经在内测中，对于组件化生态来说，三端组件外观对齐，是一个强需求。
对比上面现有的分析，其实还有一个更大一点的想法：
实现一个开源组件化仓库管理，提供更多原始可控的体验
- 组件化生态社区，通过开发者决定好用的组件库
- 可直接在工具内选择下载对应的组件，或者提供匹配的 cli
- 提供 自动化测试
- 可视化运行
- 文档预览
- 提供更多小程序特例工具的服务体验
- 具备一定的安全审核和非中心化管理的 features
接下来，会对小程序组件生态、非 Web 组件生态、多端组件生态的大致发展现状做下分析。
小程序组件生态
小程序组件其实是整个小程序中的 1/4 部分，剩下的还包括 框架，小程序API，服务端API。
小程序和 Web 是同源同生，或者说，小程序继承于 Web，只不过拥有了 Web 不一样的发展方向和安全性。下文说的小程序一般特指 微信小程序。
以前，官方组件的表现形式是 图片 代码，后面加上了 code segment，来增强组件端预览的体验。不过，由于工具自身的设定和限制，打开一个组件预览需要 3 个步骤：点击，在工具中确认信息，打开。成本会上升，抑制我去预览该组件的 revenue(收益).
现在增加了，instant preview 的效果，文档中会直接附带文档预览的效果。这种方式，算是对可视化组件的一个补充。
其中，小程序生态组件库做的比较好的有:
- vant
- weui
taro UI 组件库
taro 是以 React 的方式来写多端小程序的一种方式，它原理和小程序类似，按照 taro 的语法，结合 taro-components 来完成最基础的书写方式。同时，维护一定的社区生态，提供了 taro-UI 帮助开发者快速构建 taro 应用。
taro UI 的可视化表现形式有可直接运行的实例。这个体验性还是很不错的。
其组件库的标准也很高，有 travis, eslint, CHANGELOG 等开源库的标配。
flutter 组件生态
flutter 是一个跨 IOS 和 Android 的 SDK UI 库。主要目的在于一套代码多端复用。
Flutter is Google’s mobile app SDK for crafting high-quality native interfaces on iOS and Android in record time. Flutter works with existing code, is used by developers and organizations around the world, and is free and open source.
由于目标平台不是 Web，所以在官方文档上的表现形式是通过代码 图片的方式结合，并同时附带有对应代码片段。听说，后面新增 Web 平台，期待它在 Web 下组件生态有没有新的 features.
对于 flutter 周边组件，其生态并不是令人满意。下图是摘至 awesome-flutter。可用并且好用的组件其实并不多，而且 the amount of stars 可以说对于 google 生态来说很低了。
资料参考：
- miniui
- 微信开发工具组件生态
- 有赞小程序开源库
