Promise.finally not really final

Jon Ronnenberg jon.ronnenberg at gmail.com
Sat Sep 8 00:51:48 UTC 2018


> Why would you destroy a node and `.then()` pause it? It doesn't make
sense even in plain English. If the contract of the method (expected
behavior) is to destroy the internal node, using it after is a error.

The use case is a situation I am currently in, where I have a destroy
function that is the same for 10 classes and I can not remove their DOM
nodes myself because they are in an iframe and I'm coding against a black
box API (proprietary).

Sometimes the removal fail or the DOM node is not removed due to
performance optimization, not sure but my code needs to run regardless and
updates to their API will happen long after I leave this project.

The symptom is that I can still hear the sound of video/audio, after it
should have been removed.
 A few classes dealing with video and audio could add a `this.node.pause()`
to the promise chain without changing the destroy trait or any other non
audible dealing class.

There is many ways to implement this and I thought Promises would be an
elegant implementation but since `finally` is called before `then`, even in
the same call stack, a Promise is not useful.

I've never had a use for adding to a promise chain in the next frame, which
is the main argument against calling finally at the end, so I might be the
wrong audience.

I have demonstrated how it could work and I think it makes better sense but
I'm not up for a fight to defend my way.

On Sat, 8 Sep 2018 01:18 Augusto Moura, <augusto.borgesm at gmail.com> wrote:

> Why would you destroy a node and `.then()` pause it? It doesn't make
> sense even in plain English. If the contract of the method (expected
> behavior) is to destroy the internal node, using it after is a error.
> You can easily reimplement your use case reversing the logic:
>
> ```` js
> setTimeout(() => {
>   demo.node.pause();
>   demo.destroy();
> }, 3000);
> ````
>
> Another solution is to implement a `beforeDestroy` event emitter and
> listen to it, this way is certain that the code will be executed
> always before the node is gone and after any async destroy logic:
>
> ```` js
> class Demo {
>   constructor(el) {
>     this.beforeDestroy = new EventEmitter();
>     // Using the @angular/core EventEmitter because is more "close to
> English"
>     this.node = el;
>   }
>   destroy() {
>     return new Promise(resolve => resolve())
>       .then(() => this.beforeDestroy.emit())
>       .finally(() => {
>         this.node = null;
>       });
>   }
> }
>
> const demo = new Demo(document.querySelector('video'));
>
> demo.beforeDestroy.subscribe(() => {
>   demo.node.pause();
> });
>
> setTimeout(() => {
>   demo.destroy();
> }, 3000);
> ````
>
> Anyway, the `then`, `catch` and `finally` methods mimic the serial
> try/catch/finally, simply doesn't make sense finally statements
> protecting code beyond it's try block definition, and chaining new
> `.then`s _are_ beyond the promise definition. Also, async functions
> already has finally blocks implementations in the same way as the
> current `.finally` method spec, implementing a different behaviour
> would be unnecessarily confusing.
> Em sex, 7 de set de 2018 às 16:16, Jon Ronnenberg
> <jon.ronnenberg at gmail.com> escreveu:
> >
> > I know I am late to the game and that Promise.prototype.finally is
> already in stage 4 but(!).
> >
> > It's just not very useful to have a final function when it's not the
> final function to run. If it's suppose to be for cleanup, then the current
> implementation is seriously lacking usefulness.
> >
> > Consider the following example:
> >
> > <audio
> >   class="i-am-the-element"
> >   autoplay="autoplay"
> >   controls="controls">
> >     <source type="audio/mp3" src="http:\/\/play.dogmazic.net
> \/play\/index.php?type=song&oid=22951&uid=-1&name=Black%20poetry%20-%20Aime-.mp3">
> > </audio>
> > <script>
> >   class Demo {
> >     constructor (element) {
> >       this.node = element
> >     }
> >     destroy () {
> >       return new Promise(resolve => {
> >         // do something or nothing
> >         resolve()
> >       }).finally(() => {
> >         // schedule for DOM removal
> >         this.node = null
> >       })
> >     }
> >   }
> >
> >   const demo = new Demo(document.querySelector('.i-am-the-element'))
> >
> >   setTimeout(() => {
> >     demo.destroy().then(() => {
> >    // will throw an error because finally was run before
> >       demo.node.pause()
> >     }).catch(console.error)
> >   }, 3000)
> > </script>
> >
> > One grand idea about promises is to delegate and compose asynchronous
> functions, but the current implementation can not be used to for code
> delegation.
> >
> > From the top of my head the only way to have consumer code,  tap into an
> execution process is to use callbacks which is what Promises were suppose
> to help alleviate.
> >
> > <audio
> >   class="i-am-the-element"
> >   autoplay="autoplay"
> >   controls="controls">
> >     <source type="audio/mp3" src="http:\/\/play.dogmazic.net
> \/play\/index.php?type=song&oid=22951&uid=-1&name=Black%20poetry%20-%20Aime-.mp3">
> > </audio>
> > <script>
> >   class Demo {
> >     constructor (element) {
> >       this.node = element
> >     }
> >     destroy (callback) {
> >       // do something or nothing
> >       try {
> >         callback()
> >       } finally {
> >         // schedule for DOM removal
> >         this.node = null
> >       }
> >     }
> >   }
> >
> >   const demo = new Demo(document.querySelector('.i-am-the-element'))
> >
> >   setTimeout(() => {
> >     demo.destroy(() => {
> >       demo.node.pause()
> >     })
> >   }, 3000)
> > </script>
> >
> > If at all possible, please amend to the spec before it's too late! ...
> or just drop it.
> >
> > My current use-case is that I work with PSPDFKit and can not get DOM
> access but rather schedule removal of DOM nodes via their API, but I can
> pause audio/video - just not using Promise.prototype.finally as it is
> currently envisioned.
> >
> > Regards, Jon
> >
> > PS. Tested in Firefox 63.0b3 and Safari 11.1.2
> > Here is a polyfill if you need:
> https://cdn.polyfill.io/v2/polyfill.minify.js?features=Promise.prototype.finally&flags=gated
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180908/2592ccc7/attachment-0001.html>


More information about the es-discuss mailing list