Taro实践 - TOPLIFE小程序 开发体验
前阵子,来自我们凹凸实验室的遵循React 语法规范的?多端开发方案?-?Taro?终于对外开源了,欢迎围观?star?(先打波广告)。作为第一批使用了?Taro?开发的TOPLIFE小程序的开发人员之一,自然是走了不少弯路,躺了不少坑,也帮忙找过不少bug。现在项目总算是上线了,那么,也是时候给大家总结分享下了。 与WePY比较当初开发TOPLIFE第一期的时候,用的其实是?WePY?(那时Taro还没有开发完成),然后在第二期才全面转换为用?Taro?开发。作为两个小程序开发框架都使用过,并应用在生产环境里的人,自然是要比较一下两者的异同点。 相同点
相同的地方也不用多说什么,都2018年了,这些特性的支持都是为了让小程序开发变得更现代,更工程化,重点是区别之处。 不同点
开发风格最大的不同之处,自然就是开发风格上的差异,?WePY?使用的是类Vue开发风格,?Taro?使用的是类React 开发风格,可以说开发体验上还是会有较大的区别。贴一下官方的demo简单阐述下。 WePY demo<style lang="less">
@color: #4D926F;
.userinfo {
color: @color;
}
</style>
<template lang="pug">
view(class='container')
view('userinfo' @tap='tap')
mycom(:prop.sync='myprop' @fn.user='myevent')
text {{now}}
</template>
<script>
import wepy from 'wepy';
import mycom from '../components/mycom';
export default class Index extends wepy.page {
components = { mycom };
data = {
myprop: {}
};
computed = {
now () { return new Date().getTime(); }
};
async onLoad() {
await sleep(3);
console.log('Hello World');
}
sleep(time) {
Promise((resolve,reject) => setTimeout(resolve,time * 1000));
}
}
</script>
Taro demoimport Taro,{ Component } from '@tarojs/taro'
import { View,Button } '@tarojs/components'
export Component {
constructor () {
super(...arguments)
this.state = {
title: '首页',list: [1,2,0);">3]
}
}
componentWillMount () {}
componentDidMount () {}
componentWillUpdate (nextProps,nextState) {}
componentDidUpdate (prevProps,prevState) {}
shouldComponentUpdate (nextProps,nextState) {
return true
}
add = (e) => {
// dosth
}
render () {
return (
<View className='index'>
<'title'>{this.state.title}</View>
<'content'>
{this.state.list.map(item => {
return (
<'item'>{item}</View>
)
})}
<Button className='add' onClick={this.add}>添加</Button>
</View>
</View>
)
}
}
可以见到在 WePY 里,? 而在 Taro 里,就是彻头彻尾的 React 风格,包括? 除此之外还有一些细微的差异之处:
总的来说,毕竟是两种不同的开发风格,自然还是会有许多大大小小的差异。在这里与当前很流行的小程序开发框架之一?WePY?进行简单对比,主要还是为了方便大家更快速地了解?Taro?,从而选择更适合自己的开发方式。 实践体验Taro?官方提供的demo 是很简单的,主要是为了让大家快速上手,入门。那么,当我们要开发偏大型的项目时,应该如何使用?Taro?使得开发体验更好,开发效率更高?作为深度参与TOPLIFE小程序开发的人员之一,谈一谈我的一些实践体验及心得 如何组织代码使用taro-cli生成模板是这样的 ├── dist 编译结果目录
├── config 配置目录
| ├── dev.js 开发时配置
| ├── index.js 默认配置
| └── prod.js 打包时配置
├── src 源码目录
| ├── pages 页面文件目录
| | ├── index index页面目录
| | | ├── index.js index页面逻辑
| | | └── index.css index页面样式
| ├── app.css 项目总通用样式
| └── app.js 项目入口文件
└── package.json
假如引入了redux,例如我们的项目,目录是这样的 ├── 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
TOPLIFE小程序整个项目大概3万行代码,数十个页面,就是按上述目录的方式组织代码的。比较重要的文件夹主要是?
除此之外,?asset?文件用来存放的静态资源,如一些icon类的图片,但建议不要存放太多,毕竟程序包有限制。而?constants?则是一些存放常量的地方,例如? 只要按照上述或类似的代码组织方式,遵循规范和约定,开发大型项目时不说能提高多少效率,至少顺手了很多。 更好地使用reduxredux大家应该都不陌生,一种状态管理的库,通常会搭配一些中间件使用。我们的项目主要是用了? 数据预处理相信大家都遇到过这种时候,接口返回的数据和页面显示的数据并不是完全对应的,往往需要再做一层预处理。那么这个业务逻辑应该在哪里管理,是组件内部,还是? 举个例子: 例如上图的购物车模块,接口返回的数据是 {
code: 0,data: {
shopMap: {...},// 存放购物车里商品的店铺信息的map
goods: {...},136);">// 购物车里的商品信息
...
}
...
}
对的,购车里的商品店铺和商品是放在两个对象里面的,但视图要求它们要显示在一起。这时候,如果直接将返回的数据存到? 所以,我个人比较推荐的做法是,在接口返回数据之后,直接将其处理为与页面显示对应的数据,然后再? ,payload: cartData}) // dispatch处理过后的函数
...
// handleCartData处理后的数据
{
commoditys: [{
shop: {...},136);">// 商品店铺的信息
goods: {...},136);">// 对应商品信息
},...]
}
可以见到,处理数据的流程在render前被拦截处理了,将对应的商品店铺和商品放在了一个对象了. 这样做有几个好处
实际上,不只是后台数据返回的时候,其它数据结构需要变动的时候都可以做一层数据拦截,拦截的时机也可以根据业务逻辑调整,重点是要让组件内部本身不关心?数据与视图是否对应,只专注于内部交互的逻辑?,这也很符合? connect可以做更多的事情
上面是很普通的一种?
页面内容有缓存
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |