Strange no one mentioned `Promise.race` which would do the job (ex:
https://github.com/mo/abortcontroller-polyfill/blob/master/src/abortableFetch.js#L77
)
2018-04-24 22:40 GMT+02:00 kai zhu :
> here's a simple (60 sloc), zero-dependency/zero-config, high-performance
> express-middleware for servi
here's a simple (60 sloc), zero-dependency/zero-config, high-performance
express-middleware for serving files, that can broadcast a single fs.readFile()
operation to multiple server-requests. the entire standalone program
(including emulated express-server and client-side stress-testing) is und
to be honest, I have solved already these cases through named promises and
the broadcast micro library I've mentioned.
```js
let shouldAsk = true;
function askForExpensiveTask() {
if (shouldAsk) {
shouldAsk = false;
doExpensiveThing().then(r => broadcast.that('expensive-task', r));
}
Here's a better idea: maybe `Promise.prototype.clear(promise)` and
`Promise.prototype.add(promise)` (with a parent reference to verify
its origin, of course). You can then manage "subscriptions" via just
tracking the returned chained promises if necessary. It's technically
blanket, but keep in mind
leads* to better predictability
On Tue, 24 Apr 2018, 4:44 pm Naveen Chawla, wrote:
> Having promises be non-breakable I think is an advantage. I think it least
> to better predictability without having to check if another part of the
> code may have "broken" it. So I tend to prefer callbacks exp
Having promises be non-breakable I think is an advantage. I think it least
to better predictability without having to check if another part of the
code may have "broken" it. So I tend to prefer callbacks explicitly
handling expiry in application logic, rather than allowing promises to be
permanentl
> I see a simple scenario like the following one:
> user asks for a very expensive task clicking section A
> while it's waiting for it, user changes idea clicking section B
> both section A and section B needs that very expensive async call
> drop "going to section A" info and put "go to section B"
> I see a simple scenario like the following one:
> user asks for a very expensive task clicking section A
> while it's waiting for it, user changes idea clicking section B
> both section A and section B needs that very expensive async call
> drop "going to section A" info and put "go to section B"
Based on feedback, I agree that a blanket `Promise.prototype.clear()` is a bad
idea. I don’t think that is worth pursuing.
I still think that there is value in this, especially the adding and removing
of listeners you have reference to as Andrea’s PoC shows. Listeners would
prevent the chaining
if the result is already known (resolved), Event Emitters are basically
useless though.
On Tue, Apr 24, 2018 at 11:13 AM, Ayush Gupta wrote:
> In situations like this, I personally would use Event Emitters instead of
> promises.
>
> ___
> es-discuss ma
In situations like this, I personally would use Event Emitters instead of
promises.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Mon, Apr 23, 2018 at 6:56 PM, Oliver Dunk
wrote:
>
> My proposal is that we add a way of removing a particular
> callback, or all callbacks, from a Promise.
As has been raised, this gets complicated quickly when chains come into it.
Also, what if the same function has been used in more than on
onto the actual then and catch, meaning if already resolved/rejected the
callback triggers right away ?
anyway, in case this proposal won't go anywhere, there is a module called
broadcast that would let you listen to named events, exposing a `drop`
functionality too.
Maybe that would be enough to
How can you terminate an async call? All you're doing is refusing to handle
the result. Explain how I'm wrong if so.
On Tue, 24 Apr 2018 at 13:27 Andrea Giammarchi
wrote:
> The `isStillValid` is limited in possibilities. I think listeners open
> new possibilities, specially for very complex oper
The `isStillValid` is limited in possibilities. I think listeners open new
possibilities, specially for very complex operations.
I see a simple scenario like the following one:
- user asks for a very expensive task clicking section A
- while it's waiting for it, user changes idea clicking s
> My proposal is that we add a way of removing a particular callback, or all
> callbacks, from a Promise. This is different to cancelling a Promise and
> would instead happen if you want the operation to continue but are no
> longer interested in running a function when the Promise is resolved or
>
On Mon, Apr 23, 2018 at 10:56 AM, Oliver Dunk wrote:
> My proposal is that we add a way of removing a particular callback, or all
> callbacks, from a Promise. This is different to cancelling a Promise and
> would instead happen if you want the operation to continue but are no longer
> intereste
> What happens to `p2` if I "unthen" `f` from `p1`?
That’s an interesting point to explore. I would intuitively say p2 continues to
exist, but is never resolved or rejected.
> Interesting. I have a proof of concept that would let you do this
Andrea, that’s pretty much exactly what I was thinkin
If I have `p1` and `p2 = p1.then(f)` - if I "unthen" `f` from `p2` then
it's relatively clear that it simply won't be called.
What happens to `p2` if I "unthen" `f` from `p1`?
On Mon, Apr 23, 2018 at 11:37 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Interesting. I have a proof
Interesting. I have a proof of concept that would let you do this:
```js
new Promise(res => setTimeout(res, 1000, 'OK'))
.addListeners(console.log, console.error);
```
and you could drop that listener at any time via the following test:
```js
new Promise(res => setTimeout(res, 1000, 'OK'))
.a
20 matches
Mail list logo
