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

来源: 投稿
2022-12-12 19:56:00

近期我们确定了 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。在路由库中,诸如

组件内部会动态生成 标签,因此需要引入 [@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 中再次为社区开发者提供了适配鸿蒙的端平台插件。

使用方法

  1. 在项目中安装鸿蒙端平台插件
    <pre style="margin-left:0; margin-right:0">
    

    pnpm add -D @tarojs/plugin-platform-harmony@canary

    <blockquote>
    需要注意鸿蒙插件不在 Taro 项目内维护,所以并不会每次发布同版本号版本,直接使用 minor 与 Taro 版本号相同的版本即可。
    </blockquote>
    </li>
    <li>
    在<span> </span><code>config/index.js</code><span> </span>中增加编译配置
    
    
    
    <pre style="margin-left:0; margin-right:0">
    

    // 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', }, }

    </li>
    <li>
    准备鸿蒙运行环境
    
    <blockquote>
    开发鸿蒙软件需要用到 HUAWEI DevEco Studio,它提供了模板创建、开发、编译、调试、发布等服务。
    </blockquote>
    
    鸿蒙运行环境主要包括以下内容
    
    (1) 注册开发者账号
    
    (2)下载 DevEco Studio 安装包
    
    (3)启动 DevEco Studio,根据工具引导下载 HarmonyOS SDK
    
    (4)新建 MyApplication JS 项目
    
    (5)使用预览器或真机查看应用效果
    
    参考资料:《<a href="https://juejin.cn/post/6972109475347955749" target="_blank">初窥鸿蒙</a>》、《<a href="https://developer.harmonyos.com/cn/develop/deveco-studio" target="_blank">华为开发者工具</a>》、《<a href="https://developer.harmonyos.com/cn/documentation" target="_blank">鸿蒙开发文档</a>》
    </li>
    <li>
    项目运行
    
    Taro 编译鸿蒙项目命令
    
    
    
    <pre style="margin-left:0; margin-right:0">
    

    $ taro build —-type harmony —-watch

    <img alt="taro-harmony-example" src="https://storage.360buyimg.com/aotu-team/zakary-blog/2022-11-18-Taro-3.6-canary/taro-harmony-example.png" />
    
    <blockquote>
    testHarmony 为您通过 DevEco Studio 创建的 JS 项目。
    </blockquote>
    </li>
    

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

@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 的相关配置。这样做导致了多个问题:

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

为了让整体开发体验跟 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 ,帮助开发者提供更好的研发体验,经过一年的项目沉淀和反馈,在本次版本更新中提供了更优秀的体验。

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

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

2. PostCSS 版本升级

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

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

  1. 对 Taro 内部的 PostCSS 插件使用 PostCSS 8 版本 API 进行改写,降低代码量同时减少插件对 CSS 扫描次数进而提高构建速度;
  2. 使用 peerDependencies 管理 postCSS 依赖,降低用户的 node_modules 体积和复杂度;
  3. 对 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 版本:

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

最后

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

本文作者:

FlameFlame Taro 合作者 大喵大喵 Taro 合作者
robinrobin Taro 合作者 SHUAI XUESHUAI XUE Taro 合作者
zhiqingchenzhiqingchen 58 同城前端架构师、Taro 技术委员会成员、Taro-RN 工作组 Owner JJJJ Taro 技术委员会成员、Taro Core 工作组 Owner
TJTJ Taro 技术委员会成员、Taro Core 工作组  
展开阅读全文
点击加入讨论🔥(8) 发布并加入讨论🔥
8 评论
1 收藏
分享
返回顶部
顶部