跳到主要内容

23 篇博文 含有标签「v3」

查看所有标签

· 阅读需 4 分钟
tangcq
guoenxuan

一、背景

HarmonyOS NEXT Developer Preview 版本发布在即,越来越多的厂商加快产品鸿蒙化进程。如何把已有产品快速迁移至鸿蒙原生是大部分厂商亟待解决的问题之一。在此背景下, Taro harmony-hybrid 平台插件提供基于 Web 开发鸿蒙原生应用的迁移方案。该插件继承 H5 平台,并注入部分鸿蒙原生能力接口,扩展了 Web 应用操作设备的能力,助力厂商的产品快速鸿蒙化。

二、harmony-hybrid 平台

1. 简介

Taro harmony-hybrid 平台插件和鸿蒙三方模块 @hybrid/web-container 是上述方案的两大组成部分。该方案创建的鸿蒙应用的打包部署形态如下图所示:

运行框架

编译 Taro 工程生成 harmony-hybrid 平台的 Web 资源,由 Web 服务器加载运行;鸿蒙应用使用 TaroWebContainer 组件加载网站资源,借助该组件提供的 Taro API 实现来达到业务访问原生与使用硬件的能力。

2. 基于 harmony-hybrid 开发鸿蒙应用

编译 Taro 工程生成 harmony-hybrid 应用资源

通过 Taro CLI 工具基于 默认模板 创建 Taro 工程,使用如下编译命令生成 harmony-hybrid 平台的 Web 资源:

# yarn
$ yarn build:harmony-hybrid

# npm script
$ npm run build:harmony-hybrid

# pnpm script
$ pnpm build:harmony-hybrid

生成的 Web 资源使用 Web 服务器加载运行或者内置于鸿蒙应用的 resources/rawfile 目录下。

创建鸿蒙应用

@hybrid/web-container 三方模块提供自定义鸿蒙组件 TaroWebContainer,为运行其中的 harmony-hybrid 应用提供运行时访问系统设备的能力。

在鸿蒙应用中使用 TaroWebContainer 组件的示例代码如下:

  • entry/oh-package.json5 配置
"dependencies": {
"@hybrid/web-container": "1.0.0"
}
  • 页面中使用 TaroWebContainer 组件:
import { TaroWebContainer, HostPageState, TaroWebController } from '@hybrid/web-container';

@Entry
@Component
struct HarmonyHybridSample {
@State pageState: HostPageState = HostPageState.PageInit;
@State taroWebController: TaroWebController = new TaroWebController();

build() {
Column() {
TaroWebContainer({
webUrl: 'https://域名/index.html',
webUrlPrefix: 'https://域名/',
taroWebController: this.taroWebController,
pageState: this.pageState,
})
.width('100%')
.height('100%')
}
}
}

具体的使用方式可以参考 @hybrid/web-containerREADME.md 文档。

环境要求

  • Taro: 3.6.24 以上版本
  • 鸿蒙集成开发环境: DevEco Studio NEXT Developer Preview1 及以上版本

三、转换补充说明

对于具备小程序版本的产品,可以使用 @tarojs/cli-convertor 命令行工具转化成 Taro 项目,再编译成 harmony-hybrid 来加快适配流程。

最后

后续我们会继续完善对 harmony-hybrid 平台的适配工作,并根据最新鸿蒙系统能力来补齐和完善 harmony-hybrid 平台能力,同时也希望广大的开发者和参与到 Taro 开源生态共建的同学们,能够一起参与harmony-hybrid 平台的构建和完善,助力鸿蒙生态和 Taro 开源生态的发展。

相关阅读

标签:

· 阅读需 28 分钟
TJ

一、背景

跨端是前端研发过程中经久不衰的话题,为应对与不同场景的跨端需求也会有很多不一样的跨端解决方案诞生。为支持各端的研发诉求,我们为跨端解决方案提供了多编译内核,并以此逐步拓展各编译内核的特性,为开发者的研发体验提速提供更多可能性,这也就是所谓多编译内核生态

多编译内核生态

不论是在各种前端工程化或是跨端解决方案中,Webpack 的出现频率高是毋庸置疑的,同样在 Taro 中也是如此,基于 Webpack 实现的编译内核,就能够为包括各类小程序在内的终端项目提供很好的研发体验,达成一整套开端解决方案来实现所谓「一套代码,多端运行」的能力特性。

Untitled

但实际上在跨端方案不断迭代的过程中,在个别端生态中可能遇到各种问题和瓶颈也逐渐凸显,比如说我们基于 React Native 实现的 App 端就是如此。

基于 Webpack 实现输出 RN 项目的能力,并借助于 Metro 完成 RN App 的打包和调试等等工作,会是十分便捷的方案,但在实际项目中却依旧会遇到诸如框架层面不能与 Metro 直接交互等等很多问题,维护起来也有诸多不便。

这也就是为什么我们需要在框架内提供 Metro 编译内核,来统一 RN 端的打包工具,为 React Native 生态提供更好的兼容性。

Untitled

相较于 Webpack,使用 Vite 编译项目在 Web 端会有很多优势,在社区内一直以来也有很高的呼声,不在少数的开发者希望能够在跨端解决方案中支持使用 Vite 编译项目。那么如果能够基于 Vite 实现与 Webpack 编译内核基本一致的能力,来完成多终端项目的编译工作,实际体验又会如何呢?

Untitled

正是由于许多诸如此类的因素存在,也让我们不断思考解决的方案,最终在面向多终端的研发场景中,继跨端、跨框架之后,有了新的目标——即支持多编译内核的研发生态。

面向多终端研发

在面向多终端研发的场景中,通过借助 WebpackViteMetro 这类编译工具,可以实现包括 WebApp小程序鸿蒙等多终端的研发场景,开发者也能根据项目按需选择,以期获得更佳的研发体验。

Untitled

尽管我们主动选择在编译环节使用多编译内核,但这样的架构却并不只有优势,同时还要不少问题亟待解决。

譬如需要通过提供一致的生命周期支持,抹平各个插件对支持不同编译内核时的差异;框架配置也不会由于编译内核切换,导致额外的学习成本……编译内核的切换能够在研发和生态等各层面都能平滑无感,这也是我们正努力去实现的。

Untitled

二、极速构建

多编译内核或许是一个很好的架构方案,能够支撑各研发场景的特性实现,并给开发者更多选择的自由,但作为跨端解决方案,却不能局限于此。在面向多终端的研发场景中,多编译内核的研发生态下,想要为开发者提供极致的,极速研发体验又该怎样去做呢?

以各个编译内核及其生态为出发点,在框架内为不同研发场景提供极速构建的能力,结合框架架构内的插件系统,最终能够基于多编译内核方案得到全新的架构。

Untitled

Webpack 编译内核

在这些编译工具中,相信大家对于 Wepback 都不陌生,将开发者的代码输入 Wepback 内核编译就能够得到 Web 或小程序等等终端应用。

Webpack 编译内核中,我们通过 combination 为多端编译提供项目配置处理,不同模块的加载规则等通用能力;小程序端还有插件处理小程序模块和原生模块加载等特性;web 端也需要插件根据打包模式来处理应用和页面入口等等。结合框架的插件机制,开发者也能介入编译流程中,为项目提供自定义拓展,满足个性化的需求。

Untitled

想要在 Webpack 内核中达成更好的构建体验,除了自定义插件还有更多方案可以选择,比如 Webpack5 的持久化缓存就是其中之一,考虑到编译安全相比于速度更为重要,该特性会默认关闭。当然在绝大多数情况下,持久化缓存都能够以较稳定的方式帮助开发者提升研发体验,如果当项目研发过程中受困于编译速度时这会是个不错的选择。

借助于 ESBuild 等不同工具,我们提供了各可配置模块供开发者选择,依照需求选择更适合项目的工具,依赖预编译也是为此设计的重要特性之一,通过提前编译依赖可以在实际项目中极大提升我们的研发效率,在社区内也广受好评。

依赖预编译,也就是 PreBundle 特性通过 ESBuild 扫描项目依赖并提前编译,借助于 Webpack 的模块联邦能力分别构建 HostRemote 应用,就能实现这一有意思的特性,帮助开发者提升多终端研发的编译体验。

Untitled

原理其实不复杂,但对应不同端实际执行的操作会有一定不同,在小程序端包括了以下几个步骤。

首先需要扫描项目内的依赖,通过 ESBuild 能够很好的识别项目内使用到的 JS 模块,但是也有不少细节需要注意并处理的,比如识别 Vuesetup 语法,避免误判导致遗漏需要预编译的模块;同时其它终端所需的依赖也需避免误判被编译,导入终端不支持的依赖等等。

得到项目所需的依赖后,再次通过 ESBuild 将其打包就能够得到项目所需的 Bundle,但在这里我们还需要需解析对应依赖的入口模式,同时借助于自定义的 SWC 插件优化代码编译能力,将基于 CJS 模式输出的依赖转换成 ESM 后的编译结果进行兼容。

想要在 ESBuild 输出结果中保留原始路径,将会使最终结果难以预测,所以我们需要将其扁平化处理,仅通过虚拟模块保留原始路径。最后对编译内容进行缓存,避免多次编译造成性能损耗。

紧接着,我们需要借助 Webpack 通过 MF 插件打包出 Remote 应用,在这个过程中同时需要传入编译所需的各种插件,比如说 ProviderPlugin 用于提供小程序依赖的运行时环境,并缓存编译结果。Host 应用必要的配置将会同时生成,并将 Host 应用及其资产注入到小程序目录,供最终的项目运行使用。

Untitled

与小程序端相比,Web 端有很多步骤非常相似,比如前置的依赖扫描与打包等等,尽管具体配置会存在一定差异,比如 Web 端用于 API Shaking 的自定义 Babel 插件就需要通过 SWC 插件重新实现避免基于 Taro 的组件库在 PreBundle 特性中无法得到支持。同时由于小程序和 Web 端本身的差异,后续的步骤中也会有较大差异,比如需要为 Remote 应用配置代理。

虽然 Web 端编译 Remote 应用与小程序一样,都需要通过 ContainerPlugin 创建额外的容器入口,但却并不需要借助 ProviderPlugin 注入 runtime 等等依赖,同时也无需将远程依赖修改为同步模式等等操作。

在配置 Host 应用插件时,需要通过 ContainerReferencePluginRemote 提供的所有依赖修改为远程模块,并通过特定的引用添加作为外部资源的容器,允许它们加载远程模块,同时为公共的运行时注入必须的 Webpack 工具函数。最后在使用前,我们还需要为 Remote 应用设置代理,供 Host 应用加载应用这些依赖。

实际上,当我们在 Host 应用中直接使用未经加载的 Remote 依赖时,会导致应用报错。在业内一些类似的方案中,往往会需要通过 Babel 修改引用依赖相关的代码逻辑,但实际上如果在应用入口嵌套一层动态加载,Webpack 就会预加载这些 Remote 依赖避免相关问题出现,这也是在官方 MF 示例中推荐的方法。而在该特性方案中,为支持包括外出使用、多页应用构建等特性,我们选择基于 virtual-module 实现这一操作,最大程度借助于 Webpack 自有的能力与生态。

在通过 NutUI 的示例项目测试编译预编译时,可以发现通过 PreBundle 特性能够得到不错的优化,在社区开发者的体验当中,我们也收到了类似的反馈,小程序编译速度约为使用前的 20%,Web 应用也将耗时降低至原方案的约 30%

Untitled

这样的性能提升结果让人十分满意,但在跨端环境下使用模块联邦能力,特别是在小程序环境中使用真的如此容易?受限于小程序本身,借助于网络请求来实现该特性会极大程度的降低小程序的使用体验,牺牲用户体验不应该是一个成熟框架应该做的。

模块联邦特性实际是基于 ModuleFederationPlugin 封装提供给开发者使用,如果我们基于它内置的两个插件实现逻辑调整能否优化这一实现呢?

Untitled

在这两个内置插件中,ContainerPlugin 在构建小程序端使用的 Remote 应用时,需要在插件内为小程序创建额外的容器入口,并提供模块自动注册相关的逻辑,通过劫持 ContainerEntryDependency 将依赖异步逻辑改为同步;与此同时还需要收集使用到的 Webpack 工具函数,并删除冗余的入口、runtime 等 chunk。

而在 ContainerReferencePlugin 中,需要将预编译依赖设置为远程模块,并注入收集到的 Webpack 工具函数,修改 remote 模块中的 id 映射对象,并插入自动注册模块相关的逻辑,在 app.js 中通过 require 依赖所有预编译生成的 chunkremoteEntry;同时需要删除冗余的文件,比如已经无用的远程模加载模块,减少不必要的代码输出。

通过基于提供 ContainerPluginContainerReferencePlugin 的魔改插件 TaroModuleFederationPlugin 供框架使用,就能在小程序中不损失用户体验的同时使用这一特性。开发者也可以自行配置使用,不过如果你的项目正在使用跨端框架,直接使用 PreBundle 特性会是个更好的选择。

Untitled

当然不论是 TaroModuleFederationPlugin 还是 PreBundle 特性,都可以在第三方的项目中配置使用,以 PreBundle 为例,通过 Chain 传入 Webpack 配置,并执行实例上的 run 方法,我们就能得到最终所需的 Webpack 项目配置文件,并启动项目。

目前也有不少外部项目都通过接入该特性,来获得更佳的研发体验。

Vite 编译内核

实现 Vite 编译内核,可以说是在追赶潮流,也是当下社区开发者们的呼声,但更多也是希望能够通过支持 Vite 编译提供更多元的研发场景,让开发者可以根据实际需求,自由选择项目在对应场景下所需的编译内核。

相较于传统的编译模式,启动项目时需优先扫描整个项目依赖和代码,才能在应用完成构建后提供服务;Vite 通过使用 ESBuild 构建依赖,并在浏览器请求源码时,将对应模块转换为原生 ESM 按需提供源码,研发速度要快很多。

Untitled

通过 Vite 我们可以给 Web 端提供更好的研发体验,当然还需要兼容各种小程序的特性,比如说路由、TabBar 等等,还有各类 API 和跨端组件库,也需要兼容性配置。

同样,在 Webpack 编译内核中已经支持的各种能力和特性也不能抛下,包括 ReactPreact 等前端 UI 框架的支持,多路由模式等等,也需要在 Vite 编译内核中得到支持。

相比于在 Web 端能够得到不小的提升,在适配小程序场景中的实际收益相对就要低上不少,由于缺少持久化缓存,在编译大型项目时的实际体验与 Webpack 相比并无明显改善,但是通过配置跳过更新的页面也能够给需要的项目提供不错的研发体验。

Untitled

同样由于小程序自身的限制,Vite 并不能以开发模式来完成小程序的编译,我们在生产模式下提供应用和各页面入口的编译,写入到对应的小程序目录中,并以虚拟模块的形式更新页面,配合适配小程序端的 Vite 插件就可以完成小程序端编译工作。

总结来说,在 Vite 编译核心内,我们通过为小程序和 Web 端提供 config、entry、style 插件来适配各端的能力,当然小程序还需要 page 插件来为页面提供额外的处理。结合框架自身的插件机制,我们就能让 Vite 在适配跨端解决方案的同时,与其它编译内核形成一个互补选项,供开发者使用。

Untitled

在整个编译系统中,除了我们提供的 Vite 编译内核,CLI 还有配置工具也需要为此同步做出调整,结合内核提供的代码和样式编译能力,就能为绝大多数的编译场景提供支持。同时一些工作我们也在社区内逐步去推进完成,比如小程序的分包能力,还有 Web 端的多路由应用模式等等,都会在之后的版本里一一补齐。

当然在使用 Vite 内核还是可能遇到一些问题,我们在后续也会尝试去针对性优化,比如打包输出成 CJS 模式,在配置 splitChunk 后可能会导致循环依赖,在小程序中报错;另一个就是刚刚有提到的编译缓存,在小程序中二次编译速度可能不及基于其它打包工具的编译内核。

Metro 编译内核

Webpack 输出 RN 项目,到改用 Metro 是一个很自然的选择,借助于 Metro 我们也能将适配 React Native 的很多操作,从编译时转向到运行时,为开发者提供更好的研发体验。

Untitled

从 CLI 读取项目配置,到 Metro 内核完成编译,并启动调试服务,Metro 都能比 Webpack 更好的兼容 React Native 已有的生态环境。在框架层面需要做的,仅是为开发者提供合并定义 Metro 配置的能力,并让 Metro 可以理解我们在适配其它端时对 Webpack 的操作,并在一定程度上复刻。

Untitled

基于 @tarojs/rn-transformer 处理 RN 的入口文件,在编译时注入页面的包装方法等,并将入口的全局样式注入到页面中;同时对运行时进行一定程度的修改,比如基 React Navigation 对路由进行封装,提供动态创建导航的方法,并且封装导航相应的 API 内容;在 runtime 中对应用和页面配置进行处理等等。

相比于过往方案,Metro 能够提升编译速度,提供更好的 SourceMap 支持,提升研发效率和体验;同时规避由于 Webpack 提供的多 entry 模式导致的问题,并降低包体大小等等;也与 React Native 默认配置保持一致,支持更灵活的合并方式。

在 App 端,我们通过 MetroTransformerRuntime 两个层面对项目进行修改,让方案可以在支持多端的同时,更加顺滑的支持使用 RN 完成 App 端的研发工作。

Untitled

那如果希望在框架之外,使用这些开发好的 RN 能力,也有比较简单的方法快速接入,通过 @tarojs/rn-supporter 就能提供编译、运行时配置,和资源样式解析方案的支持。

具体使用如下图代码所示,需要注意的是,在该外部使用的方案中,路由相关的逻辑需要自行处理。

Untitled

总结来说,在我们的编译系统方案中,通过 CLI 和插件系统结合多个编译内核来为开发者提供跨端解决方案。

在编译内核之外,插件系统也能够很好的帮助框架为开发者根据编译平台,提供解决方案。

Untitled

通过 CLI 完成编译工作时,我们也可以通过加载不同平台插件的方式,来完成编译时拓展和运行时能力的注入,提供最终的编译结果。

在插件系统中,我们从 CLI、编译过程和编译平台三个方向提供能力的拓展,结合各个生命周期,比如:onBuildStartonCompilerMakemodifyWebpackChain 等等,各个编译内核都能为不同端编译提供更加个性化的定制服务。借助于此,我们可以提供 ReactVueFlutter 等等不同 DSL 的插件;也能为小程序、鸿蒙等多端提供端平台插件,辅助完成编译。

在这样的架构下,开发者也能根据我们提供的生命周期,横向或纵向拓展编译能力,为各个终端拓展编译能力支持,比如说飞书、钉钉、企微等等小程序还有鸿蒙端平台插件,都是 Taro 技术委员会或者社区开发者通过这样的方式提供的。

Untitled

同时在其它方面,为提升构建体验也有不少小优化,比如 SWC 虽然与 Babel 实际上还存在差异,但在很多特殊的应用场景下已经足够使用,比如在依赖预编译中提供代码编译,以及应用与页面配置读取等等,都有不少提升。

ESBuild 也是如此,除了 PreBundle 特性中的使用,我们还在压缩代码和样式中提供了相关的配置,不过相比于 tersercsso,还存在压缩效果等问题,加之对其稳定性的考量,我们并没有将其配置为默认选项,可以由开发者自行选择。

三、总结与展望

跨端解决方案结合多编译内核生态,我们能够在开放式的跨端跨框架解决方案中,为开发者提供更高的自由度和研发体验。

通过 ReactVueSvelte 等 DSL 插件,结合 Web 端渲染规范,小程序的标准 API 和组件库等等,我们能够为不同终端提供可靠的跨端能力,同时在 WebpackViteMetro 等多个编译内核的帮助下,我们能够提供更加高效的研发体验,为日常的开发工作提供更多的便利。

Untitled

对于框架本身来说,在未来我们也会提供更多的前端 UI 框架或编译工具的支持,比如 Solid 等等。

性能方面,也希望为小程序提供更好的热重载、预渲染等能力,提升多端研发体验,提供适用于更多场景的多端性能优化方案。

同时根据场景提示性能优化方案,以及性能指标测评工具,为项目优化提供指引。

Untitled

对于 Flutter 编译内核的支持也在日程中,在社区内持续推进;通过 Web Assembly 对小程序的运行时进行优化等等,也都在 Taro 未来的路线规划当中,敬请期待。

同时,我们还预期提供框架的测试方案,通过 TestRenderer 为跨端方案的测试提供更好的体验。

Untitled

最后关于 Taro 开源工作,目前已经由 Taro 技术委员会主导,在 Taro 生态超过 700 位贡献者中,有 50 余位行业内各个公司的同学长期参与 Taro TOC 的会议分享,所有贡献者们都为推进 Taro 跨端解决方案不断迭代作出了诸多努力和贡献,正因如此才能够让我们在多编译内核生态下,获得更加极致的研发体验。

正如技术委员会成员 @xueshuai 在投稿 v3.6 版本代号时说道,“「Reach」代表着不屈和希望,给开发者带来更好的用户体验,是全体开发者的坚守“,希望社区的积极氛围可以引导 Taro 的生态更加美好。

标签:

· 阅读需 24 分钟
Flame
大喵
robin
SHUAI XUE
zhiqingchen
JJ
TJ

两个月前,我们发布了 Taro v3.6 的 canary 版本,在技术委员会和社区范围内提供跨端路由库、跨框架组件等主要能力和重要修复的测试,并发起社区投票正式确定了当前版本的代号 —— Reach。

taro-3.6.jpg

日前 Taro v3.6 正式版本已经发布,下文将围绕 3.6 版本内的跨端、平台能力支持等多个方面展开,快速了解在 v3.6 中各个重要特性。

一、跨端能力支持

支持各类跨端能力,抹平多端研发之间的体验差异,是 Taro 一直以来尝试去实现的,基于 Taro 3 适配多端前端 UI 框架的逻辑,通过在小程序端模拟实现框架所需的 BOM / DOM API 就能达成对于各类跨端能力的适配。

1. 支持路由库

在 Web BOM 中,History & Location 对象是重要组成部分,它们是实现前端路由的关键。Taro 为支持前端路由库的使用,在运行时中引入了 histroy location 对象的实现,同时尽可能与 Web 端规范对齐。通过在 window 对象上访问到 historylocation 对象,并支持监听 hashchangepopstate 事件,为跨端使用路由库提供基础。

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

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

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

至此,可以在小程序中使用成熟的前端路由库了,包括 react-routervue-router。在路由库中,诸如 <Link> 组件内部会动态生成 <a> 标签,因此需要引入 @tarojs/plugin-html 插件以支持在 Taro 中使用 html 标签开发组件。

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

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

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

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

2. 支持网络请求库

与适配各路由库类似,通过对运行时补充就能支持绝大多数的网络请求库,所有请求库在底层都是通过使用 XMLHttpRequestFetch 提供能力支持的,而请求库大多都兼容 XMLHttpRequest 对象,也即是在提供 XMLHttpRequest 对象实现的基础上,就能支持绝大多数的第三方库。

支持这些成熟的网络请求库(例如 axios 等)就能为开发者在跨端研发场景下,提供更好的研发体验。通过引入 @tarojs/plugin-http 插件,为小程序环境提供网络请求库所需的运行时环境支持。

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

注意:当前 @tarojs/runtime 在小程序环境中缺少BlobFormDataFile对象,这在网络请求库的文件上传特性中是必须的,故暂不支持。

在支持网络请求库的同时,考虑到部分用户,特别是 web 转小程序的项目中依赖 cookie 实现鉴权,@tarojs/plugin-http 插件模拟实现了 document.cookie api 以及通过 http 响应头 Set-Cookie 来设置客户端 cookie 值 ,行为和 web 中保持一致。 此功能默认设置为关闭,需要的可通过 enableCookie 配置开启。

参数名类型默认值说明
enableCookieBooleanfalse支持 document.cookie 、 通过后端返回 Set-Cookie 响应头来设置 cookie
disabledFormDataBooleantrue是否禁用 FormData 全局对象
disabledBlobBooleantrue是否禁用 Blob 全局对象

在 @tarojs/plugin-http 插件中,以 axios 作为基准库完成测试,如果在使用其他请求库时遇到适配问题,可在社区或通过 issues 反馈相关信息。

二、平台能力支持

拓展更多端平台,适配支持各端能力与特性,是跨端解决方案不断发展的重要组成部分之一。

1. 支持鸿蒙端平台插件

在 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 编译内核也能够为鸿蒙项目编译提供支持,终于我们在 v3.6 中再次为社区开发者提供了适配鸿蒙的端平台插件。

// config/index.js

config = {
// 配置使用插件
plugins: ['@tarojs/plugin-platform-harmony'],
// harmony 相关配置
harmony: {
// 【必填】鸿蒙应用的绝对路径
projectPath: path.resolve(process.cwd(), '../MyApplication'),
// 【可选】HAP 的名称,默认为 'entry'
hapName: 'entry',
// 【可选】JS FA 的名称,默认为 'default'
jsFAName: 'default'
}
}

具体使用方法可查看官方文档,需要注意鸿蒙插件不在 Taro 项目内维护,所以并不会每次发布同版本号版本,直接使用 minor 与 Taro 版本号相同的版本即可。

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

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

2. React Native 能力

为了让整体开发体验跟 RN 更加一致,减少开发者的理解成本。我们对 @tarojs/rn-runner 的代码进行了重构。将 Taro RN 需要的所有编译逻辑,都封装到了 metro 配置中,与 RN 项目集成会更加灵活。

新版本在项目根目录下会创建入口文件 index.js 和配置文件 metro.config.js。如项目本身有这两个文件,则不会生成,需要参考模板进行添加或合并。另外 Taro RN 的相关配置,集中在 resolver 和 transformer 中,可根据相关源码自行覆盖调整。

React Native 0.70 版本已于 2022-9-5 正式发布,在 0.70 版本中 Hermes 已成为默认的 JS 引擎,

v3.6 版本将与 RN 默认配置保持一致,如不需要可自行关闭。Hermes 也带来了 RN 性能的较大提升,特别是启动场景,详细内容参考官方文章

Hermes

Taro 将与 RN 社区保持同步,将默认的 RN 版本设置为 0.70。相关依赖也已同步至最新版本,仍然可使用 yarn upgradePeerdeps 进行更新。@react-native-community/clipboard@react-native-community/cameraroll 已被弃用,旧版本升级后需要删除。

注意:升级后将不再支持 iOS 12,详细内容请参考 discussions。同时 Taro Playground 作为 RN 端的调试工具及跨端 Demo 同步更新至 v3.6。

3. Web 端能力

通过在社区中收集的相关问题反馈,Taro Web 各类特性也一直在不断推进,让开发者在多端研发的体验能够尽可能达成一致。面对各类自定义 Web 端能力的需求,虽然有很多方案可以提供组件、API 等能力的补充,但类似小程序端平台插件这样的能力在 Web 端中并没有得到支持。

在 3.6 版本中,我们将 Web 端各类定制化的能力从 runner 中转移到 @tarojs/plugin-platform-h5 插件中提供,譬如通过配置 useHtmlComponents 模式替换使用的组件库;注册 Web Components 组件库,配置各前端 UI 框架组件适配器;移除不必要的 API 等等特性。

class H5 extends TaroPlatformWeb {
// ...
}

export default (ctx) => {
ctx.registerPlatform({
name: 'h5',
useConfigName: 'h5',
async fn({ config }) {
const program = new H5(ctx, config)
await program.start()
},
})
}

和小程序端一样,借助于插件或 TaroPlatformWeb 基类,开发者可以很容易横向或纵向拓展 Web 端的各项能力,详情可参考文档

Web 端也一直在补充各类开发者常用的组件与 API 抹平与小程序端的差异。在 v3.6 版本中新增生命周期、WXML 相关的 API 支持若干,例如:createIntersectionObservercreateMediaQueryObserver 等,同时新增 movable-areamovable-view 等组件支持。

在社区开发者交流时,我们也发现了部分研发场景下需要监听各 API、组件不支持事件,相比于支持 canIUse 方法在跨端转换场景中能够更有效定位问题,所以通过支持 __taroNotSupport 事件满足相关需求,可以参考以下示例使用。

interface IOption {
name: string // 不支持的组件或 API 名称
type: 'method' | 'component' // 'method': API; 'component': 组件
category: 'permanently' | 'temporarily' | 'weixin_corp' // 'weixin_corp': 仅在微信公众号 JS-SDK 环境下支持
args?: any[] // API 传入参数
instance?: unknown // 组件实例
}
Taro.eventCenter.on('__taroNotSupport', (option: IOption) => {
console.warn('调用不支持的 API 或组件', option)
})

三、跨框架组件库

借助于 stencil,Taro 3 得以通过 Web Components 实现一套跨框架组件库,通过适配器将 Taro 的组件库提供给各个前端 UI 框架使用,开发者也可以基于这些封装上层组件,提供更多有趣的能力。

1. Web 端适配器

出于降低开发者维护门槛,与 stencil 组件库打包流程更好兼容等多方面考虑,在 3.6 版本中我们在升级 stencil 依赖版本的同时,通过官方提供的  ds-output-target 工具替换了原有的自定义适配器。

该版本适配器更好的抹平各个框架组件使用差异,补齐过往版本迭代过程中部分特性兼容性的缺失问题,为开发者提供更好的体验。在 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 3 开始支持的上层组件,虚拟列表应当是很多开发者都熟悉的特性,在过往版本中也有过数次升级,支持包括 unlimitedSize、relative 定位模式等特性,在 v3.6 版本中我们再次对虚拟列表做出了调整,将其从 @tarojs/components 包中抽离到 @tarojs/components-advanced 中维护(4.x 版本之前开发者依旧可以通过 @tarojs/components/virtual-list 引用虚拟列表组件),也欢迎大家一同参与上层组件库的维护与共建,沉淀更多跨端可用的能力。

https://img20.360buyimg.com/ling/jfs/t1/125645/6/13305/50138/5f6aaaa4E2f20eba7/d70a2d2da2d68de1.jpg

在新版本中,虚拟列表支持在选择 preact、vue3 框架构建的项目中使用,同时在使用各个前端 UI 框架的项目中都支持使用选择 absolute********relative ********不同定位方式,unlimitedSize 模式与传入 itemSize 函数等特性也得到支持。

以 Vue 为例,我们需要在入口文件声明使用:

// app.js 入口文件
import Vue from 'vue'
import registerVirtualList from '@tarojs/components-advanced/dist/components/virtual-list'
// Note: 使用以下路径导出插件可以在 vue 中获得更好的类型支持
// import registerVirtualList from '@tarojs/components-advanced/dist/components/virtual-list/vue'

Vue.use(registerVirtualList)

一个最简单的长列表组件会像这样,virtual-list  的 5 个属性都是必填项:

<! –– row.vue 单项组件 ––>
<template>
<view :id="id" :class="index % 2 ? 'ListItemOdd' : 'ListItemEven'"> Row {{ index }} : {{ data[index] }} </view>
</template>

<script>
export default {
props: ['id', 'index', 'data'],
}
</script>

<! –– page.vue 页面组件 ––>
<template>
<virtual-list
wclass="List"
:height="500"
:item-data="list"
:item-count="list.length"
:item-size="100"
:item="Row"
width="100%"
>
<! –– Vue 中支持列表首尾使用的插槽,对应 React 中的 renderTop、renderBottom 参数 ––>
<template v-slot:top>
<view>top</view>
</template>
<template v-slot:bottom>
<view>bottom</view>
</template>
</virtual-list>
</template>

<script>
import { markRaw } from 'vue'
import Row from './row.vue'

function buildData(offset = 0) {
return Array(100)
.fill(0)
.map((_, i) => i + offset)
}

export default {
data() {
return {
Row: markRaw(Row),
list: buildData(0),
}
},
}
</script>

需要注意的是,为抹平多框架参数差异便于维护,旧版本中部分命名会统一修改,比如在 React 版本中通过 children 传入的子节点组件改为 item;Vue 中的 wclass、wstyle 这类写法也不再支持。

在新版本中,根据需求和研发场景合理设置 itemSizeoverscanCountplaceholderCount 等参数优化长列表,可以获得比旧版本更加顺滑的体验,更多详情可以参考官方文档

四、研发生态

1. 小程序持续集成 CI

去年 Taro 提供小程序持续集成插件 @tarojs/plugin-mini-ci ,帮助开发者提供更好的研发体验,经过一年的项目沉淀和反馈,在本次版本重构了去年的所有代码,并提供了更优秀体验和灵活的配置。

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

以下为当前各平台支持的功能情况表:

平台/功能自动打开 IDE输出预览二维码输出体验二维码
weapp
qywx
alipay
dd
swan
jd

ps: 该插件在 taro3.6.0 版本以下亦可支持单独使用,插件版本号无需保持与其他包同步。

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

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 为相关工作做出的贡献,希望开发者可以因此获得更好的研发体验。

3. 类型与文档自动同步

快速同步各平台支持的类型,一直以来都是十分头疼的问题之一,想要实时跟进各个平台以提升用户体验十分困难,更多时候我们都通过开发者提交的 PR 或 issue 对这些平台的类型更新维护。如果能够根据各个小程序平台官方提供的文档自动化生成类型,这对于框架维护和开发者来说会是一个很棒的体验。

CanIUse

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

希望后续也能够通过和各平台合作的方式优化该能力,为开发者提供更好的体验。在这里特别感谢 @rebinv8 为组件类型自动化脚本做出的贡献~

4. Taro Playground 同步升级

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

五、升级指南

1. 创建 v3.6 版本项目:

# 安装 v3.6.0 的 CLI 工具
npm i -g @tarojs/cli@latest
# 创建项目
taro init taro_project

# 也可以跳过安装 CLI 工具使用 npx 创建项目
npx @tarojs/cli@latest init taro_project

2. 已有项目升级到最新版本:

  1. 将 package.json 文件中 Taro 相关依赖修改为 3.6.0 版本;
  2. Taro v3.6 将 web 端插件化,需要新增依赖 @tarojs/plugin-platform-h5,同时 @tarojs/router@tarojs/taro-h5 不再需要额外声明依赖,可自行移除;
  3. 重新安装依赖,如果安装失败或打开项目失败,可以删除 node_modulesyarn.lockpackage-lock.json 后重新安装依赖重新尝试。

最后

自 Taro 引入技术委员会等机制后,与社区互动愈加频繁,Taro 也得益于诸多贡献者的帮助有能力去实现更多有意思的特性,给开发者带来更好的用户体验,这也是 Taro v3.6 在代号「Reach」中的期待。感谢各位参与到 Taro 开源生态共建的同学们,所有的努力都让 Taro 的生态更加美好,为建立更加完善、更加可持续的 Taro 开源生态,贡献力量!

标签:

· 阅读需 19 分钟
Flame
大喵
robin
SHUAI XUE
zhiqingchen
JJ
TJ

近期我们确定了 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 对象上访问到 historylocation 对象。同时,也支持监听 hashchangepopstate 事件,这为使用路由库提供技术基础。

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

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

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

2. 使用路由库

至此,可以在小程序中使用成熟的前端路由库了,包括 react-routervue-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 中再次为社区开发者提供了适配鸿蒙的端平台插件。

使用方法

  1. 在项目中安装鸿蒙端平台插件

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

    需要注意鸿蒙插件不在 Taro 项目内维护,所以并不会每次发布同版本号版本,直接使用 minor 与 Taro 版本号相同的版本即可。

  2. 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',
    },
    }
  3. 准备鸿蒙运行环境

    开发鸿蒙软件需要用到 HUAWEI DevEco Studio,它提供了模板创建、开发、编译、调试、发布等服务。

    鸿蒙运行环境主要包括以下内容

    (1) 注册开发者账号

    (2)下载 DevEco Studio 安装包

    (3)启动 DevEco Studio,根据工具引导下载 HarmonyOS SDK

    (4)新建 MyApplication JS 项目

    (5)使用预览器或真机查看应用效果

    参考资料:《初窥鸿蒙》、《华为开发者工具》、《鸿蒙开发文档

  4. 项目运行

    Taro 编译鸿蒙项目命令

    $ taro build —-type harmony —-watch

    taro-harmony-example

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

  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 开源生态,贡献力量!

标签:

· 阅读需 13 分钟
zhiqingchen
Cong-Cong Pan
Flame
JJ
TJ

距离 Taro 3.5 的 Beta 版本发布已有两个月的时间,期间我们在不断地对基于 Webpack5 的编译系统、基于 Next.js 的 SSR 等功能进行打磨的同时,新增了对 pnpm 的支持等新功能。此外 Taro 社区也有很多同学参与共建,如 Taro 合作者 @biorz 为 ReactNative 侧贡献了重要特性:支持把 Taro 组件编译为 RN 组件。

日前 Taro v3.5 已正式发布,下文将介绍关于 3.5 的主要特性与重要修复,以及后续的版本规划。

一、编译提速

Taro v3.5 基于 Webpack5 构建了新的编译系统,利用持久化缓存、依赖预编译、SWC 等方法与工具,大幅降低了编译所需耗时。开发者可以自由选择切换使用 Webpack5 进行编译,也可以继续保持使用 Webpack4,另外在 v3.6 中 Taro 还将支持使用 Vite 进行编译。

依赖预编译可以预先把项目的第三方依赖打包为一个模块联邦 remote 应用,再次编译时 Webpack 无需再对这些依赖进行编译,从而提升编译速度。关于 Webpack5 编译系统的实现细节,请浏览 《Taro v3.5 beta 编译提速》

v3.5 Beta 发布后,我们补全了 H5 端的依赖预编译功能,并且把依赖预编译作为一个通用能力提取了出来。可供 Taro 以外的使用 Webpack5 的 H5 项目使用,通过 @tarojs/webpack5-prebundle 进行编译提速,具体使用方法可参考相关文档

提速效果

NutUI 组件示例库 为例,小程序、H5 端的编译速度测试结果如下:

小程序:

GroupBar-20220725.jpeg

H5:

GroupBar-20220725 (1).jpeg

使用方法

简单修改 Taro 的编译配置即可切换使用 Webpack4 或 Webpack5 进行编译:

/** config/index.js */
const config = {
// 自定义编译工具,可选 'Webpack4' 或 'Webpack5'
compiler: 'webpack4' || 'webpack5',
}

二、RN

1. React Native 0.68 版本支持

React Native 0.68 版本已于 2022-3-30 正式发布。0.68 是首个可选接入 New Architecture 的版本,新架构有望为 RN 带来性能和体验上的飞跃。Taro 默认选择的 RN 版本,正式切换到了 0.68,开发者通过 taro init 选择 react-native 模板即可。

另外 0.69 版本的适配,也在进展中。

2. RN 相关依赖库由 unimodules 升级至 expo

Expo 是 React Native 生态中的重要角色,提供了非常多优秀的模块,在 Taro 中有较为广泛的使用,如 expo-av、expo-camera 等,将来我们还会持续接入新的模块。Expo 的模块系统,由 unimodules 变更为 expo 已有一段时日,其架构变更原因可参考文章: What’s new in Expo modules infrastructure

Taro v3.5 及以后将使用新的模块系统,后续壳工程不再包含 unimodules 版本。旧版本升级可参考此 PR,升级过程较为繁琐,建议重新 init 一个仓库,再将业务改动同步。升级为 expo 后,不再支持 iOS 11,详细内容请参考 discussions

3. 支持把 Taro 组件编译为 React Native 组件

如果您想在现存的 React Native 项目中(非 Taro RN ),复用您的 Taro 组件,那么这个新功能或许适合您。

您可以使用以下命令编译组件,编译后的组件产物可以直接在 React Native 项目中使用。 详细内容请参考 discussions

taro build native-components --type rn

4. 编译打包方案优化

Android 的打包过程,从调用 gradlew 改为使用  fastlane,将打包过程配置化,尽可能地减少对 RN 初始化后原生代码的入侵。相关配置位于  android/fastlane,目前仅做了基础配置,开发者可进一步自定义。

刚接触 Taro 开发 APP 的开发者,经常在开发环境的配置上,消耗大量时间。再次建议大家先学习利用 GitHub Action 进行打包编译,相关代码位于 .github 目录中。

5. 调试工具 Taro Playground 升级至 Taro 3.5 版本及 React Native 0.68

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

6. 壳工程代码整理

对于 0.68 版本的壳工程,我们进行了代码的重新整理。将初始化 RN、安装 expo、兼容 Taro、安装依赖、添加 Github Action,每一个步骤一一列出,方便开发者在定制壳工程时进行参考。

三、pnpm

众所周知,pnpm 在当下被誉为“最先进的包管理工具”,它是由 npm/yarn 衍生而来,解决了 npm/yarn 内部潜在的 bug,极大的优化了性能,扩展了使用场景。在社区内很高的呼声下,Taro 也在提供了这一热门的包管理工具选项。

在 Taro v3.5 版本以后,在脚手架内置包管理工具不再自动识别本地环境内安装的包管理工具,而是需要开发者自行选择需要的包管理工具,供开发者更方便使用和操作。

? 请选择包管理工具 (Use arrow keys)
yarn
pnpm
npm
cnpm

如果是在较旧的 Taro 项目中,想使用 pnpm 管理工具,由于幽灵依赖的存在,开发者需要在项目中手动安装并升级依赖来修复该问题,具体操作可参考文中升级指南第 5 项。

四、其它特性

除了以上新特性外,v3.5 还包括很多重要的更新:

1. 适配 React 18

从 Taro v3.5 开始,Taro 将默认使用 React 18 版本。你可以在 Taro 使用 React18 中激动人心的新特性了。从新建项目开始探索吧:

# @tarojs/cli 升级到 v3.5
$ taro init myProject
# 选择「react」框架

需要注意的是,受小程序环境限制,诸如新 Suspense 特性将不能在小程序中使用,详情请浏览文档

2. H5 支持服务端渲染

通过 tarojs-plugin-platform-nextjs 插件配置,我们可以将 Taro 和 nextjs 社区生态打通,让 Taro H5 支持 Pre-rendering(预渲染)、SSR(服务端渲染)和 ISR(增量静态生成)各种特性,提升页面首屏渲染速度 🚀,也利于 SEO 优化 🔍。

npm install tarojs-plugin-platform-nextjs next

在 Taro 项目的  config/index.js 中添加插件。

const config = {
plugins: ['tarojs-plugin-platform-nextjs'],
}

启动项目。

npx taro build --type nextjs --watch

插件来自社区大佬 @SyMind 贡献,详细用法可以参考插件文档

3. H5 支持多页应用模式

H5 端的多页应用模式是社区呼声最高的若干特性之一,在新版本中将得到支持,详细用法及注意事项请参考文档

配置开启多页应用模式:

/** config/index.js */
const config = {
h5: {
router: {
mode: 'multi',
},
},
}

4. 补全对小程序生命周期方法的支持

过去 Taro 对于小程序常用的生命周期方法支持得不够完整,新版本中将补全对应的方法与钩子。

新增 App 生命周期:

  • onError(React & Vue3)

新增钩子:

  • useLaunch(React)
  • useError(React)
  • usePageNotFound(React)
  • useLoad(React & Vue3)
  • useUnload(React & Vue3)
  • useSaveExitState(React & Vue3)

5. 小程序内部实现优化

对小程序的内部实现进行优化,减少约 50k 包体积,同时降低内存占用,减少 setData 发送的数据量。

五、升级指南

1. 升级 Taro CLI

升级全局的 Taro CLI:

npm i -g @tarojs/cli

或升级本地的 Taro CLI 工具:

npm i @tarojs/cli

2. 更新项目依赖

如果依赖安装失败或安装成功却运行报错,可以尝试删除 node_modules、yarn.lock、package-lock.json、pnpm-lock.yaml 后重新安装依赖。

2.1 更新项目内的 Taro 相关依赖

package.json 中 Taro 相关依赖的版本修改为 3.5.0 后重新安装依赖。

2.2 使用 React 的项目

  • 【Breaking】使用 React 的项目需要额外安装 @pmmmwh/react-refresh-webpack-pluginreact-refresh
npm i @pmmmwh/react-refresh-webpack-plugin react-refresh --save-dev

2.3 使用 Preact 的项目

  • 【Breaking】使用 Preact 的项目需要额外安装 @prefresh/webpack@prefresh/babel-plugin
npm i @prefresh/webpack @prefresh/babel-plugin --save-dev

2.4 使用 Vue2 的项目

  • 【Breaking】使用 Vue2 的项目需要额外安装 @vue/babel-preset-jsx
npm i @vue/babel-preset-jsx --save-dev

2.5 使用 Vue3 的项目

  • 【Breaking】使用 Vue3 的项目需要额外安装 @vue/babel-plugin-jsx
npm i @vue/babel-plugin-jsx --save-dev

3. 使用 Webpack5

开发者需要先卸载 @tarojs/mini-runner@tarojs/webpack-runner

npm uninstall @tarojs/mini-runner @tarojs/webpack-runner

然后安装 @tarojs/webpack5-runner

npm install @tarojs/webpack5-runner

最后修改 Taro 编译配置即可:

/** config/index.js */
const config = {
compiler: 'webpack5',
}

4. 使用 React 18

需要更新 reactreact-dom@types/react 的版本:

npm i react react-dom
npm i @types/react --save-dev

5. 使用 pnpm

因为 pnpm 不允许幽灵依赖的存在,因此开发者需要在项目中手动安装下列依赖:

dependencies 补充依赖:

"@tarojs/helper": "3.5.0",
"@tarojs/plugin-platform-weapp": "3.5.0",
"@tarojs/plugin-platform-alipay": "3.5.0",
"@tarojs/plugin-platform-tt": "3.5.0",
"@tarojs/plugin-platform-swan": "3.5.0",
"@tarojs/plugin-platform-jd": "3.5.0",
"@tarojs/plugin-platform-qq": "3.5.0",
"@tarojs/router": "3.5.0",
"@tarojs/shared": "3.5.0",
"@tarojs/taro-h5": "3.5.0",

devDependencies 补充依赖:

安装项目对应的 Webpack 版本,如 Webpack5:

"webpack": "^5.73.0"

六、最后

下半年 Taro 团队的核心将围绕以下各方向展开:

  • 支持使用 Vite 进行编译(预计 Q3 推出 alpha 版本)
  • 小程序方面将持续对性能进行优化、支持更多的 React/Vue 特性(如 Portal)和生态库(如 React/Vue Router)。
  • H5 方面将输出适配 Vue3 的 SSR 方案。
  • RN 方面将深入探索高阶功能,如地图、动画、2D 及 3D 图形方案,并推出跨端可视化库,提升 Taro 跨端能力。
  • 此外还会探索对于 Flutter 的适配。

最后的最后,衷心感谢参与社区共建与交流的各位同学!上半年我们制定了开发者贡献制度,建立起规范的项目分工与有效的荣誉激励机制。未来 Taro 将积极探寻更中立与开放的开源治理机制,欢迎各位开发者参与到 Taro 社区的建设中~

标签:

· 阅读需 12 分钟
zhiqingchen
Cong-Cong Pan
Flame
JJ
TJ

编译速度一直是困扰开发者的头等问题,现阶段大型 Taro 项目即使在增加了 cache-loaderthread-loader 等优化手段后,编译耗时仍高居不下。因此在 v3.5 版本中 Taro 重点对编译系统进行了重构,引入对 Webpack5 的支持,改善小程序 & H5 编译时的性能与体验。(除此之外,Taro 也正在落地对于 Vite 的支持,届时开发者将可以自由地选择编译工具。)

同时,Taro v3.5 还带来了兼容 React 18、H5 MPA 等新特性,欢迎各位同学升级试用~

一、编译提速

为了改善编译性能,Taro 主要做了以下事情:

  • 支持 Webpack5
  • 基于模块联邦的依赖预编译
  • 支持使用 esbuild 压缩 JS,使用 esbuild@parcel/css 压缩 CSS
  • 使用 @swc/register 代替 @babel/register

接下来将简单聊聊 Webpack5 与依赖预编译,关于编译提速的完整实现细节请参阅 RFC 文档

1. Webpack5

Webpack5 发布已有两年时间,功能足够稳定,同时其持久化缓存、模块联邦、更优的 Tree Shaking 等特性都为项目的编译流程提供了更好的解决方案。

其中的持久化缓存功能是最重要的特性之一,能极大提升再次编译时的速度。但同时也引入了如何使缓存失效的问题。

Taro 遵循 Webpack “编译安全比编译速度重要” 的理念,默认不开启持久化缓存。当开发者设计好缓存策略后,强烈建议开启持久化缓存。详细配置请参考 mini.cache

2. 依赖预编译

Webpack5 另一个重要的特性要数模块联邦(Module Federation)。受 UmiJS mfsu 特性的启发,可以预先把项目的 node_modules 依赖打包为一个模块联邦 remote 应用,再次编译时 Webpack 则无需再对依赖进行编译,从而提升编译速度。

依赖预编译可以分为三步:

  1. 收集依赖
  2. 打包依赖
  3. 打包 Module Federation Remote 应用

Taro 参考 Vite 使用了 esbuild 收集用户使用到的第三方依赖,并分别进行打包。打包后的模块会作为 Webpack 的 entry,最终打包为模块联邦 Remote 应用,供主应用(Host)消费。实现细节请参考 RFC 文档

Taro 会在小程序环境的 dev 模式下默认开启依赖预编译功能。首次编译时,因为使用了 esbuild 打包第三方依赖,所以会比普通编译稍快。二次编译时,Taro 能直接复用 Remote App,Webpack 只需编译业务代码,因此根据不同项目会有不同的编译提速效果。

依赖预编译的流程图:

https://storage.360buyimg.com/cjj-pub-images/prebundle.png

3. 提速效果

NutUI 组件示例库为例,分别测试 dev 与 prod 环境下编译微信小程序的编译提速效果:

https://storage.jd.com/cjj-pub-images/compile-speed_dev.png

https://storage.jd.com/cjj-pub-images/compile-speed_prod.png

可以看出:

  1. 在 dev 环境下因为 Taro 默认开启了依赖预编译,因此 Webpack5 首次编译速度比 Webpack4 稍快。而 prod 环境没有默认开启依赖预编译,因此两者速度相当(而且 Webpack5 需要写入缓存,可能会比 Webpack4 稍慢)。
  2. 无论是 dev 还是 prod 环境,在完全命中缓存的最优情况下,Webpack5 的编译速度都能得到极大提升。即使是修改源码导致了部分缓存失效时,编译速度仍然比首次编译快得多。

4. 使用

旧项目升级后需要安装 Webpack5 的相关依赖才能正常编译,详情请参考下文的【升级指南】部分。

简单修改 Taro 的编译配置即可开启 Webpack5、持久化缓存、依赖预编译等功能:

/** config/index.js */
const config = {
// 自定义编译工具,可选 'Webpack4' 或 'Webpack5'
compiler: {
type: 'webpack5',
// 依赖预编译配置
prebundle: {
enable: true,
},
},
// 持久化缓存配置
cache: {
enable: true,
},
}

二、兼容 React18

React 官方正式发布了 react v18 版本,带来了 Automatic Batching、Transitions 和 Concurrent 等诸多新特性,提升了 React 性能。Taro 也在第一时间完成了对 React18 的兼容。

React 目前存在两种工作模式:legacyconcurrent 。在 concurrent 模式下,会使用 New Client API 来渲染组件。

不要忘记将项目的 react 版本升级到 v18 哦

详细内容请参考 React 18

三、支持服务端渲染(SSR)

1. 动机

与 SPA(单页应用程序,Single-Page Application)相比,服务器端渲染(SSR)能带来带来更快的首屏渲染速度更好的 SEO,因此 SSR 功能是大家期望 Taro 支持的特性之一。

2. 实现原理

Taro 在 3.1 版本提出了开放式架构的思想,让开发者可以通过编写插件来让 Taro 支持一个新的平台。

通过 Taro 插件,将 React 生态中知名的 Next.js 框架作为 Taro 的一个新的目标平台,以此让 Taro 能够支持服务端渲染(SSR)。

目前这个插件项目的地址位于:SyMind/tarojs-plugin-platform-nextjs

⚠️  插件目前处于早期建设中,不建议用于生产环境!

3. 安装与使用

安装插件和 Next.js 框架。

# 使用 npm 安装插件与 next.js
npm install tarojs-plugin-platform-nextjs next

# 使用 pnpm 安装插件与 next.js
pnpm install tarojs-plugin-platform-nextjs next

在 Taro 项目的编译配置中添加本插件。

const config = {
plugins: [
'tarojs-plugin-platform-nextjs'
]
}

开始尝试它吧!

npx taro build --type nextjs --watch

四、支持多页应用(MPA)

很多同学通过阅读 Taro 的源码发现,Taro 曾在 1.x 支持过多页面应用,通过配置 multi 模式就可以开启该特性,但是由于并没有很好支持,也没有相应的业务场景测试,最终并没有在文档中呈现。

在 2.x 发布时,由于各种原因我们回滚了该特性,尽管开发者们依旧可以通过插件或者在项目内自定义 webpack 配置实现类似的需求,不过这依旧会在一些细节上难以处理得尽善尽美。比如需要额外配置文件拆分规则避免冗余的代码,对于 MPA 也并不需要taro-router提供对于路由相关的事件方法的支持……

MPA 是不少社区开发者所追求的重要特性之一,为此我们改写了 taro-loadertaro-router 以适应该模式的个性化需求,应用该模式也只需要如下配置:

module.exports = {
// ...
h5: {
// ...
router: {
mode: 'multi',
},
},
}

需要注意的是,有很多小程序事件和方法都是基于 SPA 模式设计使用的,在 MPA 模式并不适用,所以会存在一些问题,比如由于多页面导致 TabBar 会重复加载,App 级的生命周期会重复触发,不支持路由动画,生产环也需要额外配置路由映射等等,开启该模式前需要认真考量适用场景。

五、RN 相关依赖库由 unimodules 升级至 expo

Expo 是 React Native 生态中的重要角色,提供了非常多优秀的模块,在 Taro 中有较为广泛的使用,如 expo-av、expo-camera 等,将来我们还会持续接入新的模块。Expo 的模块系统,由 unimodules 变更为 expo 已有一段时日,其架构变更原因可参考文章: What’s new in Expo modules infrastructure

Taro v3.5 及以后将使用新的模块系统,可以通过 taro init 选择 react-native 模板体验。如果你使用的是 Taro 壳工程,可切换到 0.67.0-expo 分支体验。

新老版本的 Taro 及壳工程之间混用的话,将存在不兼容情况,主要原因是存在多个版本原生依赖导致,可通过 resolution 进行版本锁定解决,相应版本参考此处

后续壳的工程将不再包含 unimodules 版本。旧版本升级可参考此PR

注意:升级为 expo 将不再支持 iOS 11,详细内容请参考 discussions

六、升级指南

1. 安装 v3.5.0-beta 的 CLI 工具:

npm i -g @tarojs/cli@beta

2. 更新项目依赖

如果安装失败或打开项目失败,可以删除 node_modules、yarn.lock、package-lock.json 后重新安装依赖再尝试。

2.1 把 package.json 文件中 Taro 相关依赖的版本修改为 3.5.0@beta

2.2 Breakings

  • Vue2 项目需要添加 devDenpendencies:"@vue/babel-preset-jsx": "^1.2.4”

  • Vue3 项目需要添加 devDenpendencies:"@vue/babel-plugin-jsx": "^1.0.6"

  • React 项目需要添加 devDenpendencies:

    "@pmmmwh/react-refresh-webpack-plugin": "0.5.4",
    "react-refresh": "0.11.0"
  • Preact 项目需要添加 devDenpendencies:

    ```jsx
    "@prefresh/webpack": "^3.2.3",
    "@prefresh/babel-plugin": "^0.4.1"
    ```

    2.3 重新安装依赖

3. 使用 Webpack5

新项目在创建项目时,选择编译工具为 "webpack5" 即可。

旧项目升级后需要更新依赖:

  • 建议首先删除 node_modulesyarn.lockpackage-lock.json
  • package.json 中删除 @tarojs/mini-runner@tarojs/webpack-runner 依赖,添加 @tarojs/webpack5-runner 依赖。
  • 重新安装依赖。
  • Taro 编译配置添加 compiler: 'webpack5',最后开启编译。

最后

接下来我们会继续对 v3.5 版本进行迭代,包括实现 H5 的依赖预编译等。而在 v3.6 版本则会落地对 Vite 的支持,同时优化运行时的性能。

最后的最后,衷心各位感谢参与 Taro 开源共建的同学!为了建立更加完善、更加可持续的 Taro 开源生态,突出贡献者价值,Taro 推出了更清晰的参与机制和荣誉激励机制,欢迎更多的同学参与进来~

标签:

· 阅读需 10 分钟
Bin
honlyHuang
TJ

为了建立更加完善、更加可持续的 Taro 开源生态,突出贡献者价值,我们参照成熟开源社区运行机制制定了《 Taro 贡献者晋级制度》,为热爱和喜欢 Taro 技术的开发者和贡献者提供更清晰的参与机制和荣誉激励机制。

晋升角色

晋升角色路线图

如图包含 4 个晋升角色:个人贡献者&生态个人贡献者、助手、合作者&生态合作者、技术委员会委员,晋升机制通过提名+投票的方式进行共识决策,晋升路径如下:

  • 个人贡献者 → 助手 → 合作者 → 技术委员会委员
  • 个人贡献者 → 合作者 → 技术委员会委员
  • 生态个人贡献者 → 生态合作者 → 技术委员会委员

对于一年内不活跃者,会进行自动进行降级,贡献突出者可申请荣休。

个人贡献者&生态个人贡献者(Individual Committer)

任何同意《 Taro 行为准则》的个人开发者,都可以基于《贡献者指南》进行 pull request 提交, bug 反馈 & 修复、新特性提议或 PR 均可,会在 Taro 官方文档中列为个人贡献者。当贡献者的有价值工作被其他合作者注意到后,可以被提名为合作者。

任何基于或围绕 Taro 生态进行的工具、插件、培训、教程等个人都会在 Taro 官方文档中列为生态个人贡献者。

助手(Triage)

负责 NervJS/taroNervJS/taro-ui 仓库新 issues 的维护,负责给 issues 或 pull requests 打标签,以及负责评论、关闭和重新开启 issue 或 pull request,负责将 bug 或 feature 分流给具体工作组。

  • 目的

    旨在减少 issue 列表,保持 issue 及时跟踪,促进新人参与及贡献 pull request。

  • 权益

    Github NervJS 组 Member 权限,相关项目 Triage 权限,可以管理 issues 和 pull requests(没有写权限)。

  • 申请方法

    对 Taro 项目有全面了解和深度开发经验的任何人,可以在 NervJS/taro README.md 中提交一个 pull request,说明申请成为助手的动机并同意本项目的行为守则,经 2 名合作者同意即可通过。

    申请 pull request 参考模版如下:

    PR 模板

  • 退出机制

    对 6 个月不活跃的小助手进行定期移除。

合作者 & 生态合作者(Collaborator)

负责维护 NervJS/taroNervJS/taro-ui 仓库,帮助用户和初级贡献者,参加具体工作组为当前项目贡献代码和文档,评审和评论 issues 和 pull requests。

  • 目的

    旨在不断丰富 Taro 特性、性能、安全等。

  • 权益

    Github NervJS 组 Member 权限,Github Write 权限,可以提交 commit 到 NervJS/taro 仓库,可以配置持续集成任务,负责 pull request 评审及合并,1 个 PR 合并需至少 2 名合作者或 1 名技术委员会成员同意即可进入观察期,观察期 3 个月即可正式成为合作者。

  • 申请方法

    合作者提名有突出贡献的个人贡献者,通过投票机制决定是否可以成为合作者。一名合格的合作者需具备:技术精进,业务精湛;沟通无障碍,至少读写无阻碍;人品优良,能钻研,不轻易半途而废;态度谦逊,能接受他人意见;Owner 心态,积极主动。

    申请 pull request 参考模版如下:

    PR 模板

  • 退出机制

    对不活跃的合作者,技术委员会有权进行移除或设置为荣休状态,荣休成员可以重新向技术委员会申请为活跃状态。如果一个合作者超过 6 个月无任何贡献,会自动设置成荣休状态。

技术委员会成员(Technical Steering Committee)

负责技术方向、项目管理、项目发布、贡献政策、仓库托管、行为准则、维护合作者列表,定期参加 TSC 活动,主席(主持人)会在线上主持活动,并做好活动记录并公布。

  • 目的

    解决难以达成共识的技术难题、新方向等。

  • 权益

    Github NervJS 组 Owner 权限。

  • 申请方法

    新增 TSC 成员需要由其他 TSC 成员提名并讨论投票。

    申请 pull request 参考模版如下:

    PR 模板

  • 退出机制

    在一季度内,缺席 75%的活动,且未参与任何一次投票,自动除名。成员可提出暂时”荣休“。

运行机制

技术委员会组成

如图运行机制包含技术委员会以及下设的 5 个团队(Core 团队、Plugins 团队、Platform 团队、创新团队、社区团队)。技术委员会由技术委员会委员组成,负责技术方向、项目管理、贡献政策、仓库托管、行为准则、维护合作者列表等,技术委员会主席负责定期组织会议。工作组由合作者成员组成,每个方向有一个 Owner,负责相关工作组的开发进展。

团队

  • Core 团队

    • Cli 工作组

      主要负责 Taro 命令行工具的开发和维护工作。
    • Compile 工作组

      负责维护、优化小程序和 H5 的编译系统。
    • Runtime 工作组

      负责维护小程序运行时系统。
  • Plugin 团队

    负责维护各 Taro 插件,包括端平台插件,React、Vue DevTools 等。

    • 端平台插件工作组

      负责维护各端平台插件,包括对微信、支付宝、百度、字节跳动、QQ、京东、企业微信、飞书、快手、钉钉、小红书等厂商小程序的适配等。
    • 混合开发组

      负责维护 Taro 与原生小程序的相互调用功能、Taro 开发原生插件等。
  • Platform 团队

    负责 App、Web、Open Harmony 等跨平台开发。

    • H5 工作组

      负责维护 H5 的各模块,包括路由、组件库、API 库等。
    • React Native 工作组

      负责React Native适配核心、组件库、API 库等部分的开发。
    • Open Harmony 工作组

      负责鸿蒙适配核心、组件库、API 库等部分的开发。
    • 快应用工作组

  • 创新团队

    Taro 创新特新、新方向探索,如 wasm、rust、vite、flutter、electron 等。

    • UI 框架兴趣组

      TaroUI、NutUI 等 UI 库和其他类型生态工具的研发与管理。
  • 社区团队

    负责 Taro 生态与运营,和 Taro 社区的运营推广工作。

技术委员会双周会

  • 时间:每双周周四前,在 TSC issue 中预告下次会议的内容和日期。
  • 议题:来自 Taro 下各项目中标注了 tsc-agenda 标签的事宜。会议结束后提交会议纪要 pull request。每次会议可邀请非委会参加,但无投票权。

基于共识决策的投票机制

各个晋升投票环节,基于共识决策原则,原则上达成多数一致。

  • 待投票的议题需要在会议前周知各成员,给予成员足够调研思考时间
  • 议题在即将达成一致时,在结题前必须询问“有人反对吗?”,以周知最后反对的机会
  • 议题无法达成一致时,可以投票多数支持是否延期到下一个会议,否则必须继续讨论
  • 议题满足“多数胜利”后即可通过,成员可以弃票

引导 / 培训机制

助手、合作者和技术委员会成员每个阶段,均提供相应的引导和培训,让新晋升者可以快速开展工作。

标签:

· 阅读需 11 分钟
TJ

关注 Taro 近期动态的朋友们可能都已经注意到,社区推送了一份问卷,向各位开发者征集对于 Taro 尚在调研中,或未发布各类新特性的建议,短时间内就收获非常多反馈,远超预期。

框架特性

依托于开放式跨端跨框架架构,Taro 框架和生态都聚集了大量特性供开发者使用,不论是使用 Vue、Preact 开发多端应用,还是各种拓展插件都是基于这样的架构开发的特性。目前我们准备了很多新特性的研发方向,依旧打算通过提交 RFC 提案来达成社区共识,希望这些特性是开发者在多端项目中真正需要的。

taro-feature.jpeg

从投票结果来看,大家对于 Vite 和 Flutter 有很高的期待,同时对于 pnpm 的支持也有很高的需求。同时也有很多开发者提到的了更多的需求,比方说支持 WebComponent API、小程序 SSR 方案,Webpack5、Windi、Tailwind,甚至是 Angular 等等,这些特性有的已经在最后的验证阶段,有的则还在调研当中,会在合适的时候发布到社区中,可以耐心等待。

Web 端

作为 Taro 最早支持的非小程序端,Taro H5 一直在稳步的迭代当中,在同步小程序能力的同时,也在不断补充 Web 端生态的能力,类似路由动画、多页面应用等等,都在不断迭代的过程中一一补齐,其他的特性比如 SSR、云开发等方案,或者备受期待的自定义 TabBar 也都会在后续的更新过程中不断补充。

taro-web.jpeg

当然对于很多 Taro H5 中未能同步的组件、API 等等,也将逐一对齐,但短期内完成也并不现实,因此我们会依据社区反馈的需求按照优先级提供相应的能力,比方说 CoverView、CoverImage 等等特性已经上线,剩下的诸如 MovableArea、MovableView 、PickerView、支付能力等等也是在排期中,有的则是已经有 PR 等待合并……同时也欢迎大家参与相关能力的共建,提升 Web 端能力的边界和开发体验~

App 端

App 端当前使用的是 RN 方案,问卷提出的特性也是基于这一方案考量的,目前 RN 和 H5、Open Harmony、快应用都是由 Taro 技术委员会 Hybrid 工作组负责,Taro RN 主要由该工作组的 Owner zhiqingchen ,其与 58 同城的小伙伴主要负责相关能力的架构与研发工作。

taro-rn.jpeg

Taro RN 目前也在高速迭代的过程中,每日相关的 Issue 和 PR 都十分活跃,社区提交的需求在评估过后,也能快速相应。目前提出的这些特性,在完成相关的评审之后,也会按照优先级逐一在后续版本中呈现。

小程序

对于小程序生态的持续性探索,一直以来都是我们前行的方向,自 Taro 诞生至今从未停止过相关的探索,当前的跨端方案,各种混合开发的能力等等都是在这条路上寻觅所得。时至 2022 年,在这条路上依旧未能穷尽,也有很多开发者们翘首以盼的新特性正在努力研发的过程中。

探索新特性

最受开发者们期待的是预渲染骨架屏方案;其次则是 Web Component 和 History 这些打通 Web 端能力的特性;同样也有不在少数的开发者希望能够支持小程序的 wxs 语法……

taro-mini.jpeg

混合开发能力

使用混合开发能力来拓展能力边界,丰富小程序生态逐渐成为很多开发者的选择。Taro 也在多端生态融合中,有很多努力与尝试,比方说 taro-convert 和 taro-blended 等等都在尝试打破多端生态的边界,但是在混合开发过程中,依旧有不少有待完善。

很多开发者朋友对于 Vue 生态有着很高的需求,不论是微信、支付宝小程序插件,还是开发独立分包,都有超过五成的投票,在之后的研发中,我们也会上调相关特性的优先级,敬请期待~

taro-mini-plugin.jpeg

开发中最常用的 Taro 版本是?

从 Taro 正式开源算起,按照版本号可以分成四类,目前最受欢迎的是 Taro 3.x,也就是 20 年团队提出的开放式跨端跨框架方案,有超过 90 % 的开发者正在基于这个版本开发项目,其中超过五成开发者正在使用最新的 3.4 版本。

taro-version.jpeg

Taro 3 方案受到社区的广泛接受这件事,让团队内备受鼓舞,对于方案能力优化与边界拓展也一直是我们下苦功的地方。当然也有不少开发者在问卷中表示自己还有一些项目正在依赖 Taro 的历史版本,也不必太过担心,尽管 Taro 团队已经公告过暂停维护相关版本,但是对于一些重大的问题,依旧会发新版本修复。

渐进式文档与教程

文档 & 视频 & 直播

社区化运营是 Taro 很长时间以来追求的目标,Taro RFC、Task List 还有贡献者等机制都是基于这一诉求逐步设计完善的设计的。为了能够达成这一目的,在各类技术文章和渐进式文档等等也有内容持续性输出。这次调研的四个方向也是我们一直都有文章输出的领域,在问卷中也有很多朋友提到了最佳实践、体积优化等等相关的内容也会整理成文章或教程输出,大家如果有更多想法也可以提出,和 Taro 相关的文章也可以在 Taro 社区中投稿,丰富社区的动态资讯。

2022 年,自 Taro 开源以来已经快足足四年,直播课程也是我们一直想做但没有足够人力去完成的内容,今年我们会考虑在重大版本或其他合适的时机去实现这件事情,侧重的主题还会再斟酌思量,如果感兴趣可以继续关注这方面的动态,或者在评论区说说你们的看法。

taro-edu.jpeg

写在最后

在问卷有一道开放题中,我们询问了大家对于 Taro 的发展有什么看法和意见,相当多朋友都在这一题中留言,其中不乏见解深刻的长文解读。正是这些来自各位开发者朋友们的看法,让我们对于社区有了更深刻的认知,同时也意识到了对于目前的 Taro 来说,在很多方面都有足够的提升空间,这也让我们确信目前社区前行的方向是对的,正有足够多的同伴和我们携手共进。

有很多朋友都提到了 Taro 对于 Vue 生态支持力度的不足,希望在使用 Vue 时能获得更好的开发体验;我们同样注意到,很多朋友希望文档可以更加完善,对于框架原理和各个版本功能有更全面的指引,对于贡献者和开发者都有更好的体验;生态不够健壮,缺少强有力的研发工具辅助开发,包括可靠的 UI 库等等……这些问题中,有很多都是我们正在努力探索并解决的,有些做得不够的地方也希望大家可以参与进来,共同为社区生态建设出一份力。

当然也有些许感动,很多小伙伴送出了大量的祝福和鼓励,很感谢大家对于 Taro 社区的支持,也正是因此,还有大量贡献者为 Taro 开源做出的努力,使得我们可以走到今天。

今后,Taro 也会以更加坚定的姿态向前迈进,大家有任何意见或问题都可以在评论区留下自己的看法,每一条反馈我们都会仔细阅读,希望可以和大家一同见证 Taro 社区的繁荣。

标签:

· 阅读需 10 分钟
JJ
TJ

距 Taro v3.4 beta 版本的发布已有一段时间,期间我们完善了对 Preact 和 Vue3 的支持,加入了一些有趣的特性,更是对 H5 作了大幅度的优化与调整,并于近期发布了 v3.4 的正式版本。

上月我们还推出了支持开发鸿蒙应用的 v3.5.0 canary 版本,欢迎各位同学关注~

一、支持使用 Preact

开发小程序应用时我们经常会受到包体积的掣肘,大型应用常常为了“尺土寸金”的包体积开展瘦身行动。在此背景下 React 将近 100k 的体积则显得有点过于奢侈。因此 Taro v3.4 实现了对 Preact 的支持,仅需少量配置即可从 React 切换到 Preact,有效地降低了包体积。

Preact 是一款体积超小的类 React 框架,提供和 React 几乎一致的 API,兼容 React 生态,而体积只有 5k 左右。

适配思路与具体用法请参阅 《Taro v3.4 发布 beta 版本 —— 支持使用 Preact 进行开发》

二、更好地支持 Vue 3.2

1. 支持 Composition API 版本的小程序生命周期钩子

文档地址

Vue 3.2 正式推出了 script setup 语法,过去 Taro 的 Options 式小程序生命周期钩子难以配合 script setup 语法进行使用。因此 Taro v3.4 提供了 Composition API 版本的小程序生命周期钩子,方便开发者配合 setup 语法组织和复用代码逻辑。

例子:

<script setup>
import { useDidShow } from '@tarojs/taro'

useDidShow(() => console.log('onShow'))
</script>

2. 支持 <style> v-bind 语法

Vue 3.2 的 <style> v-bind 语法让我们可以对样式进行数据绑定。它的实现使用了 DOM 的 MutationObserver API,但之前 Taro DOM 没有模拟实现此 API,因此使用 <style> v-bind 时会报错。

感谢 @b2nil 同学,参照 worker-dom 为 Taro DOM 实现了 MutationObserver API,让我们可以使用 <style> v-bind 语法。

Taro DOM 只针对 Vue3 暴露了 MutationObserver API,使用 React 或 Vue2 的同学不需要担心会增大代码体积。

3. 暴露 VueLoader 的配置

文档地址

开发者有时需要修改 VueLoader 的配置,例如使用小程序原生组件时需要配置 compilerOptions.isCustomElement。以往开发者只能通过 WebpackChain 去修改,Taro v3.4 暴露了 VueLoader 的配置,让开发者可以更方便地进行修改。

三、H5

1. 自定义多路由配置

Taro-H5 过去并不支持多路由访问同一个页面实例的操作,即便通过自定义路由配置也并不能在多个路由中访问同一个页面。

因此 Taro-H5 提供了自定义多路由配置的参数,供开发者根据需求自行配置。

文档地址

module.exports = {
// ...
h5: {
// ...
router: {
customRoutes: {
// "页面路径": "自定义路由"
'/pages/index/index': '/index',
'/pages/detail/index': ['/detail'], // 可以通过数组为页面配置多个自定义路由
},
},
},
}

2. 路由动画 by @ShaoGongBra

Taro-H5 支持了路由动画,开发者可以通过配置 app.config.js 来控制页面的动画效果,也可以通过覆盖 CSS 样式来调整动画。当然一些场景下,比如页面需要使用 position: fixed; 会因为 translate3d 影响实际效果,可以将动画禁用。

文档地址

export default {
// ...
animation: {
// 动画切换时间,单位毫秒
duration: 300, // 动画切换时间,单位毫秒
delay: 50,
}, // ...
}

3. dynamic-import-node

Taro-H5 打包时会将页面和组件拆分成独立的文件按需加载,但这么做会导致没有用到的页面和组件依旧会被打包,导致编译体积变大,在一些特殊场景中(比如 PWA 等需要严格限制包体大小时)会因此受到不小的困扰。

所以我们通过 babel 插件提供了移除懒加载的方法:

module.exports = {
presets: [
[
'taro',
{
framework: 'react',
hot: false,
'dynamic-import-node': true,
},
],
],
}

四、新增 defineAppConfig 与 definePageConfig 编译宏

再次感谢 @b2nil 同学为 Taro 新增了此特性。 文档地址:defineAppConfigdefinePageConfig

defineAppConfig

开发者可以使用 defineAppConfig 包裹 App 配置对象,以获得全局配置的类型提示自动补全,如:

// app.config.ts
export default defineAppConfig({
pages: ['pages/index/index'],
window: {
navigationBarTitleText: 'WeChat',
},
})

definePageConfig

使用 definePageConfig 包裹 Page 配置对象,同样可以获得页面配置的类型提示自动补全,如:

// page.config.ts
export default definePageConfig({
navigationBarTitleText: '首页',
})

除此之外,开发者可以不提供页面的配置文件,直接在页面逻辑文件中使用 definePageConfig 定义页面配置

如在 React 中:

// page.tsx
definePageConfig({
navigationBarTitleText: '首页',
})

export default function Index() {}

在 Vue 中:

<script>
definePageConfig({
navigationBarTitleText: '首页',
})

export default {}
</script>

五、其它重要特性与优化

性能

  • 修复 eventSource 导致的内存泄漏的问题,相关 commit
  • 修复 CustomWrapper 嵌套使用后失效的问题,感谢 @CS-Tao 的贡献。
  • 运行时体积优化,相比 Taro v3.3 版本大约减少了 30k 空间。

特性

  • 支持微信小程序开发者工具的热重载功能,文档地址
  • 支持支付宝小程序 2.0 构建
  • H5 端支持配置渲染页面的容器 id,文档地址
  • H5 端路由规则调整,Query 参数不再添加到 pageId 中,同时 TabBar 页面不会重新创建重复节点。
  • H5 端支持 entryPagePath 参数,by @liuchuzhang
  • H5 端支持 CoverView & CoverImage 组件,by @jiaozitang
  • H5 端支持 NodesRef.context & NodesRef.node 方法
  • H5 端支持通过 useResize 方法监听 resize 事件

修复

  • 修复预渲染失败的问题。
  • 修复多个页面使用同一个组件时,因为组件定义了 id 而导致事件触发失效的问题。
  • 修复 H5 端多页面滚动事件偶发性触发错误问题。
  • 修复 3.x 中 H5 端 API 失效的 Shaking 能力。

六、Breaking Changes

  • 旧项目升级到 Taro v3.4 需要安装对应的框架适配插件,详情浏览升级指南。
  • 百度小程序使用 onInit 代替 onLoad 生命周期,以优化首次启动时间。
  • H5 端调整了 showModal 返回的 errMsg 参数,和小程序接口对齐,如果项目内针对这个差异做过适配,可以在升级后移除。 #11040

升级指南

1. 把 Taro CLI 更新到 v3.4.0

npm i -g @tarojs/cli

2. 更新项目依赖

如果安装失败或打开项目失败,可以删除 node_modulesyarn.lockpackage-lock.json 后重新安装依赖再尝试。

修改 package.json 文件中 Taro 相关依赖的版本修改为 3.4.0,再重新安装依赖。

3.【Breaking Changes】安装对应的框架适配插件

因为 Taro v3.4 把各前端框架的适配逻辑拆分到对应的插件中,因此旧项目升级时需要安装对应框架的适配插件:

  • 使用 React,请安装 @tarojs/plugin-framework-react
  • 使用 Vue2,请安装 @tarojs/plugin-framework-vue2
  • 使用 Vue3,请安装 @tarojs/plugin-framework-vue3

最后

接下来 Taro v3.6 的工作重心将会放在小程序性能优化、编译系统升级(如升级 Webpack5)和优化 H5 能力(如输出 SSR 方案、优化路由系统等)上。

Taro 迭代的另一条主线是对 鸿蒙应用 && OpenHarmony 的适配,Taro 与 OpenHarmony 团队成立了跨平台 UI 兴趣组,将联合社区共同展开适配工作。目前第一阶段的开发工作已完成,并发布了 Taro v3.5-canary 版本。

相关咨询:

鸿蒙 & OpenHarmony 交流群:

Taro X Harmony 交流群

最后,衷心感谢参与了 Taro 开源共建的各位同学,也欢迎更多的同学参与进来!

标签:

· 阅读需 6 分钟
Jiaozi

一、背景

在开发的工作中,我们都引用过大量的社区优秀的开源项目,但怎么才能更好的了解这些开源项目呢,答案是 Join it

参与开源项目,能够帮助我们拓宽对研发项目的认识,更好的理解开源项目的原理,以及提高个人影响力、竞争力。

二、选择项目

人对于不熟悉的东西总是觉得高深莫测的,没有参与开源项目的经验的时候,会对参与开源项目不知道从何下手。

其实不然,在我们开发日常需求时就可以参与到开源项目中来,开发时用到的技术栈,就是我们最值得入手的开源项目了。

像我自己日常有开发微信小程序、京东小程序等跨平台的需求,这类型需求主要技术栈是 TaroTaro 本身就是 github star 近 30 k 的优秀开源项目了,那么我就可以从 Taro 着手,参与到开源项目的建设工作中。

image.png

三、快速开始

首先要了解、遵守开源项目的贡献规范,一般可以在官网找到贡献规范文档,如 Taro 贡献指南

1. 确定贡献形式

贡献形式多种多样,下面我以 “提交代码” 类型快速开始贡献流程。

s17110101222022

2. 找到感兴趣的 issue

Taro 官网:issue 中会列出所有被标记为 good first issue 或 Helper Wanted 的 Issues,并且会被分为 Easy、 Medium、 Hard 三种难易程度。

通过 issue 标签筛选,选择自己感兴趣的 issue,可以先从 "good first issue""Easy" 的开始:

s17454801222022

在 Issue 中查看有没有你感兴趣的而且可以被分配(无其他重复 Issue 且未被分配)的 Issue, Assignees 至自己。如无 Assignees 权限,可以通过 Draft Pull Requests 占位或在评论区中 @管理员使其分配任务。

s17463701222022

3. fork & clone

fork Taro 源码至自己仓库:

s17280901222022

clone 个人仓库的 Taro 源码至本地:

git clone https://github.com/jiaozitang/taro

4. 本地开发环境

在 Taro 源码项目中安装依赖并编译:

# 安装依赖
$ yarn

# 编译
$ yarn build

查看该 issue 涉及哪些 package,为这些 package 设置 yarn link,并在本地编译,使得调试项目能够 link 到开发中的源码:

Taro package 说明见文档:Taro 仓库概览

# yarn link
$ cd packages/taro-components
$ yarn link

# 本地编译
$ yarn dev

新建 Taro 项目用于调试 Taro 源码:

# 使用 npm 安装 CLI
$ npm install -g @tarojs/cli

# 初始化项目
$ taro init myApp

# yarn link
$ yarn link "@tarojs/components"

5. 开始开发

5.1 功能开发

通过以下步骤解决上述 “textarea 组件 onLineChange 时间调用无效” issue:

源码路径:packages/taro-components/src/components/textarea/textarea.tsx

onLineChange 事件:

  • 新增 onLineChange 事件
  • 监听输入事件,输入时通过行高计算行数
  • 行数改变时触发 onLineChange

auto-height 属性:

  • 新增 auto-height 属性
  • 新增 auto-height 样式

具体代码见:https://github.com/NervJS/taro/pull/10681/files

5.2 更新测试用例

在测试用例中添加对 onLineChange 事件、aotu-height 属性的测试。

源码路径:packages/taro-components/__tests__/textarea.spec.js

5.3 更新文档

在 README 中更新对 onLineChange、auto-height 的描述。

源码地址:packages/taro-components/src/components/textarea/index.md

5.4 自测

在本地测试项目 myApp 中,自测 onLineChange 事件、auto-height 属性功能是否正常,自测通过后,在 Taro 源码项目中跑自动化测试。

# 自动化测试
$ npm run test

6. 提交 pull request

测试通过后,在 github 中提交 pull requrst。

s18260601222022

7. code review 流程

提交 pull request 后等待社区 code review,并及时跟进 code review 反馈进行修改。

s09142901242022

四、总结

本文讲述了参与大型开源项目-Taro 的流程,其中以为 Taro 解决 issue 的视角,介绍了从认领 issue、解决 issue、贡献代码的完整过程。

在这个过程中,我们可以了解到如何参与开源项目并帮助开源项目解决问题,在开发工作中遇到开源项目的问题时,就可以愉快的参与进来了,不用因为一个小问题耽搁项目进度。

星星之火,可以燎原,在越来越多的开发者的参与下,开源社区的发展未来可期。

参考资料

标签: