Taro实践 - 深度开发实践体验及总结

时间 2019-11-08

标签 taro 实践深度开发体验总结繁體版

原文原文链接

前言

凹凸实验室的 Taro 是遵循 React 语法规范的多端开发方案，Taro 目前已对外开源一段时间，受到了前端开发者的普遍欢迎和关注。截止目前 star 数已经突破11.7k，还在开启的 Issues 有 200多个，已经关闭700多个，可见使用并参与讨论的开发者是很是多的。Taro 目前已经支持微信小程序、H五、RN、支付宝小程序、百度小程序，持续迭代中的 Taro，也正在兼容更多的端以及增长一些新特性的支持。javascript

回归正题，本篇文章主要讲的是 Taro 深度开发实践，综合咱们在实际项目中使用 Taro 的一些经验和总结，首先会谈谈 Taro 为何选择使用React语法，而后再从Taro项目的代码组织、数据状态管理、性能优化以及多端兼容等几个方面来阐述 Taro 的深度开发实践体验。css

为何选择使用React语法

这个要从两个方面来讲，一是小程序原生的开发方式不够友好，或者说不够工程化，在开发一些大型项目时就会显得很吃力，主要体如今如下几点：html

一个小程序页面或组件，须要同时包含 4 个文件，以致开发一个功能模块时，须要多个文件间来回切换
没有自定义文件预处理，没法直接使用 Sass、Less 以及较新的 ES Next 语法
字符串模板太过孱弱，小程序的字符串模板仿的是 Vue，可是没有提供 Vue 那么多的语法糖，当实现一些比较复杂的处理时，写起来就很是麻烦，虽然提供了 wxs 做为补充，可是使用体验仍是很是糟糕
缺少测试套件，没法编写测试代码来保证项目质量，也就不能进行持续集成，自动化打包

原生的开发方式不友好，天然就想要有更高效的替代方案。因此咱们将目光投向了市面上流行的三大前端框架React、Vue、Angular 。Angular在国内的流行程度不高，咱们首先排除了这种语法规范。而类 Vue 的小程序开发框架市面上已经有一些优秀的开源项目，同时咱们部门内的技术栈主要是 React，那么 React 语法规范 也天然成为了咱们的第一选择。除此以外，咱们还有如下几点的考虑：前端

React 一门很是流行的框架，也有广大的受众，使用它也能下降小程序开发的学习成本
小程序的数据驱动模板更新的思想与实现机制，与 React 相似
React 采用 JSX 做为自身模板，JSX 相比字符串模板来讲更加自由，更天然，更具表现力，不须要依赖字符串模板的各类语法糖，也能完成复杂的处理
React 自己有跨端的实现方案 ReactNative，而且很是成熟，社区活跃，对于 Taro 来讲有更多的多端开发可能性

综上所述，Taro 最终采用了 React 语法 来做为本身的语法标准，配合前端工程化的思想，为小程序开发打造了更加优雅的开发体验。java

Taro项目的代码组织

要进行 Taro 的项目开发，首先天然要安装 taro-cli，具体的安装方法可参照文档，这里不作过多介绍了，默认你已经装好了 taro-cli 并能运行命令。react

而后咱们用 cli 新建一个项目，获得的项目模板以下：git

├── dist                   编译结果目录
├── config                 配置目录
|   ├── dev.js             开发时配置
|   ├── index.js           默认配置
|   └── prod.js            打包时配置
├── src                    源码目录
|   ├── pages              页面文件目录
|   |   ├── index          index页面目录
|   |   |   ├── index.js   index页面逻辑
|   |   |   └── index.css  index页面样式
|   ├── app.css            项目总通用样式
|   └── app.js             项目入口文件
└── package.json
复制代码

若是是十分简单的项目，用这样的模板即可以知足需求，在 index.js 文件中编写页面所须要的逻辑github

假如项目引入了 redux，例如咱们以前开发的项目，目录则是这样的：npm

├── dist                   编译结果目录
├── config                 配置目录
|   ├── dev.js             开发时配置
|   ├── index.js           默认配置
|   └── prod.js            打包时配置
├── src                    源码目录
|   ├── actions            redux里的actions
|   ├── asset              图片等静态资源
|   ├── components         组件文件目录
|   ├── constants          存放常量的地方，例如api、一些配置项
|   ├── reducers           redux里的reducers
|   ├── store              redux里的store
|   ├── utils              存放工具类函数
|   ├── pages              页面文件目录
|   |   ├── index          index页面目录
|   |   |   ├── index.js   index页面逻辑
|   |   |   └── index.css  index页面样式
|   ├── app.css            项目总通用样式
|   └── app.js             项目入口文件
└── package.json
复制代码

咱们以前开发的一个电商小程序，整个项目大概3万行代码，数十个页面，就是按上述目录的方式组织代码的。比较重要的文件夹主要是pages、components和actions。json

pages里面是各个页面的入口文件，简单的页面就直接一个入口文件能够了，假若页面比较复杂那么入口文件就会做为组件的聚合文件，redux的绑定通常也是此页面里进行。
组件都放在components里面。里面的目录是这样的，假若有个coupon优惠券页面，在pages天然先有个coupon，做为页面入口，而后它的组件就会存放在components/coupon里面，就是components里面也会按照页面分模块，公共的组件能够建一个components/public文件夹，进行复用。

这样的好处是页面之间互相独立，互不影响。因此咱们几个开发人员，也是按照页面的维度来进行分工，互不干扰，大大提升了咱们的开发效率。
actions这个文件夹也是比较重要，这里处理的是拉取数据，数据再处理的逻辑。能够说，数据处理得好，流动清晰，整个项目就成功了一半，具体能够看下面***数据状态管理***的部分。如上，假如是coupon页面的actions，那么就会放在actions/coupon里面，能够再一次见到，全部的模块都是以页面的维度来区分的。

除此以外，asset文件用来存放的静态资源，如一些icon类的图片，但建议不要存放太多，毕竟程序包有限制。而constants则是一些存放常量的地方，例如api域名，配置等等。

项目搭建完毕后，在根目录下运行命令行 npm run build:weapp 或者 taro build --type weapp --watch 编译成小程序，而后就能够打开小程序开发工具进行预览开发了。编译成其余端的话，只需指定 type 便可（如编译 H5 ：taro build --type h5 --watch ）。

使用 Taro 开发项目时，代码组织好，遵循规范和约定，便成功了一半，至少会让开发变得更有效率。

数据状态管理

上面说到，会用 redux 进行数据状态管理。

说到 redux，相信你们早已耳熟能详了。在 Taro 中，它的用法和平时在 React 中的用法大同小异，先创建 store、reducers，再编写 actions；而后经过@tarojs/redux，使用Provider 和 connect，将 store 和 actions 绑定到组件上。基础的用法你们都懂，下面我给你们介绍下如何更好地使用 redux。

数据预处理

相信你们都遇到过这种时候，接口返回的数据和页面显示的数据并非彻底对应的，每每须要再作一层预处理。那么这个业务逻辑应该在哪里管理，是组件内部，仍是redux的流程里？

举个例子：

例如上图的购物车模块，接口返回的数据是

{
	code: 0,
	data: {
        shopMap: {...}, // 存放购物车里商品的店铺信息的map
        goods: {...}, // 购物车里的商品信息
        ...
	}
	...
}
复制代码

对的，购车里的商品店铺和商品是放在两个对象里面的，但视图要求它们要显示在一块儿。这时候，若是直接将返回的数据存到store，而后在组件内部render的时候东拼西凑，将二者信息匹配，再作显示的话，会显得组件内部的逻辑十分的混乱，不够纯粹。

因此，我我的比较推荐的作法是，在接口返回数据以后，直接将其处理为与页面显示对应的数据，而后再dispatch处理后的数据，至关于作了一层拦截，像下面这样：

const data = result.data // result为接口返回的数据
const cartData = handleCartData(data) // handleCartData为处理数据的函数
dispatch({type: 'RECEIVE_CART', payload: cartData}) // dispatch处理事后的函数

...
// handleCartData处理后的数据
{
    commoditys: [{
        shop: {...}, // 商品店铺的信息
        goods: {...}, // 对应商品信息
    }, ...]
}
复制代码

能够见到，处理数据的流程在render前被拦截处理了，将对应的商品店铺和商品放在了一个对象了.

这样作有以下几个好处：

一个是组件的渲染更纯粹，在组件内部不用再关心如何将数据修改而知足视图要求，只需关心组件自己的逻辑，例如点击事件，用户交互等
二是数据的流动更可控，后台数据 ——> 拦截处理 ——> 指望的数据结构 ——> 组件，假如后台返回的数据有变更，咱们要作的只是改变 handleCartData 函数里面的逻辑，不用改动组件内部的逻辑。

实际上，不仅是后台数据返回的时候，其它数据结构须要变更的时候均可以作一层数据拦截，拦截的时机也能够根据业务逻辑调整，重点是要让组件内部自己不关心数据与视图是否对应，只专一于内部交互的逻辑，这也很符合 React 自己的初衷，数据驱动视图。

用Connect实现计算属性

计算属性？这不是响应式视图库才会有的么，其实也不是真正的计算属性，只是经过一些处理达到模拟的效果而已。由于不少时候咱们使用 redux 就只是根据样板代码复制一下，改改组件各自的store、actions。实际上，咱们可让它能够作更多的事情，例如：

export default connect(({
  cart,
}) => ({
  couponData: cart.couponData,
  commoditys: cart.commoditys,
  editSkuData: cart.editSkuData
}), (dispatch) => ({
  // ...actions绑定
}))(Cart)

// 组件里
render () {
	const isShowCoupon = this.props.couponData.length !== 0
    return isShowCoupon && <Coupon /> } 复制代码

上面是很普通的一种connect写法，而后render函数根据couponData里是否数据来渲染。这时候，咱们能够把this.props.couponData.length !== 0这个判断丢到connect里，达成一种computed的效果，以下：

export default connect(({
  cart,
}) => {
  const { couponData, commoditys, editSkuData  } = cart
  const isShowCoupon = couponData.length !== 0
  return {
    isShowCoupon,
    couponData,
    commoditys,
    editSkuData
}}, (dispatch) => ({
  // ...actions绑定
}))(Cart)

// 组件里
render () {
    return this.props.isShowCoupon && <Coupon /> } 复制代码

能够见到，在connect里定义了isShowCoupon变量，实现了根据couponData来进行computed的效果。

实际上，这也是一种数据拦截处理。除了computed，还能够实现其它的功能，具体就由各位看官自由发挥了。

性能优化

关于数据状态处理，咱们提到了两点，主要都是关于 redux 的用法。接下咱们聊一下关于性能优化的。

setState的使用

其实在小程序的开发中，最大可能的会遇到的性能问题，大多数出如今setData（具体到 Taro 中就是调用 setState 函数）上。这是由小程序的设计机制所致使的，每调用一次 setData，小程序内部都会将该部分数据在逻辑层（运行环境 JSCore）进行相似序列化的操做，将数据转换成字符串形式传递给视图层（运行环境 WebView），视图层经过反序列化拿到数据后再进行页面渲染，这个过程下来有必定性能开销。

因此关于setState的使用，有如下几个原则：

避免一次性更新巨大的数据。这个更多的是组件设计的问题，在平衡好开发效率的状况下尽量地细分组件。
避免频繁地调用 setState。实际上在 Taro 中 setState 是异步的，而且在编译过程当中会帮你作了这层优化，例如一个函数里调用了两次 setState，最后 Taro 会在下一个事件循环中将二者合并，并剔除重复数据。
避免后台态页面进行 setState。这个更有多是由于在定时器等异步操做中使用了 setState，致使后台态页面进行了 setState 操做。要解决问题该就在页面销毁或是隐藏时进行销毁定时器操做便可。

列表渲染优化

在咱们开发的一个商品列表页面中，是须要有无限下拉的功能。

所以会存在一个问题，当加载的商品数据愈来愈多时，就会报错，invokeWebviewMethod 数据传输长度为 1227297 已经超过最大长度 1048576。缘由就是咱们上面所说的，小程序在 setData 的时候会将该部分数据在逻辑层与视图层之间传递，当数据量过大时就会超出限制。

为了解决这个问题，咱们采用了一个大分页思想的方法。就是在下拉列表中记录当前分页，达到 10 页的时候，就以 10 页为分割点，将当前 this.state 里的 list 取分割点后面的数据，判断滚动向前滚动就将前面数据 setState 进去，流程图以下：

能够见到，咱们先把商品全部的原始数据放在this.allList中，而后判断根据页面的滚动高度，在页面滚动事件中判断当前的页码。页码小于10，取 this.allList.slice 的前十项，大于等于10，则取后十项，最后再调用 this.setState 进行列表渲染。这里的核心思想就是，把看得见的数据才渲染出来，从而避免数据量过大而致使的报错。

同时为了提早渲染，咱们会预设一个500的阈值，使整个渲染切换的流程更加顺畅。

多端兼容

尽管 Taro 编译能够适配多端，但有些状况或者有些 API 在不一样端的表现差别是十分巨大的，这时候 Taro 没办法帮咱们适配，须要咱们手动适配。

process.env.TARO_ENV

使用process.env.TARO_ENV能够帮助咱们判断当前的编译环境，从而作一些特殊处理，目前它的取值有 weapp 、swan 、 alipay 、 h5 、 rn 五个。能够经过这个变量来书写对应一些不一样环境下的代码，在编译时会将不属于当前编译类型的代码去掉，只保留当前编译类型下的代码，从而达到兼容的目的。例如想在微信小程序和 H5 端分别引用不一样资源：

if (process.env.TARO_ENV === 'weapp') {
  require('path/to/weapp/name')
} else if (process.env.TARO_ENV === 'h5') {
  require('path/to/h5/name')
}
复制代码

咱们知道了这个变量的用法后，就能够进行一些多端兼容了，下面举两个例子来详细阐述

滚动事件兼容

在小程序中，监听页面滚动须要在页面中的onPageScroll事件里进行，而在 H5 中则是须要手动调用window.addEventListener来进行事件绑定，因此具体的兼容咱们能够这样处理：

class Demo extends Component {
  constructor() {
    super(...arguments)
    this.state = {
    }
    this.pageScrollFn = throttle(this.scrollFn, 200, this)
  }
  
  scrollFn = (scrollTop) => {
    // do something
  }
  
  // 在H5或者其它端中，这个函数会被忽略
  onPageScroll (e) {
    this.pageScrollFn(e.scrollTop)
  }

  componentDidMount () {
    // 只有编译为h5时下面代码才会被编译
    if (process.env.TARO_ENV === 'h5') {
      window.addEventListener('scroll', this.pageScrollFn)
    }
  }
}
复制代码

能够见到，咱们先定义了页面滚动时所需执行的函数，同时外面作了一层节流的处理（不了解函数节流的能够看这里）。而后，在 onPageScroll 函数中，咱们将该函数执行。同时的，在 componentDidMount 中，进行环境判断，若是是 h5 环境就将其绑定到 window 的滚动事件上。

经过这样的处理，在小程序中，页面滚动时就会执行 onPageScroll 函数（在其它端该函数会被忽略）；在 h5 端，则直接将滚动事件绑定到window上。所以咱们就达成小程序，h5端的滚动事件的绑定兼容（其它端的处理也是相似的）。

canvas兼容

假如要同时在小程序和 H5 中使用 canvas，一样是须要进行一些兼容处理。canvas 在小程序和 H5 中的 API 基本都是一致的，但有几点不一样：

canvas 上下文的获取方式不一样，h5 中是直接从 dom 中获取；而小程序里要经过调用 Taro.createCanvasContext 来手动建立
绘制时，小程序里还需在手动调用 CanvasContext.draw 来进行绘制

因此作兼容处理时就围绕这两个点来进行兼容

componentDidMount () {
    // 只有编译为h5下面代码才会被编译
    if (process.env.TARO_ENV === 'h5') {
        this.context = document.getElementById('canvas-id').getContext('2d')
    // 只有编译为小程序下面代码才会被编译
    } else if (process.env.TARO_ENV === 'weapp') {
        this.context = Taro.createCanvasContext('canvas-id', this.$scope)
	}
}

// 绘制的函数
draw () {
    // 进行一些绘制操做
  	// .....
    
    // 兼容小程序端的绘制
    typeof this.context.draw === 'function' && this.context.draw(true)
}

render () {
    // 同时标记上id和canvas-id
	return <Canvas id='canvas-id' canvas-id='canvas-id'/> } 复制代码

能够见到，先是在 componentDidMount 生命周期中，分别针对不一样的端的方法而取得 CanvasContext 上下文，在小程序端是直接经过Taro.createCanvasContext进行建立，同时须要在第二个参数传入this.$scope；在 H5 端则是经过 document.getElementById(id).getContext('2d')来得到 CanvasContext 上下文。

得到上下文后，绘制的过程是一致的，由于两端的 API 基本同样，而只需在绘制到最后时判读上下文是否有 draw 函数，有的话就执行一遍来兼容小程序端，将其绘制出来。

咱们内部用 Canvas 写了一个弹幕挂件，正是用这种方法来进行两端的兼容。

上述两个具体例子总结起来，就是先根据 Taro 内置的 process.env.TARO_ENV 环境变量来判断当前环境，而后再对某些端进行单独适配。所以具体的代码层级的兼容方式会多种多样，彻底取决于你的需求，但愿上面的例子能对你有所启发。

总结

本文先谈了 Taro 为何选择使用React语法，而后再从Taro项目的代码组织、数据状态管理、性能优化以及多端兼容这几个方面来阐述了 Taro 的深度开发实践体验。总体而言，都是一些较为深刻的，偏实践类的内容，若有什么观点或异议，欢迎加入开发交流群，一块儿参与讨论。