这样应该会有个问题：假如当前定时器是 cancel 的，那 pollingInterval 变化会自动启动定时器。这个行为和之前是有差异的。

这里是不是应该判断当前定时器是否正在等待中？

确实忽略了这个细节。

但是有一个疑问想要讨论下，因为我在开发过程中，设置了一个有效的 pollingInterval 后，所期待的行为是 "以最新的周期开启轮询"，但是目前的行为还需要多一步 run/runAsync，对不熟悉 api 的用户来说，在变更 pollingInterval 时可能也会有这样的想法，不知道这样会不会造成额外的理解负担。

在考虑，哪种表现形式更接近普遍的认知。

目前控制轮询 启动/停止，轮询时间变化 的逻辑是相互独立的，看看需不需要做下适当的合并。

我先处理为和当前版本行为保持一致

设置了一个有效的 pollingInterval 后，所期待的行为是 "以最新的周期开启轮询"，但是目前的行为还需要多一步 run/runAsync

这个是指变更 pollingInterval 后，不会立即执行一次吗？

另外当前变更应该还有造成另外一个问题：和 pollingWhenHidden 的配合问题。

假设当前屏幕隐藏，则定时会停止，监听下一次屏幕显示发起请求。但变更 pollingInterval 后，会打破这个规则。

这里的变更需要整体考虑。

是不是这么简单改一下就好了？

这个是指变更 pollingInterval 后，不会立即执行一次吗？

对，是这个意思

但是考虑和 pollingWhenHidden 的配合问题，确实页面隐藏时，即使变更了 pollingInterval 也不应该启动定时器。

之前我截图的代码应该是没有问题的。 只用关心当前是不是有正在等待的定时器，如果有，则重新开个新的定时器。如果没有，啥也不做。

这么写感觉有两个问题：
请求被 cancel 应该要用 timeRef 标识一下，这样写的话，mount 时 timeRef 是 undefined，可以正确判断，但是启动一次再cancel 后 timeRef 就变成了上一个定时器ID，再次变更 pollingInterval 会导致定时器误启动。
页面隐藏时，pollingInterval 的变更不应该导致 unsubscribeRef 的订阅被取消。

1. cancel 的时候，会清空 timeRef，不存在定时器误启动把。
2. 页面隐藏时，也就是没有正在等待的 setTimeout，也就不会做任何事情。

好像有问题，有个比较恶心的点：

1000->cancel->2000 手动取消，然后再变更 pollingInterval，则不应该重启定时器。
1000->0->12000 变成0取消，然后再变更 pollingInterval，好像又应该重启定时器。

吐血。这里感觉会越改越复杂了。

应该可以兼容这种情况的，我现在测一下

我提了个 pr，你看下。现在这样改我是可以接受的。你看看有啥问题么。

想先确认一下，因为 pollingInterval 变为 0 而导致的轮询停止，属于被 cancel 吗？

我的观点是不属于，0ms 只是个特殊的情况而已。

然后考虑这种情况：

1. pollingInterval -> 1000ms，开始轮询
2. pollingInterval -> 0ms，关闭轮询（但这时并不是 cancel 状态）
3. pollingInterval -> 1500ms，...

关于步骤 3 的表现，
实际：不能开启轮询
期望：步骤3,可以继续轮询

原因是，调用 cancel 停止轮询，和 pollingInterval 变为 0 停止轮询，走的都是一样的方法 stopPolling，所以没法区分轮询停止是因为 0 还是 cancel。

所以我认为这两种情况还是应该分开处理，我早一点的PR是通过引入一个 -1 标识，来判断当前是否处于 cancel 状态

stopPolling 应该专注处理清理定时器相关的工作，而 cancel 这个动作的额外操作应该在 onCancel 中扩展，这样会比较合适吧

这里用 timeRef.current 可能不准确
测试过程中发现，如果 pollingInterval 变化发生在一次请求的 onBefore 之后，onFinally 之前，此时 timeRef.current 是被清除了的（undefined），导致不能正确的进入这里的逻辑来启动新定时器。

要启动新定时器，应该满足下面两个条件：

1. 当前处于 非 cancel 状态（timeRef.current !== -1）
2. 页面显示； 或者页面隐藏，但 pollingWhenHidden 必须是 true （isDocumentVisible() || pollingWhenHidden）

我结合了一下我们的PR，调整了一下，你看看，能不能接受这样改呢

另外，当 pollingInterval 为 0 时也不能直接返回空对象，此时不是 cancel 状态，应该要返回 onCancel 和 onBefore 来处理可能到来的 pollingInterval 变更和 cancel 请求

稍后我看下，目前的代码变更还是偏复杂，我好好想想。

ok，感觉这里和 options.ready 的情景有点相似