何时不使用承诺 [英] When NOT to use promises
问题描述
在阅读了数十篇关于es6承诺的伟大之处以及为什么要实现它们的文章之后，我感到我的（非平凡的）javascript函数的 ALL 应该是承诺。
After having read dozens of articles on how great es6 promises are and why we should implement them I have been left with the feeling that ALL of my (non-trivial) javascript functions should be promises.
事实上，在使用它们编写代码时，我感觉很好，因为我避免了厄运的三角形，并且看上去得到了简洁明了的代码。 （这确实使执行推理变得简单得多。）
In fact I feel great when writing code using them since I avoid the triangle of doom and seemingly get clear and concise code. (it really makes reasoning about execution much simpler).
我一直无法找到的是：您什么时候不使用诺言？ ？何时避免使用它们？
What I haven't been able to find is: When do you NOT use promises? When do I avoid using them?
更新：
诸如API一致性之类的一些优点还没有找到可靠的解决方案。 Lux的答案表明，获取事件发射器的操作应避免使用它们，因为循环回调与Promise不兼容。不过，我确实觉得答案仍然缺乏实质性检查（正确）。
While I have seen some great points like API consistency I have yet to find a solid NO case. The answer by Lux suggests that operations that fetch event emitters should avoid them since recurring callbacks are incompatible with promises. I do however feel like the answer is still lacking in substance to check it(as correct) right now.
推荐答案
一些规则thumb：
-
当您的方法可以同步（简单数据转换）时，请在该方法中使用同步代码。
When your method can be synchronous (simple data transformation), then use synchronous code in that method.
但是，如果该方法可以是同步的有时和异步的有时（基于内部或外部状态的多个代码路径），它应该是异步 始终 。否则，您可能会在代码在复杂场景中的行为上遇到意想不到的细微差异，因此最好避免将两种态度混为一谈。
However if the method can be synchronous sometimes, and asynchronous sometimes (multiple code paths based on internal or external state), it should be asynchronous always. Otherwise, you may encounter unexpected subtle discrepancies in how your code behaves in complex scenarios, so it's best to avoid mixing the two attitudes.
[edit]当您的方法暂时处于同步状态，但您强烈认为它可能将来需要在某个时刻进行异步工作时，您可能希望从一开始就使用Promise以避免昂贵的重构。
[edit] As noted in comment, when your method is synchronous for now, but you strongly believe it might need to do async work at one point in the future, you might want to use promises from the beginning to avoid costly refactoring.
通常，您的API应该保持一致，因此最好在任何地方都使用Promise，或在任何地方使用回调。
In general, your API should be consistent, so it's best to either use promises everywhere, or callbacks everywhere. This will make it easier to reason about the code.
如果要编写超高性能代码和/或需要低内存占用，则可以考虑不使用代码Promise而是回调，或使用侧重于性能的Promise库，例如 bluebird ，而不是原生Promise实施/一般用例polyfill。
If you are writing ultra high performance code and/or need low memory footprint, you may consider not using promises but callbacks, or using a promise library with a focus on performance, like bluebird, instead of the native Promise implementation / general use case polyfill.
[edit]无论如何，Web平台的新增功能，例如全局获取函数，返回 Promise ，然后似乎在即将到来的未来，越来越多的内置浏览器将实现承诺。因此，如果您愿意编写现代代码，就不会逃避诺言。
[edit] Anyway, new additions to the web platform, like global fetch function, return a Promise, and it seems that in the upcoming future more and more browser built-ins will be operating on promises. So if you're willing to write modern code, you're not going to escape promises.
这篇关于何时不使用承诺的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
