JavaScript 状态容器（vuex、redux）进行状态管理时，store设计问题

Question

近来一直在研究前端框架，之前是vue，现在开始看react，但一直对于store设计，感觉弄不清楚，

假设需要做一个带搜索、分页的列表，我想到的几种形式是

1 store中只存一页的数据，每次进入此页，重新请求数据。但这样的做法感觉用状态管理没有什么意义？

2 我目前采用的设计，以log为例，格式为

  // 日志详情信息,结构{日志id:日志详情对象}

  log: {

    1： {…}，

    2： {…}，  

    …

    },

  // 日志搜索结果,结构{搜索条件:日志id数组}

  searchLog: {

    'user_id/1/type/add/px/1/pz/10': [1,2,3,…],

    …

    }

页面根据条件从searchLog中获取id数组，再.map返回对应日志列表数据，

这样，请求过的数据可以重复使用，问题是在数据变动时，没什么好办法，感觉也只能清空重新获取了。

感觉都不是很好用，想请教看看大家是怎么做的？

Answer 1

跟store设计有什么关系。Redux只是给一个存东西的地方给你，至于以什么方式存这个数据，redux是不限制的。你当然也可以把之前获取到的数据存起来，但这会带来问题是，数据不是实时的（这是最核心的问题），并且数据会越来越大。而这么做的唯一好处只是调少几次接口，但多这几次对于页面以及服务器而言影响不大。你所认为的状态管理是什么？对于你这个列表而言，当前列表的内容，页数，筛选条件都是它的状态，“没有意义”从何而来？当然，这种简单的状态我们完全可以自己管理，不借助redux完全可以。所以说，这个东西和"redux"没有关系。是你对于你的页面应用的数据结构如何设计的问题。（引入redux的目的可以看Motivation）

Answer 2

这个需要根据具体的需求来斟酌。如果你的列表页数据（后端数据库数据）更新很频繁，建议不要缓存，只保存当前页。如果你的列表页数据好几天才会变动一次，可以尝试使用store来缓存很多页的数据，但。。。。是，还是建议不要这么干，避免到时候数据更新频繁之后，有新的坑，还有就是，如果后端连这么点频繁的请求都hold不住，那就不是后端的（这些优化，后端有解决方案），不要太纠结，就缓存一页。望采纳