"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