API about await-timeout HOT 8 CLOSED

Calling set() internally calls clear() for previous timers:

const timer = new Timeout();
timer.set(1000);
timer.set(100); // timer for 1000 cleared and new timer for 100 set
timer.clear(); // timer for 100 cleared

from await-timeout.

Hi @benjamingr!
As Timeout.set(1000) should return promise (not actually timer as setTimeout does) it looks a bit tricky how to make a fully similar api.

from await-timeout.

@vitalets hey, you can do something like

class Timeout {
  static #items = new WeakMap();
  static set(ms) {
    let id;
    const timeout = new Promise(resolve => id = setTimeout(resolve, ms));
    Timeout.#items.set(timeout, id);
    return timeout;
  }
  static clear(timeout) {
    const id = Timeout.#items.get(timeout);
    clearTimeout(id);
  }
}

const timeout = Timeout.set(100); // returns the promise
timeout.then(() => console.log('hi'));
Timeout.clear(timeout); // clears the timeout

The caveat here is that chaining the promise won't preserve the timeout - this can be made to work but it's hard to do so without full blown cancellation and likely we shouldn't - you can guarantee the return type with TypeScript or warn on non-timers passed to clear.

It would also be nice to consider supporting AbortController which would allow the API to be web compatible (cancelling a timer and a fetch at the same time for instance):

const controller = new AbortController()
const timer = Timeout.set(1000, { signal: controller.signal });
signal.abort();

from await-timeout.

The caveat here is that chaining the promise won't preserve the timeout

This is the key point 👍
Could you show the original code that you try to optimize?

It would also be nice to consider supporting AbortController which would allow the API to be web compatible.

Nice idea! Created #4

from await-timeout.

Could you show the original code that you try to optimize?

What do you mean? I just found it surprising that new Timeout() required a separate set mutating step so that we can cancel it:

const timer = new Timeout(); // this doesn't actually create a timeout, it creates a timer
timer.set(1000) // this creates the timeout and starts the timer and returns a promise
timer.clear(); // this clears the timer

Rather than:

const timer = Timeout.set(1000); // creates the timer and starts it, no "unstarted timers"
Timeout.clear(timer); // static because I dislike patching promises, but can also be non-static

from await-timeout.

Yep!
For me the first variant is more clear - you explicitly define where is timer (for timeout manipulation) and where is promise (for app logic):

const timer = new Timeout();
const promise = timer.set(1000);

Merging timer and promise into single variable saves one line of code but adds a complexity imho.

from await-timeout.

const timer = new Timeout();
timer.set(1000);
timer.set(100);
timer.clear(); 

Were two timers set or one? Does clear clear both timers or just one? Does the second set remove the first one?

from await-timeout.

Thanks,

I'm basically saying that the way the API works doesn't make this particularly clear since creation and initialization are two separate processes. This is unlike the Timeout.set static API where it's clear that creating a timeout and setting it is done in one step.

from await-timeout.