RE: [futures] Persistent/Repeated Future that doesn't resolve

I think this isn't a great use case for promises. Indeed, I don't think progress in general is a good use case for promises: it doesn't fit the sync/async function call parallel that they try to model.

Rather, what you're looking for is probably something more like an event stream, from functional reactive programming. The more interesting implementations of these that I have seen include [RxJS][] and [Dart's stream API][]. There is some hope of getting something like this in the DOM, and having use cases like this are very helpful toward that work, but I don't think any ideas have gelled yet into something usable. It's very tricky to get right.

Finally, just as an incidental point of terminology, it's important to note that a promise can be "resolved" but never become fulfilled or rejected. (Or accepted/rejected, using DOM Future terminology.) This would simply occur by resolving a promise to a forever-pending promise, e.g.

```js
var foreverPending = new Future(() =>);
var resolvedButAlsoForeverPending = new Future(({ resolve }) => resolve(foreverPending));
```

[RxJS]: https://github.com/Reactive-Extensions/RxJS

[Dart's stream API]: http://www.dartlang.org/articles/feet-wet-streams/


> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Thursday, April 11, 2013 19:24
> To: www-dom@w3.org
> Subject: [futures] Persistent/Repeated Future that doesn't resolve
> 
> While redesigning the CSS Font Load Events api to use Futures, I ran into a
> case where I needed to stick with events, even though they're suboptimal
> and something more future-like would be better.
> 
> The current api proposal at
> <http://wiki.csswg.org/ideas/font-load-futures>.  Look at the
> loading/loadingdone events - these are used to allow an author to provide
> loading UI indicating to the user whether fonts are loading at any given time.
> Because font loading can start and finish multiple time across a document's
> life, this can't be done as a future currently - there's no concept of
> "resolving" to hook off of.
> However, events aren't well-suited for this either, as you can't tell what the
> "current" state of loading is at the time you register events.  Plus, while this
> exact case won't ever have errors, other similar cases may, so they'd need to
> add an error event too.
> 
> Basically, what I need is something like a ProgressFuture (after the
> "immediately ping with most recent value" change from my previous email),
> but which never completes.  That way I could just register a callback, get
> called in the next tick with the current value, and then called again every time
> the value is updated, forever.
> 
> My immediate thoughts are that maybe this can be a ProgressFuture which is
> specified to never resolve.
> 
> Another thought is to create a normal future (or a new type of future) that
> resolves multiple times.  This would let you use .then() as normal, rather than
> having to hook both .progress() and
> .then(null,...) if you want to listen for errors as well.  This might play better in
> the futures algebra, too, though it would need special handling - for the
> purpose of all other future combinators, it would act like it was initially
> unresolved and resolves the next time it receives a "progress update".
> 
> If I pretend it's something like the latter, I'd be able to tweak Font Load
> Events to have a .ready() method returning a normal Future, for running
> code whenever font loads aren't currently running, and a
> .status() method return a MultiFuture that alternates between sending
> "loading" and "loaded" progress values.
> 
> Thoughts?
> 
> ~TJ
>

Received on Friday, 12 April 2013 00:06:20 UTC