Taro 多端开发的正确姿势:打造三端统一的网易严选(小程序、H5、React Native)

53,001

前言

笔者所在的趣店 FED 早在去年 10 月份就已全面使用 Taro 框架开发小程序(当时版本为 1.1.0-beta.4),至今也上线了 2 个微信小程序、2 个支付宝小程序。

之所以选用 Taro,解决微信小程序原生开发的痛点是一方面,另一方面团队也有多端统一开发的诉求,Taro 无疑是当时支持最好的。另外 React 也符合个人及团队的整体技术栈,可显著降低团队学习成本。

可以说,Taro 在小程序端、H5 端支持程度已经不错,也有不少上线实例可以查看,但在 React Native 的支持上,Github 中公开的项目在 RN 这块均未适配:

这种现况可以理解,毕竟要做到多端统一是有一定难度的,需准确把握各端差异,并做出合理取舍,而 Taro 虽以多端为设计目标,可重心在小程序端,没有对多端做出一定的开发约束,无从下手也便正常。笔者曾在 2018 iWeb 峰会 - 厦门站做过《多端统一开发实践》的分享,提到用 Taro 开发 RN 端的坑与大体思路,并加以实践。

结合趣店 FED 在过去小半年的实践经验,我们开发了首个 Taro 三端统一应用:taro-yanxuan(高仿网易严选微信小程序),用以探讨本文的重点:Taro 开发多端应用的正确姿势。

相关代码已开源:github.com/js-newbee/t…

在线预览

小程序端已支持微信小程序、支付宝小程序,但无法提供在线版,请 clone 代码本地运行。

H5 端、RN 端可在线预览(直接调用了网易严选接口,若要体验登录、购物车功能,请使用网易邮箱账号登录):

小程序 H5 - 访问链接 React Native
请 clone 代码本地运行
H5
Expo Snacks

如下是 React Native 的运行截图:

首页、分类 详情、加购物车 购物车、个人
首页、分类
二级分类、详情
购物车、个人

样式管理

样式管理是多端开发的首要挑战,因为 React Native 与一般 Web 样式支持度差异较大,上述几个未适配 RN 的多端项目多数已栽在样式上了,用到了大量 RN 不支持的样式,这种情况再要去兼容 RN 无异于重写页面,想必也是有心无力了。这也是本文所强调的,需把握正确的多端开发姿势。

样式上 H5 最为灵活,小程序次之,RN 最弱,统一多端样式即是对齐短板,也就是要以 RN 的约束来管理样式,同时兼顾小程序的限制,核心可以用三点来概括:

  • 使用 Flex 布局
  • 基于 BEM 写样式
  • 采用 style 属性覆盖组件样式

使用 Flex 布局

在进一步阐述之前,需先了解 RN 端几个影响样式方案的主要差异:

  • display 只有 flex / noneposition 只有 relative / absolute
  • 不支持标签选择器、子代选择器、伪元素,不支持 background: url() 等;
  • 文本要用 Text 标签包裹,文本的样式不能加在 View 标签上,只能加在 Text 标签上。

使用 Flex 布局,不单单是因为 RN 的 View 标签有默认样式 display: flex; flex-direction: column,更重要的是 Flex 可以解决幽灵空白问题:

// View 标签高度不会是 100px,图片下方会有几像素空白,称为幽灵空白
<View>
  <Image src={...} style={{ height: '100px' }}
</View>

常规解决方案是在 View 标签上设置 font-size / line-height: 0, 或 Image 标签 display: inline-block 等,但这些在 RN 中都不支持,给 View 标签设置 display: flex 算是唯一可靠方案了。

何况 Flex 布局能力强大,为啥不用呢?只需要注意一点,RN 中 View 标签默认主轴方向是 column,如果不将其他端改成与 RN 一致,就需要在所有用到 display: flex 的地方都显式声明主轴方向。

基于 BEM 写样式

RN 实际上只支持一种样式声明方式,即声明 style 属性:

<View style={{ height: '100%' }}

这也导致 Taro 在 RN 端基本只支持 class 选择器这一种写法(最终编译成对象字面量),BEM(Block Element Modifier)在此处就恰如其分的发挥了作用:

  1. 避免样式冲突(RN、小程序样式独立,但 H5 不是)
  2. 自解释、语义化

例如每行 2 个元素的列表,每行最后 1 个元素有特定样式,用伪元素选择器 :nth-child(even) 很容易实现,在 RN 中就需要自行计算了:

{list.map((item, index) => (
  <View className={classNames('block__element',
    index % 2 === 1 && 'block__element--even' 
  )} />
)}

基于 BEM 写 class 样式,不依赖其他选择器,虽然会让代码稍显繁琐,但也能保证多端都是行得通的,不存在支持问题。

采用 style 属性覆盖组件样式

小程序、RN 在页面、组件间传递样式时均有问题:

// 目前 Taro RN 端还未实现往组件传递 className 对应样式
<CompA compClass='my-style' />

// CompA,样式不生效
<View className={this.props.compClass} />

上述场景小程序虽可通过组件外部样式 externalClasses 实现,但官网文档有强调 "在同一个节点上使用普通样式类和外部样式类时,两个类的优先级是未定义的,因此最好避免这种情况";用全局样式倒是可以,但这样样式就不好维护了。

那么,通过 style 传递、覆盖组件样式也就成了唯一可选方案了。需要注意一点,样式文件是会经过编译处理兼容多端的,但 style 方式需要运行时兼容:

<Comp style={postcss({ background: '#fff' })} />

// 简单演示,如 RN 不支持 background,需改成 background-color
function postcss(style) {
  const { background, ...restStyle } = style
  const newStyle = {}
  if (background) {
    newStyle.backgroundColor = background
  }
  return { ...newStyle, ...restStyle }
}

从这个角度看,styled-components 或许是多端开发的最佳样式方案,然而 Taro 还不支持。另外微信小程序官方文档中有提到 "尽量避免将静态的样式写进 style 中,以免影响渲染速度",全部样式都写到 style 属性中恐怕不靠谱,但只用来覆盖少量样式不见得会有太大影响。

样式兼容

即便是把握了如上样式管理思路,多端样式差异的问题依然存在,例如 white-space: nowrap 这个样式在 RN 端会报错,Taro 有提供解决方案:

.text {
  /*postcss-pxtransform rn eject enable*/
  white-space: nowrap;
  /*postcss-pxtransform rn eject disable*/
}

但项目中不止一处会有这个问题,都这样写实在不太美观,可以用 Sass mixins 稍微封装下:

@mixin eject($attr, $value) {
  /*postcss-pxtransform rn eject enable*/
  #{$attr}: $value;
  /*postcss-pxtransform rn eject disable*/
}

.text {
  @includes eject(white-space, nowrap);
}

Sass mixins 并不能解决差异,但对于部分各端不兼容的样式,通过 Sass mixins 统一处理是比较合理的方式,代码相对美观也方便维护。

端能力差异

相较于样式,端能力的差异倒是还好,各端差异是客观存在的,更不用说 RN 在 iOS 与 Android 上就已存在大量差异。

应对端能力差异,要么改变实现思路,例如 RN 端还不支持 Taro.(get/set)StorageSync,那就改用 async / await + Taro.(get/set)Storage 实现,要么就得使用环境判断方式了。

Taro 提供 process.env.TARO_ENV 用于环境判断,多数小的差异都可以用这种方式来解决:

function foo() {
  if (process.env.TARO_ENV === 'weapp') {
    // 微信小程序逻辑
  }
  if (process.env.TARO_ENV === 'h5') {
    // H5 逻辑
  }
  if (process.env.TARO_ENV === 'rn') {
    // RN 逻辑
  }
}

这个时候也比较考验开发者的封装能力了,一般是建议将这些差异逻辑的判断统一起来,例如在 src/utils 中进行封装,对外提供一致的接口,尽量不要在业务页面中杂糅太多的判断。

而对于简单的环境判断处理不了的问题,就只能动用原生开发了,例如 Taro 还不支持 RN 端的 WebView 组件,就需要自己用原生 RN 实现(备注:Taro v1.2.16 已支持):

import { WebView } from '@tarojs/components'
// Taro 已开启 Tree shaking,可以放心引入各端组件
// 未使用的内容在编译时会被自动去掉
import WebViewRN from './rn'

export default class extends Component {
  render() {、
    {/* 根据环境进行调用 */}
    return process.env.TARO_ENV === 'rn' ?
      <WebViewRN src={this.url} /> :
      <WebView src={this.url} />
  }
}

// 原生 RN 页面,从 react-native 引入 WebView
import Taro, { Component } from '@tarojs/taro'
import { WebView } from 'react-native'

export default class WebViewRN extends Component {
  render() {
    return <WebView source={{ uri: this.props.src }} />
  }
}

process.env.TARO_ENV 的处理是编译时而不是运行时,且 Taro 引入了 Tree shaking,也就是说若不是编译 RN,上述用原生写的 WebViewRN 不会被打包,保证了编译成其他端时不会引入不支持的内容(否则在非 RN 端引用 react-native 会报错)。

原生页面能够引入,多端问题也就有了基本的实现保障。

不过上述方式会令代码中充斥着大量 process.env.TARO_ENV,还是不够理想的,3 月中旬发布的 Taro v1.2.17 提供了一种更方便的跨平台开发方式,更适合用于多端兼容:

// 例如原先有一个组件 test.js
// 若需要分别实现 h5 端、RN 端的组件,则将相应组件命名为:
// test.h5.js,test.rn.js
// 这样只需要引入 test,Taro 会根据环境自动引入相应的组件
// 就不需要写 process.env.TARO_ENV 的判断了
import Test from '../../components/test'

render() {
    // 例如编译 h5 时,实际引入的组件是 test.h5.js
    // 组件只需要遵循对外接口统一即可
    return <Test data={data} onClick={onClick} />
}

Taro RN 端的坑

Taro RN 端目前小问题还是不少的,本项目开发过程中也顺带解了几个 bug:

给 Taro 提的 pr

除此之外还有好几个问题,时间关系还未提 pr 解决,暂且先绕过,但高度自适应这个坑还是值得一说的。

小程序、H5 可用 rpx / em 实现自适应,而 RN 的自适应方案麻烦些,一般需通过 Dimensions 获取宽高再进行换算。Taro 提供的 pxTransform() 可解决该问题,但编译 RN 端样式文件时并没有考虑这点,即 width: 100px 会被编译成 width: 50,而不是 width: Taro.pxTransform(100),也就无法适配不同的屏幕尺寸。

因此,目前 Taro RN 端还不好做到自适应,要么非百分比的宽高都用 style + Taro.pxTransform(),要么就得自己写个脚本去处理编译后的样式文件。

这个问题已提了 issue 2204,有需要的可以关注下解决进度

Taro H5 端的坑

Taro 对 H5 端的支持度尚可,若仅仅想要实现兼容小程序与 H5,也仍建议采用 BEM 写样式 + style 属性覆盖组件样式的方案,可以有效规避小程序自定义组件的诸多局限,只是在 CSS 特性上就不用像 RN 那样拘束,transition、伪元素等使用起来无压力。

另外就是小程序、RN 都没有跨域问题,但 H5 会有,这个可通过 devServer.proxy 解决,以及编译打包的静态资源是固定文件名,建议改成带 hash 值方便缓存管理,这些配置在项目里的 src/config 中都能找到,就不再复述了。

H5 端的坑更多的是集中在内置组件不够完善、端能力缺失较多,毕竟 Taro 的设计是以微信小程序为基准,去补充其他端的差异,编译成小程序就是直接用的小程序内置组件,但在 H5 端就需要一整套功能对等的内置组件,Taro 要做到一致所需的繁杂细节也可想而知。

举一个比较明显的坑来说,就是还不支持 Taro.switchTab(),暂时只能用如下方式先绕过:

if (process.env.TARO_ENV === 'h5') {
  Taro.navigateBack({ delta: Taro.getCurrentPages().length - 1 })
  setTimeout(() => { Taro.redirectTo({ url }) }, 100)
}

好在官方已计划在接下来的 1.3 版本重构 H5 TabBar,到时这个问题也就解决了。

其他

要做到多端统一,能说的细节点实在太多,上述实现思路虽然简单,但背后也都是隐含着对各端差异的斗争与取舍,本文也仅是列出最基本的几点,用于阐述 Taro 多端开发的核心思路。

本项目代码没有做过多封装,方便阅读,也实现了足够多的样式细节进行踩坑,具体涉及的踩坑点、注意事项都在代码中以注释 // TODO(Taro 还未支持的)、// NOTE(开发技巧、注意事项)注明了,更多内容就有待各位去实践、体会了。

注释

ps: Taro 的版本更新速度还是比较给力的,本项目最早基于 v1.2.11 开发,2 月 19 号发布时用的是 v1.2.13,到 3 月 11 号已更新到 v1.2.17 版本,笔者会尽量跟随版本变动对本文内容、github 代码做出相应完善。

总结

如前言所说,Taro 虽然是以多端为设计目标,但重心是小程序端,RN 端目前的支持情况不算特别理想。但充分理解多端差异、掌握正确的多端开发姿势(特别是样式管理方面,避免项目成型后再去兼容需要大动刀斧)之后,在简单的项目上是完全可以一展拳脚的。

若说 2 个礼拜开发一个小程序,是稀疏平常的事,但 2 个礼拜即搞定了小程序端(微信、支付宝、百度等等),还搞定了 H5、React Native 端,后续更新也只要改一处地方,这产出、维护效率就实在太惊人了,这大抵也就是 "Write once, run anywhere" 的魅力所在(虽然在前端领域极容易发展成 "Write once, debug everywhere" 😂)

相信随着小程序热度不断上升,还会有更多优秀的开源框架、解决方案涌现。而我们不倾向于造轮子,更关注基于现有方案如何更好地去开发多端应用。若有兴趣的前端小伙伴,不妨加入我们,一起搞事 caiminxing#qudian.com 😁(base 厦门)

本文由趣店 FED 出品,首发于趣店技术学院;项目开源地址 github.com/js-newbee/t…