什么时候不用承诺

Question

在阅读了数十篇关于es6承诺是多么伟大以及为什么我们应该实现它们的文章之后，我觉得我的所有(非平凡的) javascript函数都应该是承诺。

事实上，在使用它们编写代码时，我感觉很棒，因为我避免了命运多端的三角形，而且似乎得到了清晰而简洁的代码。(它确实使关于执行的推理变得更加简单)。

我没能找到的是:你什么时候不使用承诺？我什么时候才能避免使用它们？

更新：

虽然我看到了一些伟大的观点，如API一致性，但我还没有找到一个坚实的，没有的情况。Lux的回答是，获取事件发射器的操作应该避免它们，因为重复的回调与承诺不兼容。不过，我确实觉得答案仍然缺乏实质内容来检验(作为正确的)现在。

Answer 1

一些经验法则：

1. 当您的方法可以是同步的(简单的数据转换)，然后在该方法中使用同步代码。 但是，如果方法有时是同步的，有时是异步的(基于内部或外部状态的多个代码路径)，则应该是异步(始终是)。否则，您可能会遇到在复杂场景中代码行为方式的意外微妙差异，所以最好避免将这两种态度混合在一起。 正如注释中所指出的，当您的方法目前是同步的，但是您强烈认为它可能需要在将来的某个时间点执行异步工作时，您可能希望从一开始就使用承诺来避免代价高昂的重构。
2. 一般来说，您的API应该是一致的，所以最好要么到处使用承诺，要么到处回调。这将使对代码的推理变得更容易。
3. 如果您正在编写超高性能代码和/或需要较低的内存占用，您可以考虑不使用承诺，而是使用回调，或者使用以性能为重点的承诺库(如蓝鸟 )，而不是使用本机承诺实现/通用用例填充。
4. 不管怎么说，新增加的网页平台，如全球获取功能，返回一个Promise，似乎在即将到来的未来越来越多的浏览器内置将运行的承诺。因此，如果您愿意编写现代代码，您就不会逃避承诺。

Answer 2

您可以对一次性异步操作使用承诺。启动操作，执行操作，将完成或结果或错误通知来电者，然后做好。

在情况下，不使用承诺的情况与上面描述的不同：

1. 当您的操作或函数是时，完全同步的。将异步API (即使有承诺)放在同步操作上，只会使事情变得比需要复杂。
2. 代替可以多次发生的事件。例如，您不会对按钮单击处理程序使用承诺。eventEmitter或其他类似事件的结构仍然是循环事件的更好结构。
3. 当您遇到回调时，回调是，设计为多次调用(例如报告进度或通过回调提供插件服务)。
4. 如果要向已经设计好的API中添加一个新操作(例如，使用传统回调)和API一致性，则需要。
5. 如果针对的是那些本机不支持承诺的旧环境(比如旧浏览器)，并且您试图优化代码的下载大小，并且您只执行一两次异步操作，并且您没有使用类似于jQuery或like之类的东西，而这些承诺已经包含了一种形式的承诺--您可以直接使用。如果您正在做大量的异步工作，那么它可能是值得使用的承诺多边形填充，因此，这一点只适用于规模非常重要，而且异步工作很少的情况。
6. 对于操作经常未完成或发生的情况，。承诺是一个具有状态的对象，因此会消耗一些内存。创建数千个承诺来得到许多通常不会发生的不同事情的通知是没有意义的，因为这将创建成千上万个承诺对象(通常是伴随的闭包)，这些对象通常永远不会被使用。这只是内存使用效率低下，最好是通过某种类型的事件通知来提供。正如我前面所说的，当您启动操作、执行操作、将结果或错误通知调用者时，承诺最有效。

Answer 3

好的，承诺只有一个用例:异步结果只出现一次。

如果可以同步返回结果，则不使用承诺，而且仍然需要事件回调，因为事件可能会多次发生。