为啥2.0不用1.3版本async这个模式

[ZhongGuoDragon]

用起来更加简单，复制粘贴也方便，也不会手动配置错误。有时候一个页面好几个异步组件写起来好麻烦又容易漏配置，而且async一看就知道是异步组件了。
这个改为配置式是有啥好处，不是很懂。
我觉得以前的那种模式挺不错的，比现在方便多了，现在使用起来这个东西心智都比以前高了，为啥这么改？

[Vanisper]

你好。
你指的是异步组件引用 xxx.vue?async 吗？

确实是的，这是我最早的方案，我也觉得这是很自然很方便的，比较符合“人体工程学”，但是后面逐渐发现了一些问题：

自定义语法带来的负担

xxx.vue?async 为自定义语法，插件本身需要为此做组件引用的扫描，筛出这种情况的引用，然后生成类型声明文件。
这样子在编辑器中才会有组件的类型提示，这个问题其实算是解决了的。
但是由于 uniapp 项目的热更新机制比较难把控，例如：

• h5 端的热更新其实就是 dev 状态下的热更新，这个的表现是比较容易把控的，比较符合认知；
• 然而小程序端的热更新则是在 build 模式下的“热更新”，这个情况下的热更新表现十分难把控，因为 uniapp 项目小程序侧的 dev 模式的热更新好像是有 “按需差量更新” 的机制，vite 插件内部对这种热更新行为的捕获不稳定。

为了能够保证所有写过的的 import xxx from "xxx.vue?async" 都能被记录到类型声明文件中，
最后我的方案是 始终是增量写入 类型声明文件，也就是说如果你中途删掉了某一个组件的异步引用，
他还是会被记录到类型声明文件中，这个声明文件会越来越冗余。
当然这个问题是小问题，是可以接受的。

---

另外一点就是，我发现有些人是有 自定义占位组件 的需求的。
xxx.vue?async 的原理就是在编译到小程序时，在组件 json 文件中写入如下类似配置：

{
  "usingComponents": {
    "xxx": "../../uni_modules/xxx"
  },
  "componentPlaceholder": {
    "xxx": "view"
  }
}

注意这里的 componentPlaceholder 是关键配置，你可以看到 xxx 组件名后面对应的值是 view。
这个的意思就是，在这个异步组件未加载之前，会先使用 view 这个组件占位，view 这个就是小程序端的一个普通组件。
有人是有自定义这个的需求的。

我早期也是想过，还是在 引用路径后面的查询参数 上加东西，可能类似于 import xxx from "xxx.vue?async&custom-view" 这样的语法。
如果是编译的话，还是很好实现的，但是类型声明就完全行不通了，我找过很多资料，最后的结论是 ts 目前还实现不了这么复杂的类型声明，因为我理想中需要实现 /\?async(?:&.*)?/ 这样的一个匹配的类型，ts 中至少目前无法实现。

这个类型声明没能解决，于是我就搁置了这个功能的开发了，直到 2.0 版本大重构才能有机会继续。

---

之后的一点就是，webstom 编辑器不支持我前面生成的那个类型声明，只在 vscode 有效，可能这是 webstom 的 ts 语言服务器问题，没做深入研究。

[Vanisper]

2.0 之后的版本，则是完全摒弃了之前的两个自定义语法（AsyncImport 函数，以及上面讲的自定义 ?async 引用后缀）。

完全抛弃之后，路子就畅通了很多。

开发难度降低

从 ?async 引用，重构成了需要做一个小配置。
使用上确实是没之前那么顺手了，但是这让插件的具体实现的复杂度降低了。
因为不用处理很多无关的问题，之前还要考虑热更新时要生成类型文件、还要对自定义语法做记录，都是负担。
现在不用考虑了，代码复杂度大大降低，这也使得插件的稳定性提高了。

?async 是便利的，但是前面提到了，不能再拓展自定义占位组件的需求了，导致 1.x 版本有些功能上不了。
现在转成配置式，换来的是稳定性和功能拓展性的增强。

原生语法支持

现在都是用的 js 原生语法，根本不用考虑类型提示的问题，这点的好处也不用多说。