小程序跨端组件库 Mpx-cube-ui 开源：助力高效业务开发与主题定制

背景

随着越来越多的业务产品通过小程序这一渠道进行推广和使用，各个技术团队也开始根据各自业务产品的需求进行定制化开发。在滴滴的所有小程序产品中，滴滴出行小程序作为最大的C端流量入口，负责将不同业务的流量进行有效分发。在具体的小程序产品研发过程中，这些不同业务的小程序被集成到滴滴出行小程序中，统一打包上线和发布。

在这种跨业务和技术部门的产品研发环境下，各技术团队都注重构建自身的基础能力。以小程序的组件库为例，每个独立业务产品都会根据自身的交互设计规范，构建一套符合业务需求的基础组件，以提高日常业务开发的效率。这些基础组件可能包括按钮、半浮层弹窗、Toast、Dialog、表单等。

除了在跨业务产品研发场景中，同一技术团队内部也可能需要应对来自不同业务产品方向的需求。这些不同业务产品同样具有独立发展和迭代的需求。由于业务场景的限制，团队内部也需要考虑如何积累和复用基础能力，以便在节约研发资源的同时提高业务项目交付的质量和效率。

在不同业务产品的发展初期，为了快速交付产品功能并确保上线时间，研发团队会尽可能地利用已有基础能力来快速构建产品功能。以小程序组件库的复用为例，常见的做法包括：

直接在原有组件代码中进行硬编码（Hard Code），使不同业务产品依赖于同一份组件代码。通过使用if/else或条件编译等手段，使原有组件既能满足最新业务需求，又不会影响原有业务的使用。
Fork 一份原有组件库的代码，并在其基础上进行单独迭代和维护，从而实现与原有组件的完全隔离，避免产生污染。

然而，这两种方案都存在一定的问题。对于第一种方案，由于组件本身需要满足差异化的增量需求，导致组件的维护成本增加。同时，在处理差异化代码时，可能会在编译打包环节出现代码冗余问题，即原本不属于当前业务产品的代码实现也会被一同打包。对于第二种方案，组件库维护的数量增多，使得后续的组件迭代和更新需要在多处进行修改。

此外，在小程序场景下，还需要面对平台规范对包体积的硬性约束。尤其是对于像滴滴出行小程序这样的大型小程序，众多小程序业务产品被集成到同一个小程序中，包体积成为日常研发过程中重点关注的一个指标。良好的模块或组件复用性和可扩展性意味着无需重复开发相同功能代码，从而避免因重复实现相同功能而导致代码包体积过快增长。

Mpx 技术生态

在 Mpx 的技术生态中，目前的组件体系尚不完善。

目前使用 Mpx 去开发实际的业务产品的过程中，我们基于小程序平台的基础组件去搭建了特定业务场景的基础业务组件，因为业务场景、功能和代码实现等各方面的原因，这些业务场景的基础组件是没法开放给社区的 Mpx 开发者来使用的。因此，社区开发者要么只能基于平台的基础组件开发上层基础组件，要么使用第三方原生小程序组件库。无论哪种方式，社区开发者都需要付出一定的学习和开发成本。

此外，社区中也有不少用户希望 Mpx 能够提供更基础、更通用的组件，以更好地支持上层业务开发。

无论是我们内部维护的业务组件库，还是之前开源的基于 Vue 的 Web 组件库 Cube-ui，组件的文档和示例都是组件库迭代过程中的重要组成部分，需要花费大量时间和精力。在示例和文档方面，通常需要编写多份文案，并确保它们之间的同步更新。因此，如何降低组件库本身的维护成本，也是我们亟待解决的问题之一。

以上这些问题促使我们重新审视整个 Mpx 组件体系的构建和发展。