| 22:55 | <whosy> | I wonder if there's any want for a Promise.sleep( duration ). I find myself writing one-liners for this in many a project.e.g. const sleep = durationMs => new Promise( resolve => setTimeout( resolve, durationMs ) ); |
| 22:58 | <James M Snell> | I wonder if there's any want for a |
| 23:02 | <whosy> | Might I ask what And I really did mean as a simple shorthand for wrapping whatever native implementation of setTimeout is in a promise. Though I guess that does leave a big question mark about what value is returned (if any). I am very green when it comes to actual implementations and the specification side of the language, by the way. |
| 23:04 | <James M Snell> | scheduler.wait(...) is defined https://github.com/WICG/scheduling-apis ... there's more to it but it essentially allows you to do await scheduler.wait(duration) |
| 23:07 | <whosy> | Ah, I see. I couldn't find any reference to this when I tried a quick search for npm/JavaScript or the proposals listings. It's an interesting read, and would definitely encompass this use-case. |
| 23:09 | <Chris de Almeida> | I wonder if there's any want for a setTimeout is not part of JS |
| 23:12 | <Chris de Almeida> | the longer answer is that in order to get some flavor of sleep(), you would have to add various other things in the language first in order to support it |
| 23:12 | <whosy> | Yes..that's something I only considered and realised after thinking about the differing return types across implementations. As I said in the thread now, I am very much not clued in on the language spec. I've mostly just used the language without considering its development until very recently. But the lack of a spec-defined timing mechanism, I'm guessing is why the aforementioned Scheduler API is being developed? |
| 23:13 | <snek> | even if the core js language had timers, the web would still need a more complex scheduling api. you can read the details about that in the scheduling api readme |
| 23:15 | <Chris de Almeida> | I can't speak to the motivation of the folks that advanced Scheduler, but if you already have an environment where you have production-ready foundational components available, like timing, eventing, and cancellation, and that environment is the same one in which you want to have sleep(), then that seems like a faster path to that goal |
| 23:17 | <Chris de Almeida> | that doesn't mean it can't be pursued in the language, or that it's not still useful to add to the language |
| 23:20 | <bakkot> | I very much hope scheduler.wait does not become the way to do this, but it seems pretty likely unfortunately |
| 23:21 | <bakkot> | we generally try to avoid duplicating things on the web platform, so if that ships it will not be in the language probably |
| 23:23 | <whosy> | we generally try to avoid duplicating things on the web platform, so if that ships it will not be in the language probably Both of which have their own challenges and pitfalls.. |
| 23:24 | <whosy> | Or I guess option 3, create a stage-0 proposal and just ask them very nicely to drop parts of their work which..I also don't see happening. |
| 23:29 | <whosy> | I am quite possibly the least qualified person to speak of what should or shouldn't be done here though, so I actually would love to hear the opinions of veterans on the matter. |
| 23:37 | <kriskowal> | |
| 23:43 | <bakkot> | personally I would just put it at the top level namespace, named wait or something |
| 23:43 | <bakkot> | await wait(500) etc |
| 23:50 | <sirisian> | Maybe I'm blanking since I forget proposals. Has anyone suggested an operator like f??.() that is equivalent to typeof f === 'function' ? f() : f ? |
| 23:56 | <sirisian> | bakkot: await wait(Temporal.Duration.from({ milliseconds: 500 })) heh |
| 23:57 | <bakkot> | Maybe I'm blanking since I forget proposals. Has anyone suggested an operator like f??.() that is equivalent to |