前言
笔者所在的趣店 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 代码本地运行 | Expo Snacks |
如下是 React Native 的运行截图:
首页、分类 | 详情、加购物车 | 购物车、个人 |
---|---|---|
样式管理
样式管理是多端开发的首要挑战,因为 React Native 与一般 Web 样式支持度差异较大,上述几个未适配 RN 的多端项目多数已栽在样式上了,用到了大量 RN 不支持的样式,这种情况再要去兼容 RN 无异于重写页面,想必也是有心无力了。这也是本文所强调的,需把握正确的多端开发姿势。
样式上 H5 最为灵活,小程序次之,RN 最弱,统一多端样式即是对齐短板,也就是要以 RN 的约束来管理样式,同时兼顾小程序的限制,核心可以用三点来概括:
- 使用 Flex 布局
- 基于 BEM 写样式
- 采用 style 属性覆盖组件样式
使用 Flex 布局
在进一步阐述之前,需先了解 RN 端几个影响样式方案的主要差异:
display
只有flex / none
,position
只有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)在此处就恰如其分的发挥了作用:
- 避免样式冲突(RN、小程序样式独立,但 H5 不是)
- 自解释、语义化
例如每行 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:
除此之外还有好几个问题,时间关系还未提 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…。