4 ms·
In the repeater callback, you're both calling the stop argument and awaiting it. Is it somehow both a function and a promise? Is this possible in JS? edit: I f
by pcthrowaway 8mo ago
In the repeater callback, you're both calling the stop argument and awaiting it. Is it somehow both a function and a promise? Is this possible in JS?
edit: I found where stop is created[1]. I can't say I've seen this pattern before, and the traditionalist in me wants to dislike the API for contradicting conventions, but I'm wondering if this was designed carefully for ergonomic benefits that outweigh the cost of violating conventions. Or if this was just toy code to try out new patterns, which is totally legit also
[1]: https://github.com/repeaterjs/repeater/blob/638a53f2729f5197875ec12a9d578c274c5f6709/packages/repeater/src/repeater.ts#L446-L455 https://github.com/repeaterjs/repeater/blob/638a53f2729f5197...
- bikeshaving 8mo agoYes, the callable promise abstraction is just a bit of effort: let resolveRef; const promise = new Promise((res) => { resolveRef = res; }); const callback = (data) => { // Do work... resolveRef(data); // This "triggers" the await }; Object.assign(callback, promise); There’s a real performance cost to awaiting a fake Promise though, like `await regularPromise` bypasses the actual thenable stuff.
- sheept 8mo agoIt's not common, but there are web APIs where you await a promise that already exists as a property, rather than being returned from a function call, like await document.fonts.ready device.lost.then(() => { console.log('WebGPU device lost :(') }) I feel like this isn't confusing if you know how promises work, but maybe it can be confusing for someone coming from Python/Rust, where async functions don't evaluate until their futures are awaited.