Debounce repeats last emission at completion

Debounce operator emits last value at completion, even though no event is delayed.

This is apparently due to the timer not being reset after firing: https://github.com/cujojs/most/blob/a88c3169d231bcfe6f780cbd1db94b3b304ff284/src/combinator/limit.js#L92

On call to end, this is interpreted as a pending event.

Expected result

Once a debounced event has fired, it should not fire on stream completion.

Actual Result

See codepen: https://codepen.io/corolla/pen/XVwGQY?editors=1012#0

Notice ‘foo’ outputted twice indicating emission on stream completion.

Versions

• most.js: 1.7.2
• Chrome 63

Steps to reproduce

Run code, observe foo emitting twice.

Code to reproduce

most
  .never()
  .startWith('foo')
  .until(most.of().delay(1000))
  .debounce(100)
  .subscribe({
    next: console.log,
    complete: () => console.log('complete')
});

[briancavalier]

@rhartvig Cool, glad that works for you 👍

Yeah, I debated something similar, too. I’ll try to explain why I went with the current approach. The value stored in DebounceSink is mutable, and tracks the latest seen value, and the one stored in DebounceTask is immutable and represents the pending debounce value. The use case of the former is only for end, and the use case for the latter is to implement the actual debounce functionality. Those are subtly different intents, and I thought keeping them separate might be better.

That said, I think your idea is interesting. I hadn’t considered invoking the task manually. I’ll give it a bit more thought today.

In the meantime, I think we’ll release this as is, to get the bug fix out. If we decided to change the implementation, we can do that in another release.

[briancavalier]

Wouldn’t that happen as part of run() -> _event() -> _clearTimer() => timer.dispose() ?

Aha! Yes, you’re right. Thanks.