前言
为了提升用户的使用体验，多数场合我们都会对表单场景做一些缓存。当然最简单的情况是弹框处理下钻页面，这样基本上不用考虑换页返回时的状态缓存问题了，然而并不是所有的需求都满足这种场景，此处我就记录一下这次做缓存时的一些策略选择和遇到的问题。
背景
在做项目迭代时，第一期因为时间的原因，在保证原有功能的情况下，并没有做缓存处理。在这一期的项目迭代时，应用户和产品的需求，在原有的逻辑基础上添加了缓存处理。要求仅从下钻页面返回时保留离开的状态，否则呈现默认的状态。
项目结构
项目总体有三层：
- 登陆与权限判断层
- 公共路由层
- 业务页面层
登陆与权限判断层主要处理用户的登陆信息和对应页面的权限拦截，对于无页面权限的跳转和未登录状态做重定向处理，此外全局 vuex 存储获得的页面信息。
公共路由层主要处理获取的页面路由结构，同时与权限路由的菜单配置绑定，为各页面具体的权限约束提供对应的配置方法，方便产品将其与用户角色做相关绑定。
业务页面层仅关注对应业务逻辑的开发以及相关权限控制，统一接口和方法处理权限。
缓存方案
实现缓存的方法有多个，当前考虑的可行的方案有三种，分别是：
- vuex 做查询缓存
- keep-alive 做页面缓存
- webStorage 做条件缓存
首先说一下最后选择的方案是：sessionStorage 做条件缓存。这里分别来分析一下各方案的优缺点。
vuex 方案
vuex 方案是最容易想到的一个方案，毕竟对于跨页面的单页应用来说，在数据的传递上可谓是非常便捷的，对于查询缓存来说，其优点如下：
- 获取数据和传递数据容易
- 存储数据的操作简单，代码量不大
但是其缺点也很明显：
- 子页面刷新再返回会导致缓存的数据清空
- 无论是从子页面还是从别的页面切换回来，此都会缓存查询条件
缺点的解决思路：
对于数据会清空的问题，vuex 需要配合 webStorage 对刷新情况做处理；
对于任意页面都会缓存查询条件问题，又需要配合路由来做处理。
keep-alive 方案
keep-alive 方案与 vuex 方案基本差别不带，其缓存整个组件的状态，来保证跳转至其它组件后，当前组件的状态不改变。与 vuex 写法相比，其优点还包括：
- 整体的状态能得以保存，无需过多的数据缓存处理
但是其缺点相对 vuex 来说，也有一些：
- 页面参数共享不是很方便
- 每新增一个缓存页面都需要更新一下 include 数组
缺点的解决思路：
与 vuex 的解决思路基本一致，但是此还有另外一种操作方法
keep-alive 还有一种配合路由 meta 的操作写法。但是由于项目路由基本上是动态的，有后台提供相应的路由结构，配置相应的字段还需要与后台沟通，如果考虑不是很充足对于之后的开发也不是很友好；此外，该方法对于页面回退情况有相应问题（刷新同样无法处理）。因此此方案 pass 了。
webStorage 方案
鉴于之前的两种方案都包含路由的处理以及 webStorage 的使用，从代码复杂度来衡量，最终还是选用了此方法。具体的思路为：
- 路由层添加
$route的监听，并将其存入路由的 vuex 内，存储页面的to与from。 - 子页面删除
mount钩子，监听对应的from的路由，并设置immediate: true，为需要赋值缓存的页面做单独赋值处理，否则不做操作（如有默认查询则设置默认查询） - 在触发查询操作之前，缓存查询条件至对应的 sessionStorage
当然，这种方法并不是说缺点很少，其实它也有一些痛点没有解决：
- 难以抽象出通用的处理逻辑，仅能对路由层级做一层简单的抽象和存储
- 默认值赋值操作比较麻烦，特别是组件拆分比较细的情况
- 需要控制好 nextTick
问题总结
inject 和 provide
在使用 vuex 对监听的路由参数做缓存之前，首先考虑的是 inject 和 provide 来做动态传递，毕竟业务组件都在同一个 router-view 之下，这样做参数透传原则上是可行的。
但是问题是，不知道为何，对于 from 的路由总是监听不到，inject 获取的值一直为 undefined（即使能打印出来结果）。由于使用 JSON.stringfy 分析 from 时会报错，暂时也没法处理该问题，因此采用了 vuex 的备选方案。
class 风格的 ProvideReactive 还没有做过尝试，之后看能否可行
分页问题
在赋值默认值时，由于分页参数会存储在传参之中，但是总数值不会。虽然做初始化赋值之后查询内容与预期的结果一致，但是唯独分页组件的当前页数不正确（element UI 的 el-pagination），无论 currentPage 值为多少，其最终显示的结果仍然为 1。
原因：
el-pagination 处理分页逻辑时，在 total / pageSize < currentPage 的情况，其会使用默认的 internalCurrentPage 值，而此属性的默认值为 1。在查询完结果后在为对应的 total 和 currentPage 赋值时，因为 currentPage 和查询返回值是一致的，对于相同值的情况，其 internalPageCount 的新旧值就判断一致了，因此 pager 的显示就会一直为 1。
解决：
解决思路是在初始化时将 count 值设置大一些，或者缓存上一次的 count 值，然后初始化赋值。