关于javascript:Taro-31-beta-发布-开放式架构新增-4-端支持

7次阅读

共计 5530 个字符,预计需要花费 14 分钟才能阅读完成。

作者:凹凸曼 -JJ

自 7 月初咱们正式公布了 Taro 3,至今半年工夫未然略去。期间咱们一直地修复着问题,同时也在构想着下一个 minor 版本。

面对小程序平台越来越多的大环境,Taro 是抉择偏安一隅,只反对局部的支流小程序,还是成为所有小程序平台开发、多端转换的基础设施,咱们在 v3.1 给出了答案: 开放式架构

一、开放式架构

背景

近年来业界推出的小程序平台越来越多,但 Taro 外围保护的平台只有 6 个(微信、支付宝、百度、头条、QQ、京东小程序),因而经常有同学提出能不能反对某某平台的 Feature Request。

基于目前的架构,对于繁多平台的兼容性代码散布于 Taro 外围库的各个角落,波及编译时与运行时等局部。反对一个新的平台须要改变所有的这些中央,开发复杂度高,同时社区也难以参加奉献。

为此咱们萌发了打造一个开放式框架的想法。指标是能够通过插件的模式扩大 Taro 的端平台反对能力:

  • 插件开发者无需批改 Taro 外围库代码,即可编写出一个端平台插件。
  • 插件使用者只需装置、配置端平台插件,即可把代码编译到指定平台。
  • 开发者能够继承现有的端平台插件,而后对平台的适配逻辑进行自定义。

端平台插件架构图

Taro 基于开放式架构的改变

1. 同步了小程序最新个性

咱们把内置反对的 6 个平台封装成了插件,CLI 默认会全副加载这些插件。封装的过程中,咱们检索了各小程序最新的组件、API,并全数进行更新与反对,对齐各小程序最新的能力。

2. 新增反对转换的平台

借助开放式架构,咱们编写了若干端平台插件,开发者装置后即可应用:

  • 企业微信插件:@tarojs/plugin-platform-weapp-qy
  • 钉钉小程序插件:@tarojs/plugin-platform-alipay-dd
  • 支付宝 IOT 小程序插件:@tarojs/plugin-platform-alipay-iot
  • 快手小程序插件(体验版):@tarojs/plugin-platform-kwai

对开发者的影响

没有影响,改变属于 Taro 外部架构重构,不会影响开发者应用。

还能够做什么有意思的事

除了扩大新的编译平台,咱们还能够通过继承于现有的端平台插件,来编写自定义的端平台插件,对平台的适配逻辑进行自定义:

如何编写端平台插件:文档地址

1. 疾速修复问题

因为小程序平台泛滥,而且它们也在一直地迭代,往往会呈现 Taro 对某个小程序新推出的组件或 API 反对不及时的问题。这时开发者首先须要分割 Taro 团队,再期待咱们跟进修复、公布新版本后能力失常应用,均匀须要期待一周或两周的工夫能力失去解决。

而基于开放式架构,开发者可能通过继承某个端平台插件,迅速开发出自定义端平台插件,实现对这些新组件或 API 的反对,无需期待 Taro 公布版本。

为微信小程序拓展 API 的例子:

  1. 运行时注入 API:
/** plugin/apis.ts */
export function initNativeApi (taro) {// 挂载额定 API:Taro.xxx()
  taro.xxx = function () {}
}

/** plugin/runtime.ts */
import {mergeReconciler} from '@tarojs/shared'
import {initNativeApi} from './apis'

// 把 initNativeApi 合并到 reconciler 中。// 这样能够侵入 Taro 运行时并批改 Taro 对象,达到减少 API 的目标
mergeReconciler({initNativeApi})
  1. 端平台插件入口:
/** plugin/program.ts */
import {Weapp} from '@tarojs/plugin-platform-weapp'

// 继承微信小程序
export default class Example extends Weapp {
  platform = 'example'
  // 步骤 1 中,runtime 文件的门路
  runtimePath = `@tarojs/plugin-platform-example/dist/runtime`
}

/** plugin/index.ts */
import Example from './program'
import type {IPluginContext} from '@tarojs/service'

export default (ctx: IPluginContext) => {
  ctx.registerPlatform({
    name: 'example',
    useConfigName: 'mini',
    async fn ({config}) {const program = new Example(ctx, config)
      program.start()}
  })
}

2. 属性精简

因为小程序组件的属性和事件都必须动态写死,不能够动静增加,所以 Taro 会把组件的所有属性和事件全副在模板里提前进行绑定。

但理论我的项目中很多状况下并不会应用到组件的所有属性和事件,循环这些冗余的属性和事件绑定也会占据很大一部分的体积,另外太多的事件绑定也会在肯定水平上升高小程序的性能。

以下是 View 组件模板的伪代码:

<template name="tmpl_0_view">
  <view
    hover-class="..."
    hover-stop-propagation="..."
    hover-start-time="..."
    hover-stay-time="..."
    animation="..."
    onTouchStart="..."
    onTouchMove="..."
    onTouchEnd="..."
    onTouchCancel="..."
    onLongTap="..."
    onAnimationStart="..."
    onAnimationIteration="..."
    onAnimationEnd="..."
    onTransitionEnd="..."
    disable-scroll="..."
    hidden="..."
    onAppear="..."
    onDisappear="..."
    onFirstAppear="..."
    style="..."
    class="..."
    onTap="..."
    id="..."
  >
    ...
  </view>
</template>

Taro 须要把 View 组件的所有属性和事件提前进行绑定,能力满足不同开发者的应用需要。但可能对于某位开发者来说,整个我的项目的 View 组件都没有应用到 hover-stop-propagation 这个属性,那么则能够思考把它精简掉,不编译到 View 组件的模板当中。

须要留神的是,对属性的精简可能会引起不必要的问题、使我的项目的保护变得艰难,特地当我的项目变大,开发者泛滥时,须要审慎设计和应用。

二、重要问题修复

v3.1 除了包含开放式架构的调整外,也不忘坚固外围。以下是 v3.1 对重要问题的修复状况,有一些在 v3.0 的 patch 版本曾经推出,一些则是 v3.1 中才推出,均予以列出:

1. [Breaking Change] 修复 Vue 中 App 生命周期被调用两次的问题

留神,此修复含有【Breaking Change】,如果你正在把 Vue 我的项目从 v3.0 降级到 v3.1,须要对入口组件进行如下批改:

// app.js

// v3.0
// Taro 运行时外部原本就会调用一次 new Vue,// 用户的入口组件多调用一次的话,会导致生命周期函数反复触发
const App = new Vue({// ...})

// v3.1
// 用户在入口文件中只须要导出入口组件的配置对象,不须要再调用 new Vue
const App = {// ...}

2. 优化反向转换性能

v3.1 中咱们对反向转换性能(Taro convert)进行了宽泛的验证,修复了大量问题,现已达到比拟高可用的状态。

具体文档:https://taro-docs.jd.com/taro/docs/next/taroize。

次要变动:

  • 反对应用 Behavior
  • 反对应用自定义 tabbar
  • 反对配置全局 usingComponents
  • 修复 catch 事件不能阻止冒泡的问题
  • 修复不反对挂载额定属性到 app 对象的问题
  • 修复循环的 key 值没有被正确编译的问题
  • 修复编译时没有解决款式中援用的字体的问题

反向转换例子

咱们尝试应用 taro convert 转换了四个 GitHub 上最热门的开源微信小程序利用,它们转换之后都体现良好:

EastWorld/wechat-app-mall – 微信小程序商城

tumobi/nideshop-mini-program – 基于 Node.js + MySQL 开发的开源微信小程序商城

RebeccaHanjw/weapp-wechat-zhihu – 仿知乎

jectychen/wechat-v2ex – V2EX

3. 反对阻止小程序滑动穿透

v3.0 推出后反馈最多的问题之一,就是在 touchmove 事件回调中调用 e.stopPropagation() 并不能阻止滑动穿透。

这是因为 Taro 3 的事件冒泡机制是独自在小程序逻辑层实现,所有事件都是绑定的 bind 而不是 catch。因而 touchmove 事件回调中调用 e.stopPropagation() 只会阻止下层组件的事件回调触发,而没有 catchtouchmove 能阻止滑动穿透的能力。

v3.1 中咱们为 View 组件减少了 catchMove 属性,只有 catchMove 属性值为 true,就会应用 catchtouchmove 代替 bindtouchmove 进行事件绑定,从而取得阻止滑动穿透的能力。

用法:

<View class='parent'>
  <View class='modal' catchMove> 滑动 .modal 时,并不会令 .parent 也一起滑动 </View>
</View>

4. 修复应用了 HOC 后分享生命周期办法不触发的问题

假使咱们在 v3.0 的 React 框架下,把页面应用 HOC 进行包裹,如 react-redux@connect,那么咱们设置的一些分享生命周期:onShareAppMessage, onShareTimeline 都将不会被触发。这时须要在页面的配置文件中对应设置 enableShareAppMessage: trueenableShareTimeline: true 能力解决。

v3.1 会在编译时扫描 onShareAppMessageonShareTimeline 是否有被调用,进而主动在页面配置文件中加上对应配置,大部分场景下不须要用户手动设置。

留神,如果分享生命周期被封装在基类或自定义 Hooks 中,还是须要手动加上对应配置。

5. 修复支付宝小程序应用原生自定义组件报错的问题

在 v3.0,支付宝小程序应用原生自定义组件时,会报“元素不存在”的谬误。

这是因为支付宝小程序中规定,页面援用到的自定义组件,须要在页面对应的 axml 文件中定义。而 Taro 会把自定义组件定义在全局模板文件 base.axml 中。

因而 3.1 会辨认出应用了原生自定义组件的页面,把这些页面的模板都在页面对应的 axml 里进行定义。

6. 优化 base.xml 模板体积

v3.0 刚推出,很多同学反馈小程序体积过大的问题,其中一个起因是编译产物中 base.xml 这个模板的体积太大了。

自 v3.0.9 后,咱们对模板生成逻辑进行了重构:可能嵌套援用本身的组件,模板默认生成 16 次,如 View。不会嵌套援用本身的组件,模板只会生成一次,如 Map

以微信小程序为例,在最极其的状况下体积优化率达 85% 以上:

三、降级指南

从 v2.x 降级的同学须要先按 迁徙指南 进行操作。

从 v3.x 降级的同学,首先须要装置 v3.1 的 CLI 工具:

npm i -g @tarojs/cli@next

而后进入我的项目,把 package.json 文件中 taro 相干依赖的版本批改为 3.1.0-beta.4,再重新安装依赖(倡议先把 node_modules 文件夹删除)。至此降级完结。

Breaking

v3.1 带来了一个 Breaking Change,应用 Vue 进行开发的同学须要按批示进行批改。

四、将来布局

Taro 3 行将反对 React Native,欢送体验:《减少 React Native 反对的 Taro 3.2.0 版本测试通告》

五、感恩社区

开源不易,贵在保持。Taro 团队衷心感谢各位参加过本我的项目开源建设的敌人,无论是为 Taro 提交过代码、建设周边生态,还是反馈过问题,甚至只是茶余饭后探讨、吐槽 Taro 的各位。

现诚挚邀请您与 Taro 官网团队交换您的应用状况,有你相伴,Taro 更加精彩!问卷地址

最初,特别感谢为 Taro 从 v3.0 走到 v3.1 奉献过代码的各位,排名不分先后:

  • @wuchangming
  • @SyMind
  • @zhuxianguo
  • @Songkeys
  • @vdfor
  • @Spencer17x
  • @wingsico
  • @w91
  • @fjc0k
  • @Leechael
  • @southorange1228
  • @alexlees
  • @cncolder
  • @rottenpen
  • @gcxfd
  • @twocucao
  • @pengtikui
  • @kala888
  • @LengYXin
  • @iugo
  • @xuchengzone
  • @csolin
  • @xiaoyao96
  • @zhaoguoweiLLHC
  • @baranwang
  • @fred8617
  • @huanz
  • @Cslove
  • @002huiguo
  • @jazzqi
  • @Jetsly
  • @yuezk
  • @lukezhange001
  • @k55k32
  • @Soul-Stone
  • @hisanshao
  • @gjc9620
  • @younthu
  • @digiaries
  • @ZeroTo0ne
  • @GoodbyeNJN

欢送关注凹凸实验室博客:aotu.io

或者关注凹凸实验室公众号(AOTULabs),不定时推送文章。

正文完
 0