fix(useRequest): 修复runAsync在节流状态下不生效的问题 by Arktomson · Pull Request #2899 · alibaba/hooks

Arktomson · 2026-01-25T15:25:01Z

Changed runAsync binding from .bind() to arrow function for dynamic lookup
Added unit tests for runAsync with throttle configuration
Fixes [bug useRequest] runAsync does not respect throttle options while run works correctly #2898

🤔 这个变动的性质是？

🔗 相关 Issue

💡 需求背景和解决方案

问题描述：

当使用 useRequest 配置节流选项（throttleLeading: true, throttleTrailing: false）时，runAsync 方法不遵守节流配置，会发送所有请求；而 run 方法能够正常工作。

问题根因：

问题由 useRequestImplement.ts 中使用 .bind() 方法导致。当调用 fetchInstance.runAsync.bind(fetchInstance) 时，会创建一个新函数，该函数永久引用绑定时刻的原始 runAsync 方法。之后，当节流插件替换 fetchInstance.runAsync 为节流版本时，已绑定的函数仍然指向原始的未节流方法。

解决方案：

将 runAsync 的绑定方式从：

runAsync: useMemoizedFn(fetchInstance.runAsync.bind(fetchInstance))

改为：

runAsync: useMemoizedFn((...args: TParams) => fetchInstance.runAsync(...args))

- Changed runAsync binding from .bind() to arrow function for dynamic lookup - Added unit tests for runAsync with throttle configuration - Fixes alibaba#2898

pkg-pr-new · 2026-01-25T15:25:52Z

npm i https://pkg.pr.new/ahooks@2899

npm i https://pkg.pr.new/@ahooksjs/use-url-state@2899

commit: 4e863be

whatwg6 · 2026-01-27T03:52:48Z

本地 patch 测试了下。节流虽然生效了，但是 2 个 promise 只有一个 resolve，另一个永远不会 resolve

Arktomson · 2026-02-05T08:40:21Z

本地 patch 测试了下。节流虽然生效了，但是 2 个 promise 只有一个 resolve，另一个永远不会 resolve

又是另外一个问题了0.0，改的话看上去就是节流期间多次请求的话返回同一个promise

Copilot

Pull request overview

This PR fixes useRequest’s exported runAsync so it correctly respects throttle behavior by avoiding a .bind() that pins the pre-plugin runAsync implementation, and adds tests around throttled runAsync usage.

Changes:

Update useRequestImplement to expose runAsync via an arrow function so it always calls the latest fetchInstance.runAsync (including plugin-wrapped versions).
Modify the throttle plugin’s runAsync wrapper to reuse a promise within the throttle window.
Add unit tests covering runAsync with throttle settings, including the reported leading: true / trailing: false case.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
packages/hooks/src/useRequest/src/useRequestImplement.ts	Fixes `runAsync` export to dynamically call the (possibly plugin-wrapped) `fetchInstance.runAsync`.
packages/hooks/src/useRequest/src/plugins/useThrottlePlugin.ts	Updates throttled `runAsync` promise behavior; currently has trailing-semantics issues.
packages/hooks/src/useRequest/tests/useThrottlePlugin.spec.ts	Adds tests for throttled `runAsync`, but doesn’t cover `throttleTrailing: true` behaviors.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-28T14:57:33Z

packages/hooks/src/useRequest/src/plugins/useThrottlePlugin.ts

      fetchInstance.runAsync = (...args) => {
-        return new Promise((resolve, reject) => {
+        const now = Date.now();
+
+        // If there's a current promise and it was created within the throttle window,
+        // return it to share the result
+        if (currentPromise && now - promiseCreatedAt < throttleWait) {
+          return currentPromise;
+        }


The currentPromise fast-path returns before calling throttledRef.current, which prevents lodash's throttle from registering subsequent calls. This breaks throttleTrailing: true (no trailing invocation) and throttleLeading: false (trailing uses the first call's args instead of the latest). Consider always invoking the throttled function on every call, while sharing a promise for the current throttle window, and ensure the executed callback uses the latest args for trailing behavior.

Copilot · 2026-03-28T14:57:33Z

packages/hooks/src/useRequest/src/plugins/useThrottlePlugin.ts

+                // Clear current promise after a delay to allow trailing calls
+                setTimeout(() => {
+                  if (currentPromise && Date.now() - promiseCreatedAt >= throttleWait) {
+                    currentPromise = null;
+                  }
+                }, 0);


The setTimeout(..., 0) blocks intended to clear currentPromise will almost never clear it because promiseCreatedAt was just set for this window, so Date.now() - promiseCreatedAt >= throttleWait will be false at +0ms. This logic is also duplicated in both then and catch. Either remove the clearing entirely (since the next window overwrites currentPromise), or clear it via a timer aligned to throttleWait / when the throttle window ends.

Copilot · 2026-03-28T14:57:34Z

packages/hooks/src/useRequest/__tests__/useThrottlePlugin.spec.ts

+  test('useThrottlePlugin should respect throttleLeading and throttleTrailing options with runAsync', () => {
+    const callback = vi.fn();
+
+    act(() => {
+      hook = setUp(
+        () => {
+          callback();
+          return request({});
+        },
+        {
+          manual: true,
+          throttleWait: 3000,
+          throttleLeading: true,
+          throttleTrailing: false,
+        },
+      );


Test coverage only exercises throttleTrailing: false for runAsync. Given the plugin exposes both throttleLeading and throttleTrailing, add a case for throttleTrailing: true (and ideally throttleLeading: false) asserting that the trailing invocation runs and uses the latest call's params; this would catch regressions in trailing behavior.

crazylxr · 2026-03-28T14:58:34Z

这次修复 useRequestImplement.ts 里 runAsync 的绑定方式，我觉得方向是对的；.bind(fetchInstance) 确实会把 runAsync 固定到插件改写前的实现，导致节流插件无法生效。

不过 useThrottlePlugin.ts 里新增的 currentPromise 复用逻辑会引入新的行为回归，建议这里再看一下。

问题在于：当节流窗口内再次调用 runAsync 时，现在会直接 return currentPromise，不会再进入 throttledRef.current(...)。这样 lodash throttle 收不到这次调用，trailing 触发就被绕过去了。

例如默认节流语义下（leading: true, trailing: true）：

runAsync(1) 立即执行
50ms 内再调用 runAsync(2)
预期应该在节流窗口结束后再触发一次 trailing 调用
但现在第二次调用直接复用旧 Promise，没有进入 throttle，最终只会执行第一次

所以这个改动虽然修复了 #2898 的场景，但会破坏 trailing: true（以及依赖“最后一次参数”的场景）。

我建议：

保留 useRequestImplement.ts 里把 runAsync 改成箭头函数转发的修复
不要在 throttle 窗口内直接短路掉对 throttledRef.current 的调用
另外补几个 runAsync 用例覆盖：
- leading: true, trailing: true
- leading: false, trailing: true
- trailing 场景下是否使用最后一次调用参数

这样能更稳地验证修复没有引入新的节流回归。

Arktomson · 2026-03-28T15:15:15Z

okk后续我修改完再说明一下

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年3月28日(周六) 晚上10:59 收件人: ***@***.***>; 抄送: "sheng ***@***.******@***.***>; 主题: Re: [alibaba/hooks] fix(useRequest): 修复runAsync在节流状态下不生效的问题 (PR #2899) crazylxr left a comment (alibaba/hooks#2899) 这次修复 useRequestImplement.ts 里 runAsync 的绑定方式，我觉得方向是对的；.bind(fetchInstance) 确实会把 runAsync 固定到插件改写前的实现，导致节流插件无法生效。不过 useThrottlePlugin.ts 里新增的 currentPromise 复用逻辑会引入新的行为回归，建议这里再看一下。问题在于：当节流窗口内再次调用 runAsync 时，现在会直接 return currentPromise，不会再进入 throttledRef.current(...)。这样 lodash throttle 收不到这次调用，trailing 触发就被绕过去了。例如默认节流语义下（leading: true, trailing: true）： runAsync(1) 立即执行 50ms 内再调用 runAsync(2) 预期应该在节流窗口结束后再触发一次 trailing 调用但现在第二次调用直接复用旧 Promise，没有进入 throttle，最终只会执行第一次所以这个改动虽然修复了 #2898 的场景，但会破坏 trailing: true（以及依赖“最后一次参数”的场景）。我建议：保留 useRequestImplement.ts 里把 runAsync 改成箭头函数转发的修复不要在 throttle 窗口内直接短路掉对 throttledRef.current 的调用另外补几个 runAsync 用例覆盖： leading: true, trailing: true leading: false, trailing: true trailing 场景下是否使用最后一次调用参数这样能更稳地验证修复没有引入新的节流回归。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

fix(useRequest): runAsync not working with throttle options

d788eab

- Changed runAsync binding from .bind() to arrow function for dynamic lookup - Added unit tests for runAsync with throttle configuration - Fixes alibaba#2898

meet-student requested a review from crazylxr January 25, 2026 15:34

feat: temp

4e863be

crazylxr requested a review from Copilot March 28, 2026 14:53

Copilot started reviewing on behalf of crazylxr March 28, 2026 14:53 View session

Copilot AI reviewed Mar 28, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(useRequest): 修复runAsync在节流状态下不生效的问题#2899

fix(useRequest): 修复runAsync在节流状态下不生效的问题#2899
Arktomson wants to merge 2 commits intoalibaba:masterfrom
Arktomson:fix/issue-2898

Arktomson commented Jan 25, 2026 •

edited

Loading

Uh oh!

pkg-pr-new bot commented Jan 25, 2026 •

edited

Loading

Uh oh!

whatwg6 commented Jan 27, 2026

Uh oh!

Arktomson commented Feb 5, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Mar 28, 2026

Uh oh!

Copilot AI Mar 28, 2026

Uh oh!

Copilot AI Mar 28, 2026

Uh oh!

crazylxr commented Mar 28, 2026

Uh oh!

Arktomson commented Mar 28, 2026 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

Arktomson commented Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🤔 这个变动的性质是？

🔗 相关 Issue

💡 需求背景和解决方案

Uh oh!

pkg-pr-new bot commented Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

whatwg6 commented Jan 27, 2026

Uh oh!

Arktomson commented Feb 5, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Mar 28, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 28, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 28, 2026

Choose a reason for hiding this comment

Uh oh!

crazylxr commented Mar 28, 2026

Uh oh!

Arktomson commented Mar 28, 2026 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Arktomson commented Jan 25, 2026 •

edited

Loading

pkg-pr-new bot commented Jan 25, 2026 •

edited

Loading