[Bug]: usePagination对加载异常的页数会认为加载成功了

[thisXY]

Is this a Bug?

• I have confirmed that I want to report a Bug

Has this issue been reported before?

• I have confirmed that this Issue has not been reported before

Alova Version

2.21.3

Framework

React

Problem Description

关于使用usePagination的问题：比如请求第2页失败了，再次请求下一页(像这样：setPage(value => value + 1);) ，结果会请求第3页，然而第2页失败了不是应该继续请求第2页吗

Expected Behavior

加载失败后，页数会回退到上一次加载成功的页数，如此在(setPage(value => value + 1);)后便会继续尝试加载这个失败的页数

Reproduction Link

No response

Reproduction Steps

1. 使用usePagination加载页数2，此时加载发生接口异常(页数2加载失败了)
2. 继续通过setPage(value => value + 1);这样尝试加载，会发现此时加载了页数3

System Information

No response

Additional Information

No response

[MeetinaXD]

humm，这确实是没考虑过的事情。

我们可以讨论这个策略：“加载失败后，页数会回退到上一次加载成功的页数”：

• 自己实现这个功能会不会更好？有些用户也许不希望这样
• 如果采取这样的策略，网络不稳定时请求乱序，导致奇怪的回退。

例如请求顺序：A -> B -> C -> D，实际返回顺序：D -> C -> B -> A，其中 A 请求失败，这时回退到上一个成功的页数 B 就会显得很奇怪。

还有一种情况：用户只想直接跳过中间几页看后面的页面。这时用户根本不关心中间发生了什么，成功或失败都无所谓了。如果固执地回退重试，恐怕会造成不好的体验。

[thisXY]

humm，这确实是没考虑过的事情。

我们可以讨论这个策略：“加载失败后，页数会回退到上一次加载成功的页数”：

• 自己实现这个功能会不会更好？有些用户也许不希望这样
• 如果采取这样的策略，网络不稳定时请求乱序，导致奇怪的回退。

例如请求顺序：A -> B -> C -> D，实际返回顺序：D -> C -> B -> A，其中 A 请求失败，这时回退到上一个成功的页数 B 就会显得很奇怪。

还有一种情况：用户只想直接跳过中间几页看后面的页面。这时用户根本不关心中间发生了什么，成功或失败都无所谓了。如果固执地回退重试，恐怕会造成不好的体验。

那我们是否可以考虑提供这样一个方法比如loadNextPage呢，该方法意图就是加载下一页，那这样我们不用关心具体是加载的哪一页了，只要总是基于当前成功的最后一页往下一页加载就行了。如此还可以考虑有loadPrevPage。。

[MeetinaXD]

即使提供了这样的方法，我们实现的效果应该也是 setPage(value => value + 1) 而不是根据上一个成功的页码加载下一个，理由和上面是一样的。

这个需求没理解到应用场景是什么，即使真的有这样的需求，应该也是非常好实现的。但如果为了比较小众的需求而添加功能的话，我认为是不妥的。

你可以描述一下这个功能的使用场景吗？

[de1ck]

即使提供了这样的方法，我们实现的效果应该也是 setPage(value => value + 1) 而不是根据上一个成功的页码加载下一个，理由和上面是一样的。

这个需求没理解到应用场景是什么，即使真的有这样的需求，应该也是非常好实现的。但如果为了比较小众的需求而添加功能的话，我认为是不妥的。

你可以描述一下这个功能的使用场景吗？

这个可能适合移动端（或者瀑布流）加载下一页数据时候，加载失败的场景吧。如果中间请求失败，部分数据就缺失了

[thisXY]

即使提供了这样的方法，我们实现的效果应该也是 setPage(value => value + 1) 而不是根据上一个成功的页码加载下一个，理由和上面是一样的。
这个需求没理解到应用场景是什么，即使真的有这样的需求，应该也是非常好实现的。但如果为了比较小众的需求而添加功能的话，我认为是不妥的。
你可以描述一下这个功能的使用场景吗？

这个可能适合移动端（或者瀑布流）加载下一页数据时候，加载失败的场景吧。如果中间请求失败，部分数据就缺失了

是的。。 就是这种场景 我觉得有这样一个loadNextPage是合理的

[thisXY]

即使提供了这样的方法，我们实现的效果应该也是 setPage(value => value + 1) 而不是根据上一个成功的页码加载下一个，理由和上面是一样的。

这个需求没理解到应用场景是什么，即使真的有这样的需求，应该也是非常好实现的。但如果为了比较小众的需求而添加功能的话，我认为是不妥的。

你可以描述一下这个功能的使用场景吗？

在分页器上也有问题，分页器组件的当前页数属性如果直接用page[0]，此时也会发生异常，比如从页数2到页数3，如果页数3加载发生异常，会发现分页器上显示的是页数3但实际数据还是页数2的，这样其实看上去已经BUG起来了。更让人难受的是此时我想再尝试加载页数3，我不得不先点一下其他页数比如4再尝试请求页数3

对于你提到的：例如请求顺序：A -> B -> C -> D，实际返回顺序：D -> C -> B -> A，其中 A 请求失败，这时回退到上一个成功的页数 B 就会显得很奇怪。

我觉得并不奇怪，因为此时数据列表确实就是显示的B的数据，你从A回退到上一个到B页数这是完全正常了，我们总是应该保证显示的数据和页数能完全对应才是我们期望的