- 提案时间: (格式为YYYY-MM-DD)
- 影响版本: (2.x / 3.x)
- 相关 Issues: (如果有的话就填上)
简单地描述这项功能。
为什么我们要做出这个更改？一般应对什么样的场景？这样做会产生什么结果?
如果提案新增或更改 API ，需要带上一个基本的代码案例。
可选，请向一个熟悉 Taro 内部实现的人讲解如何在 Taro 中实现这个功能，或讲解实现这一功能需要什么步骤。
我们是不是可以不做这个功能，请考虑：
- 实现这个功能的投入：包括代码的复杂度、代码体积的增加、实现功能投入的人力
- 这个功能是不是不需要 Taro 提供，使用 Taro 的开发者也可以在应用层实现，甚至实现得更好
- 对 Taro 既有惯用开发习惯的影响
- 对已发布版本和现有功能的影响，以及用户进行迁移的成本
- 对其它未有代码实现的 RFC 提案的影响
还有其他的方案也可以实现这个功能吗？
如果我们实现了这个提案，有没有什么办法可以帮助开发者更好地适应这个改动？