Taro v3.6 代号为「Reach」，已发布 canary 版本

November 18, 2022 · 19 min read

Flame

Taro 合作者

Taro 合作者

Taro 合作者

Taro 合作者

58 同城前端架构师、Taro 技术委员会成员、Taro-RN 工作组 Owner

Taro 技术委员会成员、Taro Core 工作组 Owner

Taro 技术委员会成员、Taro Core 工作组

近期我们确定了 v3.6 版本的代号「Reach」，并发布了 v3.6-canary 版本，多个新特性在该版本内开放给社区各位开发者体验，欢迎大家试用并在社区中反馈相关问题。

taro-3.6.jpg

一、支持路由库

Taro 3 适配前端 UI 框架的方式更接近于前端的本质，通过在小程序端模拟实现框架所需的 BOM/DOM API 来达成，对于适配各个路由库也是同样的思路。

1. 运行时引入 History & Location 对象

在 Web BOM 中，History & Location 对象是重要组成部分，它们是实现前端路由的关键。Taro 为了支持前端路由库的使用，在运行时中引入了 histroy location 对象的实现，且尽可能与 Web 端规范对齐，你可以在 window 对象上访问到 history 和 location 对象。同时，也支持监听 hashchange 和 popstate 事件，这为使用路由库提供技术基础。

// 统称: 页面路由状态
window.history
window.location

// 支持监听事件
window.addEventListener('hashchange', () => {})
window.addEventListener('popstate', () => {})

小程序天然支持多页面(pages 数组配置)，因此 Taro 并非以整个应用为一个路由系统，而是顺应小程序规范以页面维度进行路由管理。每当切换页面时，会将当前页面的页面路由状态缓存。跳转至新页面后会重新创建页面路由状态，并挂载在 window 对象上。当返回上一级页面时，会将上一级页面的页面路由状态重新挂载到 window 对象中。

2. 使用路由库

至此，可以在小程序中使用成熟的前端路由库了，包括 react-router 和 vue-router。在路由库中，诸如 <Link> 组件内部会动态生成 <a> 标签，因此需要引入 [@tarojs/plugin-html](https://docs.taro.zone/docs/use-h5) 插件以支持在 Taro 中使用 html 标签开发组件。

{
  "plugins": ["@tarojs/plugin-html"]
}

在 Taro 编译过程中，当 DOM 序列化数据的 nn 字段为 HTML 标签时，标签会映射为对应的小程序组件名称。由于无法提前预知动态标签，因此需要应用显式告知可能会使用到的动态标签。例如在应用中塞入一个无样式的标签名即可：

<View>
  <a></a>
</View>

更多细节可以查看官方文档，也可以查看官方提供的 DEMO 获知更多用法。

二、跨框架组件库

借助于 stencil，Taro 3 得以通过 Web Components 实现一套跨框架组件库，不过由于其 2.14+ 版本会使用一些 webpack4 不兼容的语法特性，在 3.6-canary 之前的组件库将 stencil 版本限制在 2.13+ 版本内，在 3.6-canary 版本中也针对该问题进行了修复，同时借助 stencil 的新特性优化诸多组件库在 props 与事件的遗留问题。

1. Web 端框架适配器

Web Components 虽然可以在各个前端 UI 框架中使用，但是依旧会有很多兼容性问题，这些可以通过 Custom Elements Everywhere 的一系列测试用例有所了解。所以在 Taro 3 发布之初，Web 端跨框架组件库还通过提供不同前端 UI 框架的自定义适配器，让不同框架使用 taro 提供的跨框架组件。

尽管这套适配层方案能够很好的兼容 react 框架，但对于组件库的维护者来说会额外的心智负担，比如新增组件时需要同步更新适配器；这个问题在 vue 中则更为明显，不仅 props 需要额外的配置，表单类组件也需要对事件进行标注等。这些问题不仅提升了新同学介入组件库维护的门槛，也使得维护者不能专注于组件库的能力优化。

解决问题的方法当然也很简单，那就是通过脚本在组件库编译时针对不同 UI 框架自动化导出对应组件，社区内也有足够多方案可供选择。在这里我们使用官方提供的 ds-output-target 工具并在一定程度上调整输出结果，并同步过往适配器中 Taro 做出的体验优化。

在 3.6 版本中，新的适配层不仅对齐各个框架组件使用体验，同时也补齐过往适配器在迭代过程中部分特性兼容性的缺失问题。如果依旧希望使用 3.6 以前版本适配器，也可以参考以下示例，通过配置别名替换组件库。

// config/index.js

const config = {
  h5: {
    webpackChain(chain) {
      chain.resolve.alias.set(
        // 当前版本适配层地址 @tarojs/components/dist/[framework]
        '@tarojs/components/dist/react',
        // 旧版本适配层地址 @tarojs/components/dist/[framework]/component-lib
        '@tarojs/components/dist/react/component-lib'
      )
    },
  },
}

2. 类型自动生成

如何快速同步各小程序平台当前支持的类型，对于 Taro 来说一直是个很让人头疼的问题，实时跟进各个平台的每一次更新很难做到，更多时候我们都通过开发者提交的 PR 或 issue 对这些平台的类型更新。如果能够根据各个小程序平台官方提供的文档自动化生成组件类型，这对于开发者来说会是一个很棒的体验。

通过在 Taro 社区中的积极探讨和论证，我们引入了自动同步各小程序平台组件类型的脚本，并通过与 GitHub CI 让机器人为 Taro 仓库提交类型更新 PR。组件类型的自动化同时让 Taro 的文档在类型更新时，同步这些平台组件的变更，为开发者提供更好的文档索引能力。

在这里特别感谢 @rebinv8 为组件类型自动化脚本做出的贡献～

三、支持适配鸿蒙

在 Taro 与 OpenHarmony 建立官方合作关系，并受邀成立 CrossPlatformUI Sig（跨平台前端框架兴趣小组）后，让 Taro 支持适配鸿蒙就一直在议程上，鸿蒙的方舟开发框架提供类 Web 范式编程，支持使用 JS 开发 UI 层，其语法与小程序相接近，可以沿用 Taro 现有的架构适配鸿蒙。

taro-harmony

持续关注 Taro 的开发者可能还记得，在 v3.5-canary 版本时，我们曾推出支持 Taro 应用适配到鸿蒙平台的插件，但最终没有合入 v3.5 版本主干并顺势推出该能力。在 @tarojs/plugin-platform-harmony 端平台插件经过一段时间的打磨，相关能力与特性也在社区推进下持续优化，框架编译的项目在鸿蒙开发板上得到进一步验证，同时在 Taro v3.5 新增的 @tarojs/webpack5-runner 编译内核在 canary 版本中也能够为鸿蒙项目编译提供支持，终于我们在 v3.6-canary 中再次为社区开发者提供了适配鸿蒙的端平台插件。

使用方法

在项目中安装鸿蒙端平台插件
```
pnpm add -D @tarojs/plugin-platform-harmony@canary
```
需要注意鸿蒙插件不在 Taro 项目内维护，所以并不会每次发布同版本号版本，直接使用 minor 与 Taro 版本号相同的版本即可。

在 config/index.js 中增加编译配置

// config/index.js

config = {
  // 配置使用插件
  plugins: ['@tarojs/plugin-platform-harmony'],
  mini: {
    // 如果使用开发者工具的预览器（previewer）进行预览的话，需要使用 development 版本的 react-reconciler。
    // 因为 previewer 对长串的压缩文本解析有问题。（真机/远程真机没有此问题）
    debugReact: true,
    // 如果需要真机断点调试，需要关闭 sourcemap 的生成
    enableSourceMap: false,
  },
  // harmony 相关配置
  harmony: {
    // 【必填】鸿蒙应用的绝对路径
    projectPath: path.resolve(process.cwd(), '../MyApplication'),
    // 【可选】HAP 的名称，默认为 'entry'
    hapName: 'entry',
    // 【可选】JS FA 的名称，默认为 'default'
    jsFAName: 'default',
  },
}

准备鸿蒙运行环境
开发鸿蒙软件需要用到 HUAWEI DevEco Studio，它提供了模板创建、开发、编译、调试、发布等服务。
鸿蒙运行环境主要包括以下内容
（1）注册开发者账号
（2）下载 DevEco Studio 安装包
（3）启动 DevEco Studio，根据工具引导下载 HarmonyOS SDK
（4）新建 MyApplication JS 项目
（5）使用预览器或真机查看应用效果
参考资料：《初窥鸿蒙》、《华为开发者工具》、《鸿蒙开发文档》
项目运行
Taro 编译鸿蒙项目命令
```
$ taro build —-type harmony —-watch
```
testHarmony 为您通过 DevEco Studio 创建的 JS 项目。

特别感谢以下同学为鸿蒙适配作出的贡献：

@AdvancedCat、@jiaozitang、@huozhongyi123、@troy-sxj、@JSZabc、@crazyonebyone、@evernoteHW、@soulhat、@xueshuai、@LuMeiling

四、RN

1. React Native 0.70 版本支持

React Native 0.70 版本已于 2022-9-5 正式发布。在 0.70 版本中 Hermes 已成为默认的 JS 引擎，我们将与 RN 默认配置保持一致，如不需要可自行关闭。Hermes 也带来了 RN 性能的较大提升，特别是启动场景，详细内容参考官方文章。 Taro 将与 RN 社区保持同步，将默认的 RN 版本设置为 0.70。相关依赖也已同步至最新版本，仍然可使用 yarn upgradePeerdeps 进行更新。@react-native-community/clipboard 及 @react-native-community/cameraroll 已被弃用，更新后可删除。

注意：升级后将不再支持 iOS 12，详细内容请参考 discussions。

2. @tarojs/rn-runner 代码重构

之前的版本中，为了让 Taro 代码能够运行在 RN 平台上，我们对 Metro 的编译过程做了较多的定制，并且封装了入口文件以及 metro 的相关配置。这样做导致了多个问题：

打包只能通过 yarn build:rn 等方式进行，而无法使用 react-native bundle 进行，存在学习成本。
RN 的编译流程中，需要过滤掉 RN 原有的 bundle 打包过程，替换成 Taro 的打包。这一步在开发者环境搭建过程中，常常出现问题。
无法对入口文件进行处理，比如加入一些全局逻辑。

为了让整体开发体验跟 RN 更加一致，减少开发者的理解成本。我们对 @tarojs/rn-runner 的代码进行了重构。将 Taro RN 需要的所有编译逻辑，都封装到了 metro 配置中。新版本在项目根目录下会创建入口文件 index.js 和配置文件 metro.config.js。如项目本身有这两个文件，则不会生成，需要参考模板进行添加或合并。另外 Taro RN 的相关配置，集中在 resolver 和 transformer 中，如需覆盖，建议先看一下相关源码。

这样做之后，Taro RN 的打包过程就与 RN 本身无太多区别，与 RN 项目集成会更加灵活。react-native 命令行的使用，请参考官方文档， yarn build:rn 等命令仍然保留。使用 react-native 命令行无法自动打印二维码，请输入 q 进行打印。ip 更换等场景，也可以输入 q 重新打印二维码。

3. 调试工具 Taro Playground 升级至 Taro 3.6 版本及 React Native 0.70

Taro Playground 作为 Taro RN 端的调试工具及跨端 Demo，进行了同步更新。此次更新无法保证向下兼容，使用旧版本 Taro 的开发者，如需调试 Android，可在 releases 中下载旧包进行调试。在 App Store 中，我们只上架最新版本，需要旧版本的开发者请不要开启应用自动更新。如不慎升级，需自行打包编译，或联系我们加入测试组。

五、研发生态

1. 小程序持续集成 CI

去年 Taro 提供小程序持续集成插件 @tarojs/plugin-mini-ci ，帮助开发者提供更好的研发体验，经过一年的项目沉淀和反馈，在本次版本更新中提供了更优秀的体验。

本次新增特性支持独立的 open、preview、upload 命令，操作自定义目录适用于将 taro 作为项目一部分（混合开发）的开发场景；同时再次同步各个小程序端的 CI 版本变更，并支持应用到钉钉小程序上；统一所有平台 CI 构建后的输出数据，并将数据传递给新增的onPreviewComplete、onUploadComplete两个钩子用户可以编写新的插件，基于这个钩子实现飞书、钉钉的 CI 推送功能等等。

更多详情可以参考官方文档，同时要特别感谢 @bigMeow 为组件类型自动化脚本做出的贡献～

2. PostCSS 版本升级

在 Taro 项目持续迭代的过程中，部分依赖稳定没有实时跟进各个社区内的特性与优化，并升级相关依赖，PostCSS 就是其中之一。如果开发者想要通过新版本的特性来优化构建流程与最终产物，相对会很困难且可能会存在一定问题阻塞。

为此在 3.6 canary 通过梳理项目内相关插件与依赖，对 PostcCSS 版本进行梳理并升级，升级后版本为 v8.4.18。本次升级主要包含以下内容：

对 Taro 内部的 PostCSS 插件使用 PostCSS 8 版本 API 进行改写，降低代码量同时减少插件对 CSS 扫描次数进而提高构建速度；
使用 peerDependencies 管理 postCSS 依赖，降低用户的 node_modules 体积和复杂度；
对 Taro 全量模板的 PostCSS 版本同步进行更新，方便开发者对新特性的使用。

特别感谢 @xueshuai 为相关工作做出的贡献，希望开发者可以因此获得更好的研发体验。

六、升级指南

1. 创建 canary 版本项目：

# 安装 **v3.6.0-canary 的 CLI 工具**
npm i -g @tarojs/cli@**canary
# 创建 canary 版本项目
taro init taro_canary_project

# 也可以跳过安装 CLI 工具使用 npx 创建 canary 版本项目
npx** @tarojs/cli@**canary init taro_canary_project**

2. 已有项目升级到 canary 版本：

将 package.json 文件中 Taro 相关依赖的版本修改为 3.6.0@canary
重新安装依赖，如果安装失败或打开项目失败，可以删除 node_modules、yarn.lock、package-lock.json 后重新安装依赖重新尝试。

最后

Taro v3.6 代号「Reach」，致远星代表着不屈和希望，希望该版本能够给开发者带来更好的用户体验，感谢各位参与到 Taro 开源生态共建的同学们，所有的努力都让 Taro 的生态更加美好，为建立更加完善、更加可持续的 Taro 开源生态，贡献力量！

一、支持路由库​

1. 运行时引入 History & Location 对象​

2. 使用路由库​

二、跨框架组件库​

1. Web 端框架适配器​

2. 类型自动生成​

三、支持适配鸿蒙​

使用方法​

四、RN​

1. React Native 0.70 版本支持​

2. @tarojs/rn-runner 代码重构​

3. 调试工具 Taro Playground 升级至 Taro 3.6 版本及 React Native 0.70​

五、研发生态​

1. 小程序持续集成 CI​

2. PostCSS 版本升级​

六、升级指南​

1. 创建 canary 版本项目：​

2. 已有项目升级到 canary 版本：​

最后​

一、支持路由库

1. 运行时引入 History & Location 对象

2. 使用路由库

二、跨框架组件库

1. Web 端框架适配器

2. 类型自动生成

三、支持适配鸿蒙

使用方法

四、RN

1. React Native 0.70 版本支持

2. @tarojs/rn-runner 代码重构

3. 调试工具 Taro Playground 升级至 Taro 3.6 版本及 React Native 0.70

五、研发生态

1. 小程序持续集成 CI

2. PostCSS 版本升级

六、升级指南

1. 创建 canary 版本项目：

2. 已有项目升级到 canary 版本：

最后