debounceTime with max time (if never ends)

[infacto]

I wonder if and how it is possible to have a debounce time of 1 second, which triggers after e.g. 10 seconds if the debounce never ends. Maybe a combination with throttleTime or auditTime?

Let me explain this with an example of an automatic save system that you may know from games (auto-save).
The player is collecting coins and I want to save this progress, but not on every coin. I want to wait at minimum 1 seconds. The debouceTime works great here. But I also want to guarantee a save after 10 seconds in case the debouceTime never ends. When the player collects coins within 1 second (debounce) and keeping this behavior over 10 seconds or 5 minutes whatever... The debouceTime will never end and the progress will never be saved. Just a fictitious example. I just want to make sure there is at least one save after a certain amount of time. If the player stops before the timeout of 10s the debounceTime triggers, saves the game and the timeout time 10s should not be triggered. Only trigger the timerout of the debounce never ends.

I'm not sure if this is already possible with rxjs only. Otherwise I would propose an argument to debounceTime which handles the max/timeout time. Note: With timeout I don't mean to throw error. It's just the time who trigger when the deboucer never ends. But ensure what there is only one trigger emitted. Either from debouce or timeout but never both. You know what I mean?

I could use throttleTime (trailing) or auditTime. But I don't want to save every e.g. 1 second or after 10 seconds. I want to save directly (1s) after action ends or at least after a longer time (10s) if the debouce never stops (e.g. in a loop). And if the debouceTime ends, the timeout time should not trigger and vice versa.

A spontaneous idea would be creating two subjects. One with debounce and the other with a longer audit time. And when trigger save system check the last save time (delta) maybe with a mutex. Not sure, I just wonder if there is an elegant way with rxjs.

[voliva]

Nice challenge 😄

I think I would just do it with const dounbeceWithMax = (debounceMs, maxMs) => new Observable(() => ...), but I think I managed to do it with RxJS operators:

const debounceWithMaximum = <T>(debounceMs: number, maximumMs: number) =>
  connect<T, Observable<T>>((shared$) => {
    const complete$ = concat(shared$.pipe(ignoreElements()), of(null));
    return merge(
      shared$.pipe(debounceTime(debounceMs)),
      shared$.pipe(delay(maximumMs)) // Initially throttleTime(trailing), but can be simplified to just delay.
    ).pipe(take(1), repeat(), takeUntil(complete$));
  });

Playground: https://stackblitz.com/edit/rxjs-musrsj?file=index.html,index.ts

Reasoning behind it:

1. Use connect because we'll have to subscribe multiple times to the source, and this will share it.
2. We need debounceTime for the debounce effect, but also a throttleTime(trailing) to put the maximum limit.
3. Merging these observables straight away works, but then how do we filter the emission that comes from each branch, and how do we reschedule them?
4. The answer I've found is to use this combination of take(1), repeat(). This will just restart both branches as soon as any one of them emits. So the maximum limit on throttleTime resets back to 0 and won't emit whatever had in queue, and same for the debounceTime
5. throttleTime then can be simplified to a delay, because we're taking(1) so we only care about the first one.
6. The only problem now is that if the source completes, repeat() will resubscribe to it, and we don't want that.
7. So we can add a takeUntil that will complete when the source completes.

I'm not sure this can have any bugs in it, and it's hard to think and reason about it. That's why I would probably just use new Observable( and go with plain imperative code.

[infacto]

You nailed it! Not tested in the app yet but seems to work well in the playground. It's exactly what I was looking for. Thanks a lot! 👍