Per Can I Use [1], promises are in 74% of browsers (only current major browser not supporting them is IE11) and proxies are in 57% of browsers.
Promise is pretty easily polyfilled for older browsers; proxies are more problematic and I don't know whether or not any of the existing proxy polyfills will work with Allora.
requestAnimationFrame doesn't repeat, it only triggers the function once, you have to request an animation frame on each render to have it run again. Valid point however regarding the other things. Might be a neat api to have like a generator for these kinds of things, something like:
for click in window.document.body:
// do something with click
and then stick this in an async function?
It's not possible to fulfill a promise more than once, no.
But a Promise.all method, while outside the A+ spec, conventionally returns a promise for the resolution of all promises in the array passed as an argument; if all those promises are fulfilled, so will be the promise returned by .all, while if any of them is rejected, so will be the etc., etc.
So the browser example given in the Allora Github readme is perfectly reasonable. It's the exact same kind of thing you do when, for example, you need to await the completion of multiple separate HTTP requests in order to do something with all of their results. While, again, .all isn't part of the A+ standard, this is perfectly conventional and unremarkable behavior; not only is it unsurprising to see in a library like this one, it would be exceptional in its absence if it weren't there.
That said, I would be curious to see Allora compared with, for example, Bluebird's "promisifyAll" method, which appears to do much the same thing.
At moment it's not possible and it does not make any sense to use a setInterval with a promise in return. But I will think about a simple solution to clear the timer functions
Yes you are right, mine was just a proof of concept and it works properly for callbacks that must be triggered only once. I am working on another script to make an event streams api from native functions a bit like Bacon.js or fx.js already do but with less code
24 comments
[ 4.7 ms ] story [ 59.2 ms ] threadPromise is pretty easily polyfilled for older browsers; proxies are more problematic and I don't know whether or not any of the existing proxy polyfills will work with Allora.
[1] http://caniuse.com/
On https://www.netmarketshare.com combined IE market share is 31% and Edge is 5%.
Thus promisifying of window.setInterval() and window.requestAnimationFrame() is very questionable.
The same applies to possibly repeatable .onXXXX() methods.
https://promisesaplus.com/But a Promise.all method, while outside the A+ spec, conventionally returns a promise for the resolution of all promises in the array passed as an argument; if all those promises are fulfilled, so will be the promise returned by .all, while if any of them is rejected, so will be the etc., etc.
So the browser example given in the Allora Github readme is perfectly reasonable. It's the exact same kind of thing you do when, for example, you need to await the completion of multiple separate HTTP requests in order to do something with all of their results. While, again, .all isn't part of the A+ standard, this is perfectly conventional and unremarkable behavior; not only is it unsurprising to see in a library like this one, it would be exceptional in its absence if it weren't there.
That said, I would be curious to see Allora compared with, for example, Bluebird's "promisifyAll" method, which appears to do much the same thing.
Also, it's async/await ready: