Skip to main content

· 13 min read
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 来渲染组件。

默认情况下,Taro react 仍会在 legacy 模式下运行。简单修改 @tarojs/plugin-framework-react 插件的配置即可启用 concurrent 模式:

/** config/index.js */
const config = {
plugins: [
['@tarojs/plugin-framework-react', { reactMode: 'concurrent' }]
]
}

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

详细内容请参考 discussions

三、支持服务端渲染(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:
    "@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 min read
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 min read
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 min read
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 min read
Jiaozi

一、背景

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

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

二、选择项目

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

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

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

image.png

三、快速开始

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

1. 确定贡献形式

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

s17110101222022

2. 找到感兴趣的 issue

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

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

s17454801222022

在 issue 中 Assignees 至自己:

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、贡献代码的完整过程。

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

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

参考资料

· 10 min read
JSZ
JJ

一、背景

鸿蒙作为华为自研开发的一款可以实现万物互联的操作系统,一经推出就受到了很大的关注,被国人寄予了厚望。而鸿蒙也没让人失望,今年 Harmony2.0 正式推出供用户进行升级之后,在短短的三个月内实现了 1.2 亿的装机量,并且在前不久的华为开发者大会上,华为宣布 Harmony2.0 的装机量已经突破了 1.5 亿。

众多应用厂商都逐步推出了适配的鸿蒙应用,Taro 作为一个开放式的 跨端跨框架 解决方案,不少开发者期待将小程序的能力移植到鸿蒙 OS 上,可以使用 Taro 开发鸿蒙 && OpenHarmony 应用。

鸿蒙的方舟开发框架提供类 Web 范式编程,支持使用 JS 开发 UI 层,其语法与小程序相接近。经过前期调研,可以沿用 Taro 现有的架构适配鸿蒙

今年 6 月份我们新建了支持鸿蒙的提案,希望能达成三大目标:

  • 开发者可以使用 Taro 开发鸿蒙应用。
  • 开发者可以把现有的 Taro 应用适配到鸿蒙平台。
  • 开发者可以使用 Taro 的反向转换工具,把原生开发的小程序转换为 Taro 应用,再适配到鸿蒙平台。

目前 Taro 和 OpenHarmony 建立了官方合作关系,受邀并成立了跨平台前端框架兴趣小组(SIG-CROSS-PLATFORM-UI),同时 Taro 与华为鸿蒙&&OpenHarmay保持着内部沟通与分享,Taro 拥有的海量开发者和优秀案例,能有效补充华为鸿蒙&&OpenHarmay生态。

二、实现细节

鸿蒙的 JS UI 语法与小程序类似,但毕竟两者底层原理不一样,不可避免地存在许多差异。接下来将简单介绍鸿蒙与小程序的主要差异,和 Taro 又是如何处理这些差异的。

1. 鸿蒙与小程序的异同

1.1 项目组织

鸿蒙的项目组织和小程序类似,有入口文件 app.js 、页面、自定义组件。

其中页面、自定义组件均由三类文件组成:

  • .hml 用来描述布局结构。与小程序的模板文件相比,语法、支持的能力有少许区别。
  • .css 用来描述页面样式。
  • .js 用于处理页面和用户的交互,默认支持 ES6 语法。

1.2 配置文件

和小程序规定的入口文件、页面文件、自定义组件各自对应一份配置文件不一样,鸿蒙 JS UI 的配置文件只有一份。

鸿蒙的路由和小程序一样是配置式的,需要在 JS UI 的配置文件中进行配置。

1.3 样式

CSS 方面,鸿蒙和 RN 一样有着诸多限制。例如不支持盒子模型、各组件只支持部分 CSS 属性等。

1.4 组件 & API

鸿蒙提供了一系列功能丰富的组件,与小程序的组件相比,命名、功能上略有差别。

API 也是一样的,两者的 API 集合有部分交集,用法、功能上有差别。

2. 兼容细节

2.1 Taro 可以解决什么?

Taro 适配鸿蒙致力于尽可能地抹平差异,但作为一个框架,注定有它能够解决和不能解决的问题。

语法差异可以通过编写运行时框架去处理;使用鸿蒙的组件、API 去尽可能地实现微信小程序规范的组件和 API,以抹平两者之间的使用差别。

而 CSS 的差异、组件和 API 能力上的差异等依赖着鸿蒙底层实现,Taro 是无法解决的。

适配方案

2.2 鸿蒙插件

Taro 在鸿蒙方面的兼容工作主要由 @tarojs/plugin-platform-harmony 插件来完成,开发者引入该插件即可编译为鸿蒙应用。它主要做了这些适配工作:

a) 模板

熟悉 Taro 的同学都应该清楚,Taro 在小程序端利用 <template> 标签的递归来渲染页面动态的 DOM 树。而鸿蒙中并没有 <template> ,因此我们使用自定义组件进行递归。

b) 运行时

运行时主要在鸿蒙端兼容了小程序的生命周期和数据更新方法 setData

c) 组件 & API

我们使用鸿蒙的原生语法封装了符合微信小程序规范的组件库和 API 库。在兼容微信小程序的属性的同时,也保留了鸿蒙独有的支持属性。

目前共适配了 29 个组件,16 类API。组件示例库可参考:taro-components-sample

组件示例图

3. 架构图

架构图

三、使用方法

如您是新项目, 升级 Taro 选择鸿蒙模板即可;

旧项目需要按照如下方法进行手动配置:

1. 把 Taro 升级到 v3.5.0-canary.0 版本

首先需要安装 v3.5.0-canary.0 的 CLI 工具

npm i -g @tarojs/cli@canary

然后更新项目本地的 Taro 相关依赖:把 package.json 文件中 Taro 相关依赖的版本修改为 ~3.5.0-canary.0,再重新安装依赖。

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

2. 安装 taro 适配鸿蒙插件

(1)Taro 项目中安装鸿蒙插件 @tarojs/plugin-platform-harmony

$ yarn add --dev @tarojs/plugin-platform-harmony

(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 build —-type harmony —-watch

若您在步骤 2(2) 设置好了打包输出到鸿蒙项目的路径,即可查看 Taro 适配鸿蒙的应用效果。

testHarmony 为您通过 DevEco Studio 创建的 JS 项目。

运行效果图

四、最后

接下来我们会继续完善对鸿蒙的适配工作,预计会在 2022 年 Q1 发布 v3.5 正式版。

同时也希望社区有更多的开发者参与共建,无论是提出 Issues、在论坛发帖、提交 PR 还是帮助建设周边生态等,对我们来说都是宝贵的财富,让我们一起把 Taro 建设的更强。

Taro 团队衷心感谢一路走来大家对我们的支持,正是因为大家的期待、信赖敦促我们走向更好。

最后,该版本鸿蒙的适配由京东内鸿蒙共建小组共同完成,感谢以下同学:@AdvancedCat@jiaozitang@huozhongyi123@troy-sxj@JSZabc@crazyonebyone@evernoteHW@soulhat@xueshuai@LuMeiling

· 7 min read
JJ

项目体积是困扰小程序开发者的一大问题,如果开发者使用 Taro React 进行开发,更是不得不引入接近 100K 的 React 相关依赖,这让项目体积变得更加捉襟见肘。因此,Taro v3.4 的主要方向,是探索对于 Preact 的支持。

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

支持使用 Preact

Taro v3.4 正式实现了对 Preact 的支持,下文将简单介绍适配思路及用法。

适配思路

1. 运行时改造

Taro 在小程序环境模拟实现了类浏览器环境,因此理论上任意的前端框架都可以在 Taro 中使用。

对于 Preact,它与 React 最大的不同在于没有实现合成事件系统,而是直接使用浏览器的事件方法,此外还使用了少量和 React 不一样的 DOM API。

对于事件的适配,Taro 已经提供了浏览器规范的事件方法,因此只需要再处理 Preact 的事件名与小程序事件名的差异。而对于 DOM 方法,则需要额外实现 Preact 使用到的 DOM API。

2. 兼容 React 生态

Preact 使用了 preact/compat 去磨平与 React 的 API 差异,让 React 的各种生态库可以直接运行在 Preact 上。得益于此,开发时我们可以使用任意的 React 生态库,甚至对 React、ReactDOM 的 API 引用也不需要修改,只需要简单地配置 alias 即可:

// Webpack config
const config = {
"resolve": {
"alias": {
"react": "preact/compat",
"react-dom/test-utils": "preact/test-utils",
"react-dom": "preact/compat",
"react/jsx-runtime": "preact/jsx-runtime"
},
}
}

用法介绍

文档地址

新项目

运行 taro init 时,框架选择 Preact 即可创建基于 Preact 的项目。

现有的 React 项目

  1. 将 CLI、项目中 Taro 相关的依赖更新到 v3.4.0-beta 版本。

  2. 安装依赖:

yarn add preact @tarojs/plugin-framework-react
  1. 修改 Taro 编译配置:
config/index.js
const config = {
// ...
framework: 'preact'
}
  1. 修改 Babel 配置:
babel.config.js
module.exports = {
presets: [
['taro', {
framework: 'preact'
}]
]
}
  1. 如果项目使用了 TypeScript,请打开 skipLibCheck 配置,以避免和其它 React 生态库配合使用时报类型错误:
tsconfig.json
{
...
"skipLibCheck": true,
}

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

文档地址

Vue3 提供了 Composition API(组合式 API) 特性,和传统的 Options API 不同,Composition API 提供了全新的编码方式 ,可以让我们更好地去组织和复用代码逻辑。

过去 Taro 只提供了 Options API 版本的小程序生命周期钩子,开发者往往对于这些钩子和 setup 函数内部该如何通讯、如何共享数据等问题感到困惑,更是不能很好地兼容 script setup 语法。

因此 Taro v3.4 提供了 Composition API 版本的小程序生命周期钩子,让开发者更方便地使用 setup 语法,例子:

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

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

运行时体积优化

目前 Taro 对于前端框架的适配层代码都放在了运行时库 @tarojs/runtime 里,意思即当开发者使用 React 时,还是会包含 Vue2、Vue3 的适配层代码。(Tree Shaking 失败的原因是使用了 Webpack Provider Plugin 导出 @tarojs/runtime 里的 BOM API)

因此,Taro v3.4 以 Taro 插件的形式去实现对于各前端框架的适配,其中一个好处是可以把上述运行时适配层的代码拆分到各个插件内。加上对运行时代码的写法优化,3.4 版本的运行时减少了约 30k 的空间。

另一个好处是现在开发者可以通过编写 Taro 插件去支持任意的前端框架,而几乎不需要改动 Taro 的核心代码。

升级指南

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

npm i -g @tarojs/cli@beta

2. 更新项目依赖

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

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

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

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

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

其他

Breaking Changes

  • 百度小程序使用 onInit 代替 onLoad 生命周期,以优化首次启动时间。

最后

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

鸿蒙应用 && OpenHarmony

Taro 迭代的另一条主线是对鸿蒙应用 && OpenHarmony 的适配,Taro 与 OpenHarmony 团队成立了跨平台 UI 兴趣组(SIG-CROSS-PLATFORM-UI),联合社区共同展开适配工作。目前第一阶段的开发工作即将完成,12 月初会发布首个可用的体验版本。

相关咨询:

鸿蒙 & OpenHarmony 交流群:

· 18 min read
zhiqingchen

Taro React Native 重大更新来了,全方位降低上手成本,提升开发体验。全流程自动化,让开发者摆脱原生环境配置,专注前端开发。

背景

Taro 3.2.0 正式版本发布至今,已过去半年。在此期间,有不少社区开发者已经使用上 Taro 来开发 APP 了。看到社区的使用量越来越多,开发团队也是收获满满。

同时我们也收到了很多来自开发者的反馈,主要集中于开发环境配置复杂、组件和 API 的完善度不够及使用上的 BUG 等。对于组件和 API 的完善度及使用上的 BUG,我们都是尽可能地及时地处理并发布新版本。然而,对于开发者反馈的开发环境配置的问题,却很难复现及解决。

首先 Android + iOS + React Native + Taro,4个技术的各种环境配置,会让很多开发者望而却步。其次开发者面对的环境问题千奇百怪,很多问题难以通过远程协助解决。不少开发者在调研阶段,因为无法顺利运行,便放弃了使用。对于一个跨平台框架来说,主要目的是提效,而非给开发者带来更多困难。开发环境配置问题的解决,显得尤为重要。

这次我们从以下三个方向去优化整个开发流程,全面降低上手成本,让 Taro 开发 APP,变得无比轻松。

  1. 为 Taro 提供 react-native 模板,项目的初始化,只需要几个命令。
  2. 与 GitHub Actions 进行集成,不再需要本地安装原生开发环境,打包及发布交给 CI 去做。
  3. 提供 Taro Playground APP,可以通过应用商店或者 GitHub 下载安装,进行项目调试。

react-native 开发模板

目前使用 Taro 开发 React Native APP 时,我们需要一个原生壳工程,在另外一个仓库[1]。对于新手来说,通常会造成一些困惑:

  1. 没有接触过 React Native 开发的开发者首先需要理解 React Native 的开发流程,然后完成两个仓库的初始化。
  2. 两个仓库都需要安装依赖,并且需要保持某些依赖版本的一致性。当有依赖更新时,需要在两个仓库中进行操作,非常容易遗漏。
  3. 项目依赖原生的运行环境。开发者经常遇到安装过程报错,无法运行的场景。一些依赖包的下载需要切换源或依赖特定网络环境。

这些问题对新手入门很不友好,为此我们提供了一个初始化模板[2]。初始化项目使用 taro init [project] 选择 react-native 模板。

初始化完成后,便可使用进入开发。以下为一些常用命令:

# 更新相关依赖。在初始化完成后或 Taro 版本更新后执行,用于同步 peerDependencies。
$ yarn upgradePeerdeps

# 打包 js bundle 及静态资源。在初始化完成后执行,用于打包默认使用的 bundle。
$ yarn build:rn --platform ios

# 启动 bundle server
$ yarn start

# 启动 iOS
$ yarn ios

# 启动安卓
$ yarn android

具体操作可以查看录屏:

通过模板方式进行初始化的项目,有几个优势:

  1. Taro 仓库与壳工程仓库进行整合,不再需要管理双仓库。当然习惯双仓库模式的开发者,仍然可以正常使用。
  2. 当 Taro 进行升级时,可以通过执行 yarn upgradePeerdeps进行依赖同步。这里我们将 Taro 依赖的 React Native 相关库写入了 peerDependencies 中,然后通过 install-peerdeps 去完成依赖的同步。
  3. 集成了 GitHub Actions,可通过 workflow 完成 APP 的打包。

GitHub Actions

要解决开发环境的各种问题,通常的做法就是提供一个稳定的环境用于打包发布,在企业里是各种 CI/CD 平台。但对于开源项目来讲,就需要一个公开的平台,每个人都能使用,当然最好是免费的。于是我们想到了 GitHub Actions。

GitHub Actions 是 GitHub 提供的持续集成服务,于 2018 年 10 月推出。功能非常强大,并且免费(每月有限额),同时私有仓库也能够使用,非常契合我们的需求。

通过模板初始化的项目,可在 .github/workflows 目录中看到 4 个文件。分别为 iOS 和 Android 的 release 包和 debug 包的打包工作流。模板为了简化过程,设置为通过 git push 即可触发打包,可根据自身情况,配置合适自身业务场景的工作流。打包生成的产物可以在 Artifacts 中找到,也可以使用 softprops/action-gh-release@v1 action,将产物发布到项目的 Release 中。

这样一来新手便可以不需要关注原生环境以及 APP 打包的问题。开发时,可以安装 debug 包加载本地的 jsbundle,进行调试。发布时,交给 CI 进行打包,产物再提交到应用市场,整个过程完全不需要 AS 与 XCode。当然这里还有一些必要配置需要做,比如 APP 的签名等,将在后面的章节讲解。

GitHub Actions 功能非常强大,Taro 就用它来做打包发布等工作,可参考文档[3]或查看资料做进一步探索,做点有趣的事情。

GitHub Actions 配置

在 Taro 项目模板里面我们提供了一个 CI 脚本模板,开发者仍然需要进行一些配置,才能够开始打包。下面是打包 Android APP 的基础配置说明,iOS 同理:

  • 配置打包的环境变量

    env:
    APP_ID: com.taro.demo # 应用 ID
    APP_NAME: Taro Demo # 应用名称
    VERSION_NAME: 1.0.0 # 应用版本号
    VERSION_CODE: 10 # 用于应用市场、程序内部识别版本,判断新旧版本,一般递增处理
    KEYSTORE_FILE: debug.keystore # 签名文件
    KEYSTORE_PASSWORD: android # 密码
    KEYSTORE_KEY_ALIAS: androiddebugkey # 别名
    KEYSTORE_KEY_PASSWORD: android # 别名的密码
  • 通过 github secrets 管理秘钥配置

    通常我们不应该把密钥等敏感信息直接写在配置文件中,而是置于加密信息中。在 GitHub Actions 中,可以使用加密机制进行处理[4]。如图,在 setting -> secret 配上 CI 需要的 secret。然后在 workflow 中通过相应变量进行使用,如 ${{secrets.DEBUG_KEYSTORE_PASSWORD}}

壳工程 GitHub Actions 方案

对于壳工程与项目工程分开的场景,利用 CI 命令将两个项目进行合并也可以实现打包自动化。具体流程如下:

  1. 壳工程和业务项目合并

    因为 GitHub Actions 只能在当前项目下进行操作,所以需要将壳工程(taro-native-shell)合并到项目工程下。

  2. 合并项目和壳工程的 package.json

    在有原生依赖的情况下,必须保证壳工程和业务项目的原生依赖版本一致,不然打包可能会报错。

  3. 安装依赖

    在业务项目工程下安装合并后的 package.json 依赖。

  4. 软链依赖

    将安装到业务项目下的依赖软链至壳工程项目 node_module 下。

    ln -s ./node_modules ./taro-native-shell/node_modules
  5. 业务项目编译

    执行 taro/cli build:rn 编译命令,打包生成 jsbundle 与静态资源。

  6. 将编译产物移动到原生壳工程

    rn: {
    appName: 'taroDemo',
    output: {
    ios: './ios/main.jsbundle',
    iosAssetsDest: './ios',
    android: './android/app/src/main/assets/index.android.bundle',
    androidAssetsDest: './android/app/src/main/res',
    iosSourcemapOutput: './ios/main.map',
    androidSourcemapOutput: './android/app/src/main/assets/index.android.map',
    },
    }

    taro 编译 rn 输出静态资源,需要将资源移到原生项目中。

  7. 编译原生 APP

    到 ios 和 android 目录里分别执行对应的打包命令。

  8. 上传 APP

    将打包后的 APP 进行上传,提供下载链接。

    # iOS
    - name: Upload iOS Products
    uses: actions/upload-artifact@v2
    with:
    name: app-${{ env.BUILD_TYPE }}
    path: |
    ${{ github.workspace }}/ios/taroDemo.ipa
    ${{ github.workspace }}/ios/taroDemo.app.dSYM.zip
    # Android
    - name: Upload Android Products
    uses: actions/upload-artifact@v2
    with:
    name: app-${{ env.BUILD_TYPE }}
    path: ${{ github.workspace }}/android/app/build/outputs/apk/${{ env.BUILD_TYPE }}/app-${{ env.BUILD_TYPE }}.apk

    在 iOS 侧,release workflow 还集成了上传至 APP Store 命令:

    - name: Upload app to App Store Connect
    env:
    APP_STORE_CONNECT_USERNAME: ${{ env.APP_STORE_CONNECT_USERNAME }}
    APP_STORE_CONNECT_PASSWORD: ${{ env.APP_STORE_CONNECT_PASSWORD }}
    run: |
    cd ios
    xcrun altool --upload-app -t ios -f "taroDemo.ipa" -u "$APP_STORE_CONNECT_USERNAME" -p "$APP_STORE_CONNECT_PASSWORD"

上面整个流程对于开发者来说理解成本太高,配置过于繁琐,所以我们将前 6 个步骤封装成一个 GitHub action[5],开发者只需要添加一些配置项就能完成上面的流程。

- name: taro-native-publish
uses: shinken008/taro-native-publish@0.4.0
with:
REPO: ${{ env.SHELL_REPO }}
REPO_REF: ${{ env.SHELL_REPO_REF }}
REPO_PATH: taro-native-shell
BUILD_CMD: yarn build:rn
IOS_BUNDLE: ios/main.jsbundle
IOS_ASSETS: ios
ANDROID_BUNDLE: android/index.android.bundle
ANDROID_ASSETS: android
PLATFORM: android

对应的需要拉取的另一个仓库的配置:

env:
# 壳工程
SHELL_REPO: NervJS/taro-native-shell
# 壳工程ref
SHELL_REPO_REF: 0.63.2
# 壳工程目录
SHELL_REPO_PATH: taro-native-shell

配置介绍:

  • REPO: 壳工程地址
  • REPO_REF: 壳工程分支
  • SHELL_REPO_PATH: 壳工程目录
  • IOS_BUNDLE: 编译 iOS 后的 js bundle 地址
  • IOS_ASSETS: 编译 iOS 后的其他静态文件(图片等)地址
  • ANDROID_BUNDLE: 编译 Android 后的 js bundle 地址
  • ANDROID_ASSETS: 编译 Android 后的其他静态文件(图片等)地址
  • PLATFORM:编译的目标平台 ios/android

模板提供的 iOS 打包方案

iOS APP 的打包过程相对繁琐,这里我们直接使用了一个优秀的工具 fastlane[6]。fastlane 是一个为 iOS 和 Android 开发者提供的工具,可以自动执行繁琐的任务,如生成屏幕截图、处理配置文件和发布应用程序。

打包过程中的 info plist 文件修改、版本号修改、签名设置都可以交给 fastlane 去处理,经过 fastlane 的封装,开发者处理这些繁琐的任务,只需要添加几行配置即可。

但是要让 fastlane 在 GitHub Actions 使用,还需要几步操作。因为证书(Certificate)与描述文件(Provisioning Profiles)并不存储在项目仓库中,而每次工作流都是发生在随机的主机上的,这就需要我们在打包前,先将证书与描述文件导入到当前主机中。

Release 证书的导入过程如下:

  1. 将证书的 p12 文件转成 base64 字符串。

    cat Certificates.p12 | base64 | pbcopy
  2. 将第一步内容保存在项目的 secret 中,keyRELEASE_SIGNING_CERTIFICATE_P12_DATA

  3. p12 文件的密码保存在项目的 secret 中,keyRELEASE_SIGNING_CERTIFICATE_PASSWORD

  4. secret 内配置的相关信息导入到主机中。

    security import <(echo $SIGNING_CERTIFICATE_P12_DATA | base64 --decode) \
    -f pkcs12 \
    -k build.keychain \
    -P $SIGNING_CERTIFICATE_PASSWORD \
    -T /usr/bin/codesign

描述文件的导入过程,与证书的导入过程类似,均已封装在 workflow 中。

要将生成的 ipa 文件上传至 testflight 或者 APP Store 上,还需要提供用户名(APP_STORE_CONNECT_USERNAME)与密码(APP_STORE_CONNECT_PASSWORD),可参考文档进行生成[7]

至于证书与描述文件的生成,可查阅 iOS 开发相关文章[8],这里不再赘述。fastlane 配置的更多细节可查看 ios/fastlane/Fastfile 文件。

模板提供的 Android 打包方案

Android 的打包过程相对简单,直接调用 gradlew 命令即可。除了配置 APP 的基础信息,还需要为应用进行签名。可参考 Android 应用签名相关文档[9],生成签名文件,置于 android/app 目录中。

签名文件也可通过命令行工具生成:

keytool -genkey -alias android -keyalg RSA -validity 99999 -keystore release.keystore

打包相关参数,通过 gradlew-P, --project-prop 参数进行传入,如 ./gradlew assembledebug -Papp_id=${{ env.APP_ID }},其默认值在 android/gradle.properties 文件中定义。

Taro Playground APP

基于 GitHub Actions 与 Taro 模板,我们完成了项目初始化与打包过程的自动化。但对于想要体验 Taro 开发 APP 的开发者来说,仍然太过繁琐。为此,我们开发了 Taro Playground APP,并完全开源[10]。一方面可以展示组件和 API 的使用示例,另一方面提供了动态加载 jsbundle 的功能,便于开发人员进行本地代码的调试。

本地调试

开发者可以在 Taro Playground 仓库的 Releases 页面进行安装包下载[11],也可扫描以下二维码安装 APP。

AndroidiOS

Taro 工程中通过 yarn dev:rn --qr 启动 bundler server,打印包含 IP 及端口信息的二维码。通过 Taro Playground APP 扫描该二维码,即可加载 jsbundle 进行调试,需要保证手机与电脑处于同一个局域网中。

具体操作可以查看录屏:

示列代码

Taro Playground 项目提供了较全面的示例代码,开发者可以参考,避免一些可能遇到的坑,如有问题,欢迎 pr。

总结

通过上述多方面的优化,极大地降低了使用 Taro 开发 APP 的成本。大部分场景下,只需要掌握 Taro 和 React Native,再加上一些配置,即可完成 APP 的开发与发布。

使用过程中,如遇任何问题,可添加 "58技术小秘书" 或 "Taro 小助手" 为好友,备注 "Taro RN",加入官方交流群寻求帮助。

后续,我们还将带来支持 React Native 的 Taro UI 以及包含详细教程的技术小册,尽请期待。

同时我们也在征集社区优秀使用案例,欢迎开发者提交案例到案例仓库中[12]

相关链接

[1] 壳工程地址:https://github.com/NervJS/taro-native-shell

[2] 模板源码地址:https://github.com/NervJS/taro-project-templates/tree/v3.4/react-native

[3] GitHub Action 文档:https://docs.github.com/cn/actions

[4] GitHub Action 加密机制:https://docs.github.com/cn/actions/reference/encrypted-secrets

[5] Taro React Native Publish Action:https://github.com/shinken008/taro-native-publish

[6] fastlane官网:https://docs.fastlane.tools

[7] AppleID 密码生成:https://support.apple.com/en-us/HT204397

[8] 使用 GitHub Action 发布 iOS 应用:https://betterprogramming.pub/deploy-an-ios-app-to-testflight-or-the-app-store-using-github-actions-c4d7082b1430

[9] 安卓签名文件生成:https://developer.android.com/studio/publish/app-signing#generate-key

[10] Taro Playground 源码:https://github.com/wuba/taro-playground

[11] Taro Playground APP 下载:https://github.com/wuba/taro-playground/releases

[12] Taro 案例提交:https://github.com/NervJS/taro-user-cases

· 7 min read
JJ

距离 Taro 3.3 第一个 alpha 版本的发布,已过去三个月的时间。期间我们不断地对 3.3 版本进行打磨,除了优化 H5 同构方案外,还引入了一些提升开发体验的新特性和修复了若干重要问题。

支持使用 H5 标签

Taro 3.3 最重要的特性就是支持使用 H5 标签进行开发,让开发者在小程序环境中复用部分的 Web 生态。

例如在 React 中可以这样使用:

function Index () {
return (
<div>Hello World!</div>
)
}

相关背景及实现思路在 《Taro 3.3 alpha 发布》 一文中有详细说明。

用法

首先需要安装插件 @tarojs/plugin-html

$ npm i @tarojs/plugin-html

然后配置使用即可:

// config/index.js
const config = {
// ...
plugins: [
'@tarojs/plugin-html'
]
}

插件的详细用法请见文档

示例项目

为了验证同构功能的可用性和效果,我们对 CSS 样式库 WEUI、React 组件库 Antd Design Mobile、Vue2 组件库 VantUI 的所有组件进行了测试。结果显示有相当一部分的组件能直接运行在小程序环境中。

示例项目仓库地址:

What's news

在开发 @tarojs/plugin-html 插件的时候,我们发现需要为 Taro 模拟的 DOM APIs 新增一些方法,如 getBoundingClientRect 等。但是对于不使用这个插件的开发者来说这些 API 是冗余的,会增大包体积。因此我们对 @tarojs/runtime 进行了重构,把 DOM APIs 做成可插拔式,让开发者可以选择在最终的编译结果里只存在哪些 DOM APIs。

本次对运行时的重构也是为了 Taro 3.4 版本作铺垫。React、Vue2 和 Vue3 这些框架运行时需要的 DOM APIs 是不尽相同的,但是目前假设开发者使用了 React,编译结果里仍然会存在着只有 Vue2 或 Vue3 依赖的 DOM APIs。Taro 3.4 将会把对各 Web 开发框架的支持逻辑抽离成为一个个插件,如:@tarojs/plugin-framework-react 等,目的是剔除掉冗余代码。

例如,假设开发者没有使用渲染 HTML 文本的 API(如 React 的 dangerouslySetInnerHTML)。这时可以修改 Taro 编译配置的 mini.runtime.enableInnerHTML 选项,令最终的打包结果剔除掉相关代码:

// config/index.js
config = {
// ...
mini: {
runtime: {
enableInnerHTML: false
}
}
}

小程序支持使用框架的 DevTools

自 Taro 3.x 改造为运行时框架后,有不少同学抱怨小程序开发者工具的 AppData 面板看到的都是 Taro 虚拟 DOM 的序列化结果,而不是页面的 data 数据。为了缓解这个问题,并进一步地提升开发者的开发体验,Taro 对 React DevTools 和 Vue DevTools 进行了适配。只需要简单地配置,就能够和开发 Web 应用时一样使用框架的 DevTools。

React DevTools

安装并配置使用 @tarojs/plugin-react-devtools 即可,详细用法请见文档

效果图:

Vue DevTools

安装并配置使用 @tarojs/plugin-vue-devtools 即可,详细用法请见文档

效果图:

修复百度小程序 flex 布局的问题

在过去很长一段时间里,Taro 3 在百度小程序里是不支持使用 flex 布局的。原因是逻辑层的每个 Taro DOM 节点都在渲染层使用一个对应的 <template> 进行渲染,而百度小程序会把 <template> 渲染成一个真实节点。

非常感谢 @SyMind 的 PR,帮助 Taro 绕过了此问题。从 Taro 3.2 开始,部分组件在百度小程序中也能够使用 flex 布局。

相关的讨论和提交可以浏览 #6015 #9529

升级指南

从 v2.x 升级的同学需要先按 迁移指南 进行操作。

从 v3.x 升级的同学,首先需要安装 v3.3 的 CLI 工具:

npm i -g @tarojs/cli

然后手工修改 package.json 文件中 Taro 相关依赖的版本,再重新安装依赖;或者使用 taro update project 更新依赖。

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

The End

Taro 3.4

下一个 minor 版本,我们会考虑把对各个 Web 开发框架的支持逻辑拆分为对应的插件。让开发者可以以插件的形式为 Taro 拓展支持一门新的开发框架,我们会运用此能力进行对 PReact 的支持,希望能进一步减少用户的包体积。

鸿蒙应用 && OpenHarmony

近期我们也一直在探索对鸿蒙应用 && OpenHarmony的适配,目前已有一系列的讨论和开发计划,也有可以运行的 Demo,详情请见 鸿蒙 && OpenHarmony 适配小组

RoadMap:

欢迎各位开发者参与讨论和共建~

快应用

此外,社区大佬 @bgfist 正在为 Taro 开发支持快应用的功能。也欢迎各位开发者参与讨论和共建,相关 PR

感恩

时光飞逝,1 年前 Taro 3 正式发布,Taro 逐渐成为被社区喜欢、信赖的开源项目。未来我们也将继续做好 Taro 的开源工作,同时也希望社区有更多的开发者参与进来,无论是提出 Issues、在论坛发帖、提交 PR 还是帮助建设周边生态等。让我们一起把 Taro 做好,做强。

最后,衷心感谢为 Taro 从 v3.2 走到 v3.3 贡献过代码的各位同学!

· 10 min read

小程序的设计并没有完全遵循 Web 规范,导致小程序生态和传统 Web 开发生态之间的割裂,海量优秀的 Web 物料并不能直接用于小程序开发。因而 Taro 在相当一段时间内生态都相对薄弱,UI 框架选择不多的问题更是深深困扰着开发者。

另一方面,业界有着存量的 H5 应用,中短期内 H5 应用适配到小程序端的需要还会存在。我们希望能减少 H5 应用迁移到小程序端的成本,甚至能够直接运行在小程序端。

Taro 团队一直在思考如何最大限度地在小程序环境中复用 Web 生态,直到 Taro 3.0 诞生后,这种想法有了落地的可能。下文将介绍基于 Taro 3.0 实现 H5 同构的思路与问题,以及我们尝试适配了三大移动端 UI 框架 WEUIAnt Design MobileVantUI 的实验结果。

一、实现思路

Taro 3.0 是一款重运行时的跨端框架,它通过模拟实现浏览器的 BOM 和 DOM API 实现了对 React、Vue 等 Web 开发框架的兼容。

既然已经有了浏览器环境的 BOM 和 DOM API,Taro 应用和 Web 应用之间的鸿沟在于小程序组件和 HTML 标签之间的差异。