Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Throttle has no option to execute conditionally at the end of the window #926

Closed
joshjordan opened this Issue · 3 comments

4 participants

@joshjordan

When using throttle (or debounce), there is no simple way to throttle in such a way that the function ignores calls during the delay period. Rather, throttle will delay execution but guarantee that it occurs. Consider the use case of renewing authentication tokens as the user takes actions on a rich page. If we wanted a large delay for this purpose, say, five minutes, we might want to do something like this:

_.throttle(renew_token, 300000)

However, if the user takes two sequential actions and then sites idle for four and a half minutes, we'll get this behavior:

1) An immediate renewal (desired)
2) A renewal five minutes later, even though the user hasn't acted recently

What I really want is to be able to say "run this function only when it is called and not in throttled mode". This was proposed in #251, but shot down after a decision was made in #170. However, as @yuchi points out, that decision was later reversed. @acidron also commented that he was looking for this behavior in that closed pull request.

@jashkenas
Owner

Sounds fine -- feel free to send a pull request that adds a third argument to throttle, similar to the current third argument to debounce.

@brysgo brysgo referenced this issue from a commit
Bryan Goldstein and David Lee Add third flag to throttle resembling debounce
[Addresses #926]
bf5c07c
@jdalton
Collaborator

I believe the patch at #1019 doesn't address this issue. The patch at #1019 addresses optionally executing immediately but not the trailing call.

@brysgo

Here are the differences in the two functions:

throttle:

  • defaults to immediate true
  • timing not affected by new calls
  • immediate true triggers on leading and falling edge, false just triggers falling

debounce:

  • defaults to immediate false
  • timing reset by new calls
  • immediate true triggers on leading, false triggers falling

It would be wonky to change the immediate flag for throttle to be consistant with which edge of the function queuing for subsequent calls occurs on. If you made the immediate flag for throttle and debounce behave the same way, the default behavior of one of them would have to change.

Its a half baked solution, but for example, if the immediate flag was ternary it could be consistant.
1) trigger leading
2) trigger both
3) trigger falling

This would change that same venn diagram to be:

throttle:

  • defaults to immediate (2)
  • timing not affected by new calls

debounce:

  • defaults to immediate (3)
  • timing reset by new calls

Problem is there does not seem to be a way to make it not confusing.

Any thoughts?

@havvg havvg referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@jashkenas jashkenas closed this in 081c9fa
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.