Подводные камни в документации Promise
Избегаем проблем популярных документов
Обнаружение анти‑шаблонов Promise в результатах поиска Google и популярных библиотеках.
Начну с признания: я сам писал те же «анти‑шаблоны», которые критикую ниже, и уверен, что многие разработчики JS делают то же самое. Всё, что я изложил, не направлено лично ни к кому и тем более не нацелено на оригинальных авторов. Это просто обзор типичных паттернов — я хочу передать вам своё понимание приоритетов и процесса критического мышления.
Надеюсь, после изучения этого проекта вы сможете распознавать сигналы плохих Promise.
CallbackHell.com
CREDIT: http://callbackhell.com/
StrongLoop
CREDIT:
https://strongloop.com/strongblog/node-js-callback-hell-promises-generators/
RisingStack
CREDIT: https://blog.risingstack.com/node-js-async-best-practices-avoiding-callback-hell-node-js-at-scale/ Это довольно солидная статья. У меня есть лишь одна озабоченность:
Q Library
CREDIT: https://github.com/kriskowal/q
Библиотека Q — одна из самых часто используемых и старейших, ассоциируемых с «Promise». Поэтому она страдает от устаревших примеров и необходимости поддерживать обратную совместимость.
Я говорю «ассоциируется с ‘Promise’», потому что считаю, что Q на самом деле реализует паттерн deferred.
Она может напоминать Promise, однако я настаиваю, что это не так. У неё слишком большая поверхность API по неправильным причинам. Кроме того, соглашения об именовании непоследовательно сокращают названия, что усложняет запоминание интерфейса. Методы вроде when и done не нужны.
Bottom line: паттерн deferred — болезненный анти‑паттерн, который почти ничего не улучшает по сравнению с обычным подходом через колбэки.
Пожалуйста, ознакомьтесь с (и поставьте ★) сопутствующим репозиторием статьи на Github — Escape From Callback Mountain
Цель проекта: исследовать и разрабатывать более чистые функциональные паттерны в JavaScript.