原本对状态管理的理解更多的是用于存储一些通用的比如用户信息、权限信息等来满足一些一对多或多对多的场景。
后来着手一个对日项目后对状态管理有了更深的了解，不仅仅是普通的用户、角色、权限这些的状态，普通的增删改查也可以使用状态管理进行维护。
业务场景是一个票据相关的后台管理系统，由于票据内容在随着使用时长的增加后会逐渐积累得越来越多，这也要求尽量减少后台接口的请求次数来优化使用体验。
在以往的开发中，一个带有翻页的列表检索，有以下几种操作：
- 条件过滤
- 新增
- 更新
- 删除
而在保证每页条目数不变的前提下（比如常见的每页 20 条），当使用条件过滤、创建、删除时都会引起新的列表数据与每页条目数的不匹配，因此在这些操作过后会重新请求一次查询接口来获取最新的 20 条数据，而如何能省下这一次查询操作？
为了满足这一需求在实际项目的使用中则需要一次查询全部条目的数据，并将所有条目的数据放置到状态管理中去，当使用创建、更新、删除操作的时候，除了向后台发送一次请求告知后台要进行的操作，还要去状态管理中进行一遍数据的维护更新操作，这样每次操作后最新的数据就不需要查询后台来获取而是通过状态管理来获取。
这样的设计使得条件过滤和翻页都变成了纯前端行为，性能上虽然首次需要请求全部数据，但后续每次操作都可以节省一次接口的调用，相对来说有所取舍，需要视项目情况而定。
不适用于一些数据经过后台逻辑处理才能显示的场景，比如新增票据的时候，新票据的状态字段则是根据系统中其他一些内容来决定的，这就必须要经过后台的再次查询才能获得。
1069
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
