一个真实的反模式 API 设计案例…

用工具支持 monorepo 模式。

在做一般的应用产品开发时，通常会基于特定的平台（比如 Android、iOS）、框架（Vue、React）或者技术标准（Servlet）等等。
这些开发平台通常经过精心设计，给程序员提供一个受控环境和开发模板，程序员在这个特定的环境中按照开发平台的规范进行开发。

集错误之大成：前朝的剑斩本朝的官。

小程序App、Page 和 Component 是通过函数调用的方式来实现创建的，通过函数参数 option 来定义数据和行为，通过 Behavior 来实现复用。
但是在抽象组件的时候，会面临几个问题：

1. 小程序没有继承体系。
2. 部分 option 的属性无法通过 Behavior 来组合/混入。

由于小程序没有使用“组件类”的构造方式，无法使用继承，因此，小程序框架提供了“混入”（mixins）方式的复用机制，“混入”主要通过 Behavior 来实现。
根据官方的定义：

每个 behavior 可以包含一组属性、数据、生命周期函数和方法。组件引用它时，它的属性、数据和方法会被合并到组件中，生命周期函数也会在对应时机被调用。每个组件可以引用多个 behavior ，behavior 也可以引用其它 behavior 。

虽然小程序提供了基于 Behavior 的复用机制，但 Behavior 对 Component 和 Page 的支持程度不一样，有必要详细区分一下。

小程序文档中关于“组件间通信与事件”的部分写得比较简单，在此主要记录官方的几种标准用法，以及一些骚操作。

在开发一个客户端应用时，通常都需要按照框架定义的模式来编写代码，最常见的是覆盖框架定义好的生命周期方法。

以微信小程序为例，当我们定义一个页面的时候，模板代码如下：

微信小程序大致可以认为是“微信 - App - Page”这样的三层结构，微信是 App 的宿主，App 是 Page 的宿主，宿主的状态会影响旗下子元素不同生命周期方法的调用。微信自身维护 Android、iOS等操作系统要求的生命周期方法，至于微信怎么定义小程序的生命周期，那全都是微信说了算。