回复: Promise.finally not really final

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

回复: Promise.finally not really final

Jack Lu
Adding to a promise chain in the next frame is not uncommon. For instance, you may want to chain a procedure conditionally by some condition calculated against some data in indexeddb, where you cannot complete in the current tick(all indexeddb operations are async). There're more use cases when you are developing a library. It's true that most usages of promises is 'static', but promise is not limited to it. It can be used more dynamically.
For your use case, think of your target as to provide a destroy method with part of it injectable. You can just pass the code you want to inject in as a parameter, or give it a field to config. It's not so relevant to whether Promise.finally is really finally, because it cannot be done directly in traditional try..finally, either.


------------------ 原始邮件 ------------------
发件人: "Jon Ronnenberg"<[hidden email]>;
发送时间: 2018年9月8日(星期六) 上午8:51
收件人: "Augusto Moura"<[hidden email]>;
抄送: "es-discuss"<[hidden email]>;
主题: Re: Promise.finally not really final

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, <[hidden email]> 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
<[hidden email]> 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&amp;flags=gated
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss