@std/async `throttle` dynamically adjusted timeframe

[lionel-rowe]

Is your feature request related to a problem? Please describe.

When throttling functions, the purpose of throttling is usually to improve performance by limiting the number of times the function gets executed. However, how much to limit it for best UX often depends on how much work the function needs to carry out, which depends on input size/complexity, overall system resource usage, etc. For example, you might want to wait at least as long as the previous execution took to complete, thus ensuring the function can't monopolize more than 50% of the current thread's execution time.

Describe the solution you'd like

Change type of throttle's timeframe param to number | ((previousExecution: number) => number). If a function, it's calculated based on the previous execution time (e.g. (n) => n to wait as long as the previous execution, or (n) => n * 2 for twice as long).

Describe alternatives you've considered

How should this work with async functions? Currently, throttle doesn't do anything special with async functions at all (despite being part of the the async package) — the returned promise is simply discarded, and lastExecution is updated after the end of synchronous execution. Is there a use case for returning the promise, if available, and/or for changing lastExecution and the putative previousExecution to be based on time-to-return/resolve rather than always time-to-return?

[tomas-zijdemans]

Hmm. I'm not sure what the best way forward here is.. I'm confused, why isn't throttle aware of async? We want to measure how long a fetch takes, right? If we want dynamic timeframe (which sounds nice), shouldn't it know about async?

Maybe we need to make it async aware, and then add dynamic timeframe? (that's a redesign, so we would need to agree that that's OK ofc)