1

When not using promises

 2 years ago
source link: https://www.codesd.com/item/when-not-using-promises.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

When not using promises

advertisements

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?

Update:

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.


Some rules of thumb:

  1. 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] 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.

  2. 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.

  3. 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.

  4. [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.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK