基于 Taro RN 的小程序容器方案讨论

[charlzyx]

这个特性解决了什么问题？

当前 Taro RN 解决方案一些 case 考虑:

• 1. RN 跟小程序 or H5 有关键能力不同, 所以实际需求场景中, 会针对各个端有不同的需求, RN/小程序/H5 同构的项目架构上理想, 但是实际场景中, 不太容易遇到
  • 1.1 小程序的各种抹平已经有比较高的复杂度, 加上RN的抹平的话, 同构项目的可维护性是在堪忧, 因此实际应用中, 应该还是底层是 taro 但各个端单独repo维护
• 2. taro-playground 现在是 ios/android/fe 维护在一个 repo 中, 类似于 expo taroify, 或者类似 CRN 这种有热更场景需求, 甚至, 壳子单独 build, 业务包单独下发(or biz patch) , 基于这种考虑, taro rn 可以更进一步, 抽象为 小程序容器 解决方案, 壳子中实现基础 sdk, 就像小程序版本那样, 业务包(or patch) 在线分发, 会更加有实际应用场景, 最近在做这方面的相关工作, 有进展回头同步过来

关于 Taro 架构

taro-preset-taro 中 https://github.com/NervJS/taro/blob/next/packages/babel-preset-taro/index.js#L6 这里可以看到, rn 的 preset 是单独的, 所以其实 rn 的项目会安装一大坨并不需要的依赖, 由此联想到的, 可能我只需要 h5, 或者只需要某个小程序, 那么其实并不需要装其他 platform 相关依赖, 当前 taro 已经支持 plugin-platfrom-xxx 来支持各种小程序, 但repo中的依赖关系看起来并不清晰, 但我了解的还不够透彻, 只是有个初步的不成熟的小想法, 假如:

能够抽取一个 @tarojs/core 已有的 @tarojs/api @tarojs/components 作为抽象层存在, 各个platform 作为 platform-preset, 各个 preset 中分别包含 platform-runtime, platfrom-platform(api lib), platform-babel-preset 这样, taro 的抽象应该更加干净(感觉上), 而上面所提到的基于 Taro 的小程序容器方案, 也可以更加容易去定制实现

其他

Taro 做了件很伟大的事情, 统一了 api/components 的interface, 某种程度上, 可以看做是小程序 SPEC (https://github.com/w3c/chinese-ig/tree/main/tf/mini-app) 的一个可行实现, 提一些不成熟的想法, 希望能让它越来越好 [笔芯];

这个 API 长什么样？

plugin-platform-xxx ~> preset-platform-xxx

[charlzyx]

platform-preset 还可以利用 namespace 与类型合并，使得插件类型更加好编写
比如
// core
namespace Taro {
// 路由部分
interface Router {
switchTo(...args) {}
}
}
// wip