Hardcoding this to always use the global setTimeout is problematic. In most unit testing frameworks, there's no way to programmatically skip forward to the execution time - we'd have to also setTimeout in the tests.

Proposal: allow debounce method to take in an object containing the settings, as it's starting to accept quite a few. What if we want to specify wait and setTimeout but not immediate?

Hi,

Using this package or throttle I have done some tests in Firefox and I have noticed using either package (yours or theirs) for throttling or debouncing a window.onscroll function is worse then just allowing the function to run on every pixel scroll.

I wouldnt have thought this because i thought the debounce would prevent any operations from happening but it seems the operations the debounce does to debounce operations from happening is more expensive then the operations just happening.

It seems in firefox on every metric they measure says using debounce or throttle for onscroll is worse for performance.

Does anyone have anything to weigh in on this?
I am not a performance measuring pro.

can not call my func right now, at first time?

react use measure is depended on debounce. I got error during the compile time.

 snowpack failed to load node_modules/react-use-measure/dist/web.js
  'debounce' is not exported by node_modules/debounce/index.js, imported by node_modules/react-use-measure/dist/web.js

As this module works now, it violates ES6/ES2015-style module export rules. See this SO question and answer for why TypeScript cares and this bug on DefinitelyTyped for additional reasoning why it's inconvenient to users.

To not break the existing const debounce = require("debounce"); for users, I propose the object be given a .debounce member so we can also import it using const { debounce } = require("debounce"); (or var debounce = require("debounce").debounce; for the traditional folks).

I would like my debounced function to execute on the next frame update.
See https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame

A good polyfill for browsers/node environments:
https://www.npmjs.com/package/raf

This is a very common problem with debounced API calls: when the user closes the browser tab, the debounced function may not have run yet. This is a frequent cause of data loss. The _.debounce() function should avoid this issue by running the trailing debounce immediately if the tab is closed prior to the trailing timeout. This should only happen while running inside a browser because it's not relevant in headless runtimes (e.g. Node.js).

debounce is an async function by definition and it doesn't have a callback or any sort of completion handler. This makes it hard to test and use with promises or any I/O.

We should at at least return a promise.

debounce(mything, 100)()
  .then(() => console.log('done after 1s!'))

This is not a breaking change even. Phase two would be to just proxy what mything returns through the promise chain and being able to .catch

debounce(mything, 100)()
  .then(() => console.log('done after 1s!'))
  .catch((err) => console.log('failed after 1s!: %s', err.message))

where

function mything() {
  return Promise.resolve('something')
}

Due to how date-now gets a reference to the Date.now function at initialization time, it cannot be overridden when using jasmine.clock().install(). It works with module level mocking, but sometimes that's a bit of an overkill.

I think the wrapped function should have a clear method attached to clear any scheduled debounce:

var debounced = debounce(fn, 300);

debounced();
debounced();
debounced.clear();

This module really needs proper tests. I see mocha being installed but it's not used anywhere and test.html can barely be classified as a test.

npm lists version 1.0.0 and github has 1.0.1

I've seen people use debounce to do this:

function MyClass() {}

MyClass.prototype.debounced = debounce(function () {
 // ...
});

This can lead to really confusing problems if they create multiple instances of MyClass.

In this case:

var c1 = new MyClass();
var c2 = new MyClass();

c1.debounced('a');
c2.debounced('b');

This leads to the method only ever being called on c2 with arguments "b". It is almost certainly not what the user intended.

I think it's fairly easy to catch that misuse here: index.js#L41

I think the solution is to compare context to previously set values. If it changes, then throw

if (context && this !== context) {
  // If people feel an Error is to strong, maybe just log a warning?
  throw new Error('debounced method called with different contexts');
}

Happy to create a PR if anyone is still maintaining this.

Summary

👋 Hi there! I've noticed that calling a debounced function from itself sets its arguments to undefined.

Minimal working example

debounce = require('debounce');

const func = debounce((x) => {
  console.log(x);
  func(2);
}, 1000);

func(1);

Actual output

1
undefined
undefined
undefined
// ...

Expected output

1
2
2
2
// ...

Workaround

As a temporary workaround, I can defer the call:

  setTimeout(() => func(2));

Cause

https://github.com/component/debounce/blob/master/index.js#L27-L28

result = func.apply(context, args); // calls debounced function, which sets args
context = args = null; // args gets reset here

Hey guys

I have a debounced function that sometimes executes the debounced function early (before fully waiting). I am calling the debounced function many times a second and was thinking maybe one reason it was executing early was because if the debounced function was called twice within the same millisecond, this line would execute the debounced function.

Is this a possible explanation? What is the rationale behind the last > 0 condition on the if statement on that line?

Thanks!

Bob