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

[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 端那种分页的话重拉是最好的。