Closed kwonoj closed 8 years ago
Hmmm... I tell you what. Examine the level of complexity with supporting both on the same operator. If it incurs too many conditionals, we should probably seperate them into debounce
and debounceTime
It'll also works. Just curious if it was intended.. I'll try to scope out changes and create PR based on those.
Yeah... looking at this, it's probably best to rename what's there to debounceTime
and add a debounce
operator that takes an Observable as an argument. Likewise, we'll need to do this for throttle
and throttleTime
... I'll take a look at that.
What do you think @kwonoj? Do you agree?
What's interesting is, in case of throttle
it didn't had durationSelector, (https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/throttle.md)
Rx.Observable.prototype.throttle(windowDuration, [scheduler])
only. For alignment, I think it makes sense.
While trying to migrate test coverage in RxJS4, could observe difference between signature of
debounce
operatorRxJS4
while current signature only allows first one
debounce<T>(dueTime: number, scheduler: Scheduler = nextTick)
Not sure if this is intended design or not - should operator to be updated, or test coverage for latter can be dropped off?