什么时候不使用承诺

Question

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

事实上,在使用它们编写代码时我感觉很棒,因为我避免了厄运的三角形,看起来似乎得到了清晰简洁的代码.(它确实使执行的推理变得更加简单).

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

更新:

虽然我已经看到了一些像API一致性这样的优点,但我还没有找到一个坚实的NO案例.Lux的答案表明,获取事件发射器的操作应该避免它们,因为重复的回调与promises不兼容.但我确实觉得答案仍然缺乏实质性的检查(正确)现在.

Answer 1

一些经验法则:

1. 当您的方法可以同步(简单数据转换)时,则在该方法中使用同步代码.

   然而,如果该方法可以是同步的,有时,和异步有时(基于内部或外部状态的多个代码路径),它应该是异步始终.否则,您可能会遇到代码在复杂场景中的行为方式的意外细微差异,因此最好避免混合这两种态度.

   [edit]正如评论中所指出的,当你的方法现在是同步的,但你坚信它可能需要在将来的某个时刻进行异步工作时,你可能希望从一开始就使用promises来避免代价高昂的重构.

2. 通常,您的API应该是一致的,因此最好在任何地方使用promises,或者在任何地方使用回调.这样可以更容易地推断出代码.

3. 如果您正在编写超高性能代码和/或需要较少的内存占用,您可以考虑不使用promises而是使用回调,或使用专注于性能的promise库,如bluebird,而不是本机Promise实现/一般用例polyfill .

4. [编辑]无论如何,网络平台的新增功能,如全局获取功能,返回一个Promise,似乎在即将到来的未来,越来越多的浏览器内置插件将在promises上运行.所以如果你愿意写现代代码,你就不会逃避承诺.

Answer 2

您使用promises进行一次性异步操作.启动操作,执行操作,通知调用者完成或结果或错误,然后完成.

在那里你不使用的情况下的诺言是那些除了上述的不同:

1. 当您的操作或功能完全同步时.在同步操作上放置异步API(即使使用promises)只会使事情变得更加复杂.
2. 代替可能多次发生的事件.例如,您不会使用按钮单击处理程序的承诺.对于重复发生的事件,eventEmitter或其他类似事件的结构仍然是更好的结构.
3. 当您有一个回调情况,其中回调被设计为多次调用(例如报告进度或通过回调提供插件服务).
4. 如果您正在向已经以其他方式设计的API添加一个新操作(例如,使用传统的回调)并且需要API一致性.
5. 如果你是针对老年环境本身不支持的承诺(如旧的浏览器)和你要优化你的代码的下载大小和你只做一个或两个异步操作,而且您没有使用类似jQuery或Angular已经有一种内置的promises形式,你可以使用它.如果你正在进行任何大量的异步工作,那么很可能值得使用Promises polyfill,所以这一点仅适用于大小非常重要并且异步工作非常少的情况.
6. 对于动作通常无法完成或发生的情况.Promise是一个有状态的对象,因此消耗了一些内存.创建成千上万的promises来获取通常不会发生的许多不同的事情是没有意义的,因为这会产生成千上万的promise对象(通常带有它们随附的闭包),而这些对象绝对不会被使用.这只是低效的内存使用,并且可能通过某种事件通知更好地服务.如上所述,当您启动操作,执行操作,通知调用者结果或错误时,promise最有效.

Answer 3

Well Promises有一个用例:异步结果只有一次.

如果可以同步返回结果,则不使用Promise,并且仍需要事件回调,因为它们可能会多次出现.