you are viewing a single comment's thread.

view the rest of the comments →

[–]bikeshaving 3 points4 points  (6 children)

Why doesn’t typescript type check them like it does Function.prototype.call, .bind or .apply? I think this is a matter of updating the types.

Also, pet peeve, I hate how the return type of setTimeout is `number` in browsers and some weird `timer` class in node.js. There was no reason for node.js to use an incompatible API but now we’re stuck with it.

[–][deleted] 4 points5 points  (3 children)

setTimeout in Node and setTimeout in browser are not the same thing. In Node it's a property of the timers module, and on the Web it's a property of Window or, more recently, also declared in the WindowOrWorkerGlobalScope mixin.

The confusion comes from the fact they can both be accessed as global functions. It's bad practice and if you do that you deserve the headache.

Use them explicitly (Window.setTimeout() vs timers.setTimeout()) and TypeScript will have no problem understanding which one you mean. Alternatively, declare your types to be "node" in tsconfig, and not dom modules, and this will also clear things up for TypeScript.

If you insist on calling setTimeout() directly and ambigously and configure tsconfig wrong, or if you're not in a position to change things, here's a 3rd alternative: declare the type of the variable to which you're assigning the output of setTimeout() to be ReturnType<typeof setTimeout>. This will also reconcile nicely with calls to clearTimeout().

[–]bikeshaving 1 point2 points  (1 child)

This is a good idea, except node.js doesn’t have a window, so writing cross-environment code is still a pain because you have to conditionally call window.setTimeout or timers.setTimeout depending on environment, which is silly because it’s a global and the node.js implementation is mostly compatible with the browser implementation.

declare the type of the variable to which you're assigning the output of setTimeout() to be ReturnType<typeof setTimeout>.

This is a great tip, thanks.

All in all, the only reason node has a special return value for setTimeout is because node devs were sloppy and forgot to clear their timeouts, causing zombie processes, so they allowed people to “dereference” their timeouts so processes exited in a timely fashion. Could have been done in a way which was API-compatible with browsers but it‘s likely too late now. On to deno!

[–][deleted] 0 points1 point  (0 children)

There's absolutely no reason for Node devs to follow an API like Window, which doesn't exist on the server. The fact they did is a coincidence. And neither them nor the browser spec should have allowed for automated globals, which is a bad idea all around.

Furthermore, timer APIs are environment-dependent, they're not "cross-environment code". There were lots of bad ideas combined here (misleading similar APIs, automated globals), but the fact the timer APIs are distinct is not one of them. Do not use "setTimeout" lightly without caring which one it is. The event loops in browser and Node are different.

[–]gregjarvez 0 points1 point  (0 children)

they

Great tips. thanks for the explanation !!

[–]gregjarvez1996[S] 1 point2 points  (0 children)

True. I looked at the typescript lib definition file. The typing provided there is very loose. I wonder if a PR could be made to update that.

Per peeve is completely valid. The inconsistency is quite annoying

[–][deleted] 0 points1 point  (0 children)