请教大家一个关于前端数据刷新策略的问题。主要的场景就是从列表进入详情页面，在详情页面修改了数据后返回列表数据如何刷新的问题。

[andy7076]

不知大家有没有具体解决此类问题的方案，如果知道的话请不吝赐教。不管是重新发起网络请求获取数据，还是利用状态管理本地处理修改后的数据，但我都不知道在何时怎样具体的处理才算是一个 BestPractice 。 类似的场景除了标题描述，还有类似于详情页进入修改页面，修改后返回详情页。往往列表页面都是分页获取数据，请考虑返回时列表的滑动和页码状态。

[renmu123]

第一个就默认重新请求一次，确保数据肯定不会错。第二看产品经理的需求，一般怎么简单怎么来，产品经理有意见再改

[slime7]

如果是翻页切换列表数据的，我就重新获取；如果是移动端滚到底部加载的模式，我就修改状态。不知道合不合适，等一个大佬解答。

[hellolex]

在列表页重新获取数据啊

[xuanbg]

最简单粗暴的做法就是重新请求数据。好处是简单，而且顺便把列表刷新了。缺点是费时间费流量，而且为后端所不喜。

除了上面的办法，你可以自己刷新数据。好处是不用请求接口，也就没有卡顿。缺点是不能及时刷新列表的其他数据。

[wunonglin]

看需求，需求不限定的话省事重新刷

[zhlssg]

肯定是重新获取数据啊

[guanhui07]

重新获取数据

[iMusic]

用的啥框架，最近项目用的是 Vue，可以用 keepAlive 控制
1. 参数重置重新请求 （其他页面进入列表页）
2. 保持列表页状态不请求（详情页返回列表页）
3. 保持请求参数重新请求（编辑页返回列表页）

[Danswerme]

@iMusic 请问我这么做对不对：
编辑页面内点击编辑更新按钮，然后发起 http 请求之前更新 /添加列表页里对应的数据，然后发送 http 请求，如果后端更新成功则不用任何操作，如果更新失败就回滚数据，这样是否可行呢？

[dustinth]

重新从服务器获取数据是必要的, 这样给用户一个确定的反馈: 修改已经成功; 客户端刷新策略, 粗暴的是重刷(如果是全列表或分页就问题不大), 细一点就是 merge(更新客户端已有变化的部分, 适合如果是无限分页加载的情况, feed 流)

[iMusic]

@Danswerme 更新请求成功后再更新列表，失败就停留在编辑，方便用户进一步修改提交

[galikeoy]

有空就写本地列表状态管理，没空直接重新获取数据，还省事快熟不出错

[andy7076]

@slime7 是的，如果是 pc 端，只显示一部分分页那么刷新是完全没有问题的。但是如果是底部加载重新请求岂不是要先删除原来数据项的那一次请求的数据，再去重新发送每个请求，显然本地做状态管理是合适的。 就是不知道有没有业内通行处理这类业务的好办法。

[DOLLOR]

重新获取当页数据，只更新当页。
因为不能保证后端真的把数据入库，避免产生数据不一致给用户造成困扰，也能尽早把后端的问题暴露出来。

[andy7076]

主要是移动端上拉加载更多的模式，去修改还要去记录列表滑动状态的问题，目前我使用的策略是根据后端返回的状态前端对数据进行处理。 但是感觉这样对于开发的体验并不好，所以不知道大家通行的策略大概是什么样子的?

[andy7076]

@galikeoy 确实的，而且我们的要求比较低。是给开发后期维护的空间的。

[andy7076]

@hellolex 确实，中后台管理页面是可行的，体验也不会受到很大的影响。

[andy7076]

@renmu123 确实，看产品还有项目留给开发的时间吧。

[jy02534655]

这种场景想要做好可以考虑列表无刷新技术，列表滚动条页面不变。
1.新增成功后后端返回单条数据，前端将数据插入到列表。
2.编辑成功后后端返回单条数据，前端更新数据。
3.删除成功后，前端根据主键删除数据。

如果觉得列表无刷新比较麻烦，那就这样
1.新增成功后列表页码重置为 1，查询条件不变，请求数据
2.编辑成功后列表页码不变，查询条件不变，请求数据
3.删除成功后，根据数据总数计算页码是不变还是减一，请求数据

[IGJacklove]

修改成功后再修改本地的数据，最好别刷新，要是下拉加载那种列表数据的话体验会很不好，要是 pc 端那种分页的话重拉是最好的。

[redbuck]

mvvm 框架可以在跳之前把数据全部本地缓存.返回时从缓存取,另外还得恢复滚动高度.这是最简单粗暴的方案.

前端路由可以 keep-alive.

还有一种分片加载的方案.
将页面分为若干片,高度固定为 pagesize*item 高度.页面加载 /滚动时检查自身是否在视口(可以用 MutationObserver 实现).若在,则发起请求用数据替换占位图(数据来源无所谓,缓存也好,请求也罢,无关).
这样只需要记一个滚动高度即可,从详情跳回来与滚动到了再加载逻辑是一致的.

[andy7076]

@jy02534655 我觉得前者处理确实 ok，我确实忽略了后端可以直接返回修改后的数据，一直纠结产品新增后没有 id 的问题。 后者适用于中后台管理页面列表展示方式，不大适用于上拉加载更多这种列表的展示。 非常感谢分享，受益良多。

[redbuck]

@redbuck
分片加载需要后端配合下,新增一个接口,获取页面元数据,需要预先知道页面有几页.然后即可渲染页面,用占位图撑开高度.滚动开始之前就已经固定页面高度了.

[azcvcza]

做好列表浏览位置的标记？然后从详情回来不管有没有编辑，按存好的列表浏览位置参数去请求列表，再调整滚动。

[ByZHkc3]

方案一：重新发起请求拉数据。
方案二：返回修改成功后根据对应条目的 id 做单条数据的前端替换

[byzf]

缓存后直接等 success, success 后直接用缓存里的数据更新, 不重新请求.

服务端有其它客户端提交的更新, 用服务端推送, 客户端判断 id 是否重复再刷新.

[sjhhjx0122]

所以我们公司把详情全部都改成弹窗或者抽屉了,然后写了一个请求的 hooks,把分页记在了 hooks 里

[JayLin1011]

离开列表组件之后，列表组件会被销毁，在详情组件回来，本来就会触发生命周期钩子（一般是 created 或 mounted ）重新请求最新的数据。
如果没有执行生命周期钩子，说明有人用了 <keep-alive /> 对列表组件进行了缓存，事实上一般这种数据量较大的列表组件确实会进行组件缓存的，但也可以根据需求来灵活配置缓存策略。
组件缓存是涉及应用级别状态管理，可以结合 Vuex + 路由导航守卫根据需求自由配置，Vuex 负责管理全局的组件状态，路由导航守卫定制缓存方案。