共计 6653 个字符,预计需要花费 17 分钟才能阅读完成。
这是第 95 篇不掺水的原创,想获取更多原创好文,请搜寻公众号关注咱们吧~ 本文首发于政采云前端博客:H5 页面列表缓存计划
前言
在 H5 日常开发中,会常常遇到列表点击进入详情页面而后返回列表的状况,对于电商类平台尤为常见,像咱们平时用的淘宝、京东等电商平台都是做了缓存,而且不只是列表,很多中央都用到了缓存。但方才说的都是 App,在原生 App 中,页面是一层层的 View,盖在
LastPage
上,人造就可能保留上一个页面的状态,而 H5 不同,从详情返回到列表后,状态会被革除掉,从新走一遍生命周期,会从新发动申请,会有新的状态写入,对于分页接口,列表很长,当用户翻了好几页后,点击详情看看商品详情后再返回列表,此时页面回到第一页,这样用户体验很差,如果在进入详情的时候将列表数据缓存起来,返回列表的时候用缓存数据,而不是从新申请数据,停留在来到列表页时的浏览地位;或者是可能像 App 那样,将页面一层层重叠在LastPage
上,返回的时候展现对应的页面,这样用户体验会好很多,本文简略介绍一下在本人在做列表缓存的时候思考的几点,后附简略实现。
思考
状态失落的起因
通常在页面开发中,咱们是通过路由去治理不同的页面,罕用的路由库也有很多,譬如:React-Router,Dva-router…… 当咱们切换路由时,没有被匹配到的 Component
也会被整体替换掉,原有的状态也失落了,因而,当用户从详情页退回到列表页时,会从新加载列表页面组件,从新走一遍生命周期,获取的就是第一页的数据,从而回到了列表顶部,上面是罕用的路由匹配代码段。
function RouterConfig({history, app}) {const routerData = getRouterData(app);
return (<ConnectedRouter history={history}>
<Route
path="/"
render={(props) => <Layouts routerData={routerData} {...props} />}
redirectPath="/exception/403"
/>
</ConnectedRouter>
);
}
// 路由配置阐明(你不必加载整个配置,// 只需加载一个你想要的根路由,// 也能够提早加载这个配置)。React.render((
<Router>
<Route path="/" component={App}>
<Route path="about" component={About}/>
<Route path="users" component={Users}>
<Route path="/user/:userId" component={User}/>
</Route>
<Route path="*" component={NoMatch}/>
</Route>
</Router>
), document.body)
如何解决
起因找到了,那么咱们怎么去缓存页面或者数据呢?个别有两种解决形式:1. 路由切换时主动保留状态。2. 手动保留状态。在 Vue
中,能够间接应用 keep-alive
来实现组件缓存,只有应用了 keep-alive
标签包裹的组件,在页面切换的时候会主动缓存 失活
的组件,应用起来十分不便,简略例子如下。
<!-- 失活的组件将会被缓存!-->
<keep-alive>
<component v-bind:is="currentTabComponent"></component>
</keep-alive>
然而,React
中并没有 keep-alive
这种相似的标签或性能,官网认为这个性能容易造成内存透露,暂不思考反对。
所以只能是在路由层做手脚,在路由切换时做对应的缓存操作,之前有开发者提出了一种计划:通过款式来管制组件的显示 / 暗藏,然而这可能会有问题,例如切换组件的时候无奈应用动画,或者应用 Redux
、Mobx
这样的数据流管理工具,还有开发者通过 React.createPortal
API
实现了 React
版本的 React Keep Alive
,并且应用起来也比拟不便。第二种解决方案就是手动保留状态,即在页面卸载时手动将页面的状态收集存储起来,在页面挂载的时候进行数据恢复,集体采纳的就是简略粗犷的后者,实现上比较简单。缓存缓存,无外乎就是两件事,存和取,那么在存、取的过程中须要留神哪些问题呢?
集体认为须要留神的有以下几点:
存什么?何时存?存在哪?何时取?在哪取?
存什么
首先咱们须要关怀的是: 存什么?既然要缓存,那么咱们要存的是什么?是缓存整个 Component
、列表数据还是滚动容器的 scrollTop
。举个例子,微信公众号里的文章就做了缓存,任意点击一篇文章浏览,浏览到一半后敞开退出,再一次关上该文章时会停留在之前的地位,而且大家能够自行测试一下,再次关上的时候文章数据是从新获取的,在这种场景下,是缓存了文章详情滚动容器的滚动高度,在来到页面的时候存起来,再次进入的时候拿到数据后跳转到之前的高度,除此之外,还有很多别的缓存的形式,能够缓存整个页面,缓存 state
的数据等等,这些都能够达到咱们想要的成果,具体用哪一种要看具体的业务场景。
何时存
其次,咱们须要思考的是什么时候存,页面跳转时会有多种 action
导航操作,比方:POP
、PUSH
、REPLACE
等,当咱们联合一些比拟通用的路由库时,action
会辨别的更加粗疏,对于不同的 action
在不同的业务场景下解决的形式也不尽相同,还是拿微信公众号举例,文章详情页面就是无脑存,无论是 PUSH
、POP
都会存高度数据,所以咱们无论跳转多少次页面,再次关上总能跳转到之前来到时的地位,对于商品列表的场景时,就不能无脑存了,因为从 List
-> Detail
-> List
须要缓存没问题,然而用户从 List
返回到其余页面后再次进入 List
时,是进入一个新的页面,从逻辑上来说就不应该在用之前缓存的数据,而是从新获取数据。正确的形式应该是进行 PUSH
操作的时候存,POP
的时候取。
存在哪
- 长久化缓存。如果是数据长久化可存到
URL
或localStorage
中,放到URL
上有一个很好点在于确定性,易于流传。但URL
能够先pass
掉,因为在简单列表的状况下,须要存的数据比拟多,全副放到URL
是不事实的,即便能够,也会让URL
显得极其简短,显然不妥。localStorage
是一种形式,提供的getItem
、setItem
等 api 也足够反对存取操作,最大反对 5M,容量也够,通过序列化Serialize
整合也能够满足需要,另外IndexDB
也不失为一种好的形式,WebSQL
已废除,就不思考了,具体可点击张鑫旭的这篇文章《HTML5 indexedDB 前端本地存储数据库实例教程》查看比照。 - 内存。对于不须要做长久化的列表或数据来说,放内存可能是一个更好的形式,如果进行频繁的读写操作,放内存中操作 I/O 速度快,不便。因而,能够放到
redux
或rematch
等状态管理工具中,封装一些通用的存取方法,很不便,对于个别的单页利用来说,还能够放到全局的window
中。
何时取
在进入缓存页面的时候取,取的时候又有几种状况
- 当导航操作为
POP
时取,因为每当PUSH
时,都算是进入一个新的页面,这种状况是不应该用缓存数据。 - 无论哪种导航操作都进行取数据,这种状况须要和何时存一起对待。
- 看具体的业务场景,来判断取的机会。
在哪取
这个问题很简略,存在哪就从哪里取。
CacheHoc
的计划
- 存什么: 列表数据 + 滚动容器的滚动高度
- 何时存: 页面来到且导航操作为
PUSH
- 存在哪:
window
- 何时取: 页面初始化阶段且导航操作为
POP
的时候 - 在哪取:
window
CacheHoc
是一个高阶组件,缓存数据对立存到 window
内,通过 CACHE_STORAGE
收敛,内部仅须要传入 CACHE_NAME
,scrollElRefs
即可,CACHE_NAME
相当于缓存数据的 key
,而 scrollElRefs
则是一个蕴含滚动容器的数组,为啥用数组呢,是思考到页面多个滚动容器的状况,在 componentWillUnmount
生命周期函数中记录对应滚动容器的 scrollTop
、state
,在 constructor
内初始化 state
,在 componentDidMount
中更新 scrollTop
。
简略应用
import React from 'react'
import {connect} from 'react-redux'
import cacheHoc from 'utils/cache_hoc'
@connect(mapStateToProps, mapDispatch)
@cacheHoc
export default class extends React.Component {constructor (...props) {super(...props)
this.props.withRef(this)
}
// 设置 CACHE_NAME
CACHE_NAME = `customerList${this.props.index}`;
scrollDom = null
state = {
orderBy: '2',
loading: false,
num: 1,
dataSource: [],
keyWord: undefined
}
componentDidMount () {
// 设置滚动容器 list
this.scrollElRefs = [this.scrollDom]
// 申请数据,更新 state
}
render () {const { history} = this.props
const {dataSource, orderBy, loading} = this.state
return (<div className={gcmc('wrapper')}>
<MeScroll
className={gcmc('wrapper')}
getMs={ref => (this.scrollDom = ref)}
loadMore={this.fetchData}
refresh={this.refresh}
up={{
page: {num: 1, // 以后页码, 默认 0, 回调之前会加 1, 即 callback(page) 会从 1 开始
size: 15 // 每页数据的数量
// time: null // 加载第一页数据服务器返回的工夫; 避免用户翻页时, 后盾新增了数据从而导致下一页数据反复;
}
}}
down={{auto: false}}
>
{loading ? (<div className={gcmc('loading-wrapper')}>
<Loading />
</div>
) : (
dataSource.map(item => (
<Card
key={item.clienteleId}
data={item}
{...this.props}
onClick={() =>
history.push('/detail/id')
}
/>
))
)}
</MeScroll>
<div className={styles['sort']}>
<div className={styles['sort-wrapper']} onClick={this._toSort}>
<span style={{marginRight: 3}}> 最近下单工夫 </span>
<img
src={orderBy === '2' ? SORT_UP : SORT_DOWN}
alt='sort'
style={{width: 10, height: 16}}
/>
</div>
</div>
</div>
)
}
}
成果如下:
缓存的数据:
代码
const storeName = 'CACHE_STORAGE'
window[storeName] = {}
export default Comp => {
return class CacheWrapper extends Comp {constructor (props) {super(props)
// 初始化
if (!window[storeName][this.CACHE_NAME]) {window[storeName][this.CACHE_NAME] = {}}
const {history: { action} = {}} = props
// 取 state
if (action === 'POP') {const { state = {} } = window[storeName][this.CACHE_NAME]
this.state = {...state,}
}
}
async componentDidMount () {if (super.componentDidMount) {await super.componentDidMount()
}
const {history: { action} = {}} = this.props
if (action !== 'POP') return
const {scrollTops = [] } = window[storeName][this.CACHE_NAME]
const {scrollElRefs = [] } = this
// 取 scrollTop
scrollElRefs.forEach((el, index) => {if (el && el.scrollTop !== undefined) {el.scrollTop = scrollTops[index]
}
})
}
componentWillUnmount () {const { history: { action} = {}} = this.props
if (super.componentWillUnmount) {super.componentWillUnmount()
}
if (action === 'PUSH') {const scrollTops = []
const {scrollElRefs = [] } = this
scrollElRefs.forEach(ref => {if (ref && ref.scrollTop !== undefined) {scrollTops.push(ref.scrollTop)
}
})
window[storeName][this.CACHE_NAME] = {
state: {...this.state},
scrollTops
}
}
if (action === 'POP') {window[storeName][this.CACHE_NAME] = {}}
}
}
}
总结
以上的 CacheHoc
只是最简略的一种实现,还有很多能够改良的中央,譬如:1. 间接存在 window
中有点粗犷,多页利用下存到 window
会失落数据,能够思考存到 IndexDB
或者 localStorage
中,另外这种计划若不配合上 mescroll
须要在 componentDidMount
判断 state
内的数据,若有值就不初始化数据,这算是一个 bug
。
缓存计划纵有多种,但须要思考的问题就以上几点。另外在讲述须要留神的五个点的时候,着重介绍了存什么和存在哪,其实存在哪不太重要,也不须要太关怀,找个适合的中央存着就行,比拟重要的是存什么、何时存,须要结合实际的利用场景,来抉择适合的形式,可能不同的页面采纳的形式都不同,没有固定的计划,重要的是剖析存取的机会和地位。
招贤纳士
政采云前端团队(ZooTeam),一个年老富裕激情和创造力的前端团队,隶属于政采云产品研发部,Base 在风景如画的杭州。团队现有 40 余个前端小伙伴,平均年龄 27 岁,近 3 成是全栈工程师,妥妥的青年风暴团。成员形成既有来自于阿里、网易的“老”兵,也有浙大、中科大、杭电等校的应届新人。团队在日常的业务对接之外,还在物料体系、工程平台、搭建平台、性能体验、云端利用、数据分析及可视化等方向进行技术摸索和实战,推动并落地了一系列的外部技术产品,继续摸索前端技术体系的新边界。
如果你想扭转始终被事折腾,心愿开始能折腾事;如果你想扭转始终被告诫须要多些想法,却无从破局;如果你想扭转你有能力去做成那个后果,却不须要你;如果你想扭转你想做成的事须要一个团队去撑持,但没你带人的地位;如果你想扭转既定的节奏,将会是“5 年工作工夫 3 年工作教训”;如果你想扭转原本悟性不错,但总是有那一层窗户纸的含糊… 如果你置信置信的力量,置信平凡人能成就不凡事,置信能遇到更好的本人。如果你心愿参加到随着业务腾飞的过程,亲手推动一个有着深刻的业务了解、欠缺的技术体系、技术发明价值、影响力外溢的前端团队的成长历程,我感觉咱们该聊聊。任何工夫,等着你写点什么,发给 ZooTeam@cai-inc.com