- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Tue, 30 Sep 2014 10:36:05 -0400
- To: Harald Alvestrand <harald@alvestrand.no>, public-media-capture@w3.org
- Message-ID: <542ABFD5.6000600@mozilla.com>
On 9/30/14, 6:39 AM, Harald Alvestrand wrote: > One question on slide 16: > > function getUserMedia(constraints, success, failure) { > var p = navigator.mediaDevices.getUserMedia(constraints); > p.then(success); > p.then(failure); > } > > The pattern I've seen people use before is p.then(success, failure). > Is this somehow equivalent? Total typo, thanks for catching it! New slides attached! > I can't remember having seen what the semantics are of calling p.then > twice on the same promise - from the ES6 draft you link to: > > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.prototype.then > > > it seems to be stacking handlers on the [[PromiseFulfilReactions]] > slot, which doesn't make sense to me in this context. Right. Quite a handy feature actually, that I've used to solve onicecandidate firing before the peer is ready in WebRTC! [1] > (this feeds into a gripe I personally have with promises - every time > I try to find the actual spec, I'm lost in a twisty little maze of > proposals, all subtly different. Thanks for including the link to what > you think the current spec is!) I agree, it's the worst! Way too many people had almost the same idea. The iterations seem to have helped though., as I'm super happy with what we got in the end. In particular, I love the .catch(failure) alias for .then(null, failure), to help remind me to "terminate" queues with error handling at the very end. Also, they got rid of deferred/resolver objects which were complicated and not needed. .: Jan-Ivar :. [1] http://lists.w3.org/Archives/Public/public-webrtc/2014Sep/0063.html
Attachments
- application/pdf attachment: ModernizegUM.pdf
Received on Tuesday, 30 September 2014 14:36:36 UTC