Promise ドキュメントの落とし穴

人気ドキュメントの落とし穴を避ける

Google検索結果や人気ライブラリに見られるPromiseアンチパターンを発見する。

まず告白から始めさせてほしい。私自身、以下で批判するのと同じ「アンチパターン」を書いてきた罪がある。それは多くのJS開発者も同様だろう。ここに書いたことは、特定の個人を非難する意図も、元の著者に向けたものも一切ない。単によくあるパターンに対してコードレビューを行っているだけだ——このプロジェクトを通じて、私の優先順位と批判的思考プロセスを伝えられればと思う。

このプロジェクトを理解すれば、悪いPromiseの警告サインを見抜けるようになるはずだ。

1. CallbackHell.com
2. StrongLoop
3. RisingStack
4. Qライブラリ

CallbackHell.com

出典: 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/ これはかなりしっかりした記事だ。懸念は1つだけある。

Qライブラリ

CREDIT: https://github.com/kriskowal/q

Qライブラリは最も使われているライブラリの1つであり、‘Promises’に関連づけられた最古のものの1つでもある。そのため、古いサンプルコードや後方互換性の維持という課題を抱えている。 Qは実際にはdeferredパターンに関するものだと感じているため、‘Promises’に関連していると言っている。

Promiseに似ているかもしれないが、私はそうではないと主張する。間違った理由で表面積が大きすぎる。また、命名規則が一貫しておらず名前を省略しているため、インターフェースを覚えにくくなっている。whenやdoneのようなメソッドは不要だ。

結論：deferredパターンは厄介なアンチパターンだ。典型的なコールバック手法と比べて、実質的に何も改善していない。

この記事の関連Githubプロジェクト、Escape From Callback Mountainをチェックして（& star）ください。

プロジェクトの目標：JavaScriptにおけるより良い関数型言語パターンの研究と開発。