"non-missable" events, or multi-promises
There seem to be an interesting section in Promises doc from 2001 about
multi-state promises -
https://www.w3.org/2001/tag/doc/promises-guide#state-transitions
One of the things that we are working on is a spec for loading localization
resources into HTML, which resembles the example from this chapter.
I was thinking about something like:
linkElement.ready((resource) => {
console.log(resource.text());
});
and make when the language changes, I'd update the url in the link and the
callback would get called again when its loaded.
Is there any evolution of that proposal?
What's the current thinking about solving such cases?
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: "non-missable" events, or multi-promises
On 09/22/2015 09:49 AM, Zibi Braniecki wrote:
There seem to be an interesting section in Promises doc from 2001 about
multi-state promises -
https://www.w3.org/2001/tag/doc/promises-guide#state-transitions
That document is from 2015 ;)
One of the things that we are working on is a spec for loading localization
resources into HTML, which resembles the example from this chapter.
I was thinking about something like:
linkElement.ready((resource) => {
console.log(resource.text());
});
and make when the language changes, I'd update the url in the link and the
callback would get called again when its loaded.
The example in that chapter is "This property should return the same promise every time it is retrieved, until the image moves backward from the
loaded state into the unloaded state. Once that occurs, a new promise is created, representing the next transition to loaded."
So a new promise would be created.
Is there any evolution of that proposal?
What's the current thinking about solving such cases?
Why not use events for that? There is nothing wrong with events , and
https://www.w3.org/2001/tag/doc/promises-guide#when-not-to-use
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: "non-missable" events, or multi-promises
On Tuesday, September 22, 2015 at 3:02:21 AM UTC-7, smaug wrote: > That document is from 2015 ;) Oh. Fun! > The example in that chapter is "This property should return the same promise > every time it is retrieved, until the image moves backward from the > loaded state into the unloaded state. Once that occurs, a new promise is > created, representing the next transition to loaded." > So a new promise would be created. Oh, ok. So it's basically not the API I'm looking for :( > Why not use events for that? There is nothing wrong with events , and > https://www.w3.org/2001/tag/doc/promises-guide#when-not-to-use Events are missable. That means that writing async/lib code where you have to be ready to be executed at any point requires the following code: 1) Check if the target is in the fulfilled state 2) If yes, apply logic 3) Set up event listener With a Promise its: 1) Set a promise on the target and either: 2a) In the promise callback, set event listener, but only if it's not set yet or: 2b) Set an event listener now, but guard against double executing when event listener and promise are fulfilled at the same time. This sort of repeatable-promise, would reduce it to: 1) Set the repeatable promise on the target Sounds like it would make much easier to write async code without logic for preventing race conditions. Is there any other approach to that? zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: "non-missable" events, or multi-promises
On Tue, Sep 22, 2015 at 4:50 PM, Zibi Braniecki
wrote:
> This sort of repeatable-promise, would reduce it to:
> 1) Set the repeatable promise on the target
>
> Sounds like it would make much easier to write async code without logic for
> preventing race conditions.
>
> Is there any other approach to that?
I think it best to just consider promises async program flow: it
completes or errors out. A repeatable promise concept does not seem to
have an analogy with sync program flow (maybe checkpointing a line in
a piece of code and re-winding it to run again?), so I would be more
hesitant to try to fit that into a promise model.
In gaia email, we have an event library[1] that has an
"emitWhenListener" method, so the code that does the emit of the event
can do so via that method, and then when the first event listener
listens for that particular event name, it gets that previously
emitted event. This is only useful if we know there is likely just one
event listener and there may be a race between the emitter and the
listener.
There is also a concept of "latest" in the event library:
evt.latest('foo', function(event){}) will be called when there is a
'foo', and if there is an existing one, called right away, and for
future changes to a 'foo'. This approach works well for multiple
listeners that may be dealing with something that could already have
an existing state.
Maybe the conceptual models in that library could be refined, but they
sound related to what you are asking.
For async concepts, gtor[2] might be an interesting read, but I say
that not having fully grokked the fullness of gtor, and perhaps if I
did it would contradict some of the above.
James
[1] https://github.com/jrburke/evt - light on docs, tests might be the
most instructive.
[2] https://github.com/kriskowal/gtor/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
