这是第 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 的时候取。

存在哪

  1. 长久化缓存。 如果是数据长久化可存到 URL 或 localStorage 中，放到 URL 上有一个很好点在于确定性，易于流传。但 URL 能够先 pass 掉，因为在简单列表的状况下，须要存的数据比拟多，全副放到 URL 是不事实的，即便能够，也会让 URL 显得极其简短，显然不妥。 localStorage 是一种形式，提供的 getItem、setItem 等 api 也足够反对存取操作，最大反对 5M，容量也够，通过序列化 Serialize 整合也能够满足需要，另外 IndexDB 也不失为一种好的形式，WebSQL 已废除，就不思考了，具体可点击张鑫旭的这篇文章《HTML5 indexedDB前端本地存储数据库实例教程》查看比照。
  2. 内存。 对于不须要做长久化的列表或数据来说，放内存可能是一个更好的形式，如果进行频繁的读写操作，放内存中操作 I/O 速度快，不便。因而，能够放到 redux 或 rematch 等状态管理工具中，封装一些通用的存取方法，很不便，对于个别的单页利用来说，还能够放到全局的 window 中。

何时取

在进入缓存页面的时候取，取的时候又有几种状况

  1. 当导航操作为 POP 时取， 因为每当 PUSH 时，都算是进入一个新的页面，这种状况是不应该用缓存数据。
  2. 无论哪种导航操作都进行取数据，这种状况须要和何时存一起对待。
  3. 看具体的业务场景，来判断取的机会。

在哪取

这个问题很简略，存在哪就从哪里取。

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)@cacheHocexport 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