Last 12 weeks · 0 commits
4 of 6 standards met
Repository: sindresorhus/p-throttle. Description: Throttle promise-returning & async functions Stars: 513, Forks: 33. Primary language: JavaScript. Languages: JavaScript (97.9%), TypeScript (2.1%). License: MIT. Latest release: v8.1.0 (3mo ago). Open PRs: 0, open issues: 0. Last activity: 3mo ago. Community health: 85%. Top contributors: sindresorhus, Richienb, dormeiri, BendingBender, SamVerschueren, schinkowitch, darcyparker, edy, TehShrike, mvila and others.
Continuing #2, I am concerned with the simple scenario where the rate at which executions are being made exceeds the rate at which they are resolved due to the throttling config. This time, the concern is not around memory exhaustion, but around the ever-growing delay in executing the next call being made. Using the function is a way to deal with this situation, with two drawbacks as I see them: it is hard to employ this 'flushing' with precision. For example, periodically checking the throttler to see how many pending executions are there, 'flushing' only several of them, choosing whether to 'flush' by FIFO or LIFO, etc. when pending executions are aborted, they reject with an . I'd love to have an option to have aborted executions resolve with a value that depends on the execution arguments. As a solution, I'm basically thinking of adding a way to peek into the throttledFn object, and extending the function with the following argument: Would appreciate feedback on relevance, direction, and anything else.