feat(redux): ReduxのMiddlewareのPros/Cons

ja/Redux/README.md

@@ -199,22 +199,49 @@ Connectの _Middleware_ は最終的な結果(`response`)を書き換えでき
 
 ## どういう事に向いてる?
 
-- アスペクト的に前後に処理を挟むことができる
-    - ログへの利用
-- 値自体は直接操作できない
-- 受取るデータは変換できる
+Reduxの _Middleware_ そのものも三原則に基づいた仕組みとなっています。
+_Middleware_ はActionオブジェクトを自由に書き換えたり、Actionを無視したりできます。
+一方、Stateを直接は書き換える事ができません。
+
+多くのプラグインの仕組みでは、プラグインに特権的な機能を与えている事が多いですが、
+Reduxの _Middleware_ は書き込みのような特権的な要素も制限されています。
+
+_Middleware_ に与えられている特権的なAPIとしては、`getState()` と `dispatch()`ですが、
+どちらも書き込みをするようなAPIではありません。
+
+このように、プラグインに対して一定の権限を持つAPIを与えつつ、
+原則を壊すような特権を与えない事を目的としている場合に向いています。
 
 ## どういう事に向いていない?
 
-- [ ] TODO
-- 変換の仕組み上、書き換え等を行うプラグインを扱いにくい
+一方、プラグインにも書き込み権限を与えないためには、
+プラグイン間でやり取りする中間的なデータ表現が必要になります。
+
+Reduxの場合は、Actionオブジェクトが中間表現として存在しますが、
+このような中間表現が導入しにくい場所には向かない仕組みと言えるかもしれません。
+
+ReduxではActionオブジェクトというような命令(コマンド)を表現したオブジェクトに対して、
+Reducerという命令を元に新しいStateを作り出す仕組みを設けていました。
+
+つまり、プラグインそのものだけではできる事が限られています。
+プラグインで処理した結果を受け取り、その結果を処理する実装も同時に必要となっています。
+
+プラグインを組み合わせるだけで全ての処理ができるわけではなく、
+そのプラグインで処理した結果に対する実装も必要になります。
+そういう意味ではプラグインと実装の距離が近いと言えるかもしれません。
+
+そのため、プラグインのみで全処理が完結するような機能を持たせるようなことに向いていないといえます。
+
+## まとめ
 
-## この仕組みを使っているもの
+ここでは[Redux][]のプラグインアーキテクチャについて学びました。
 
-- Connectに似ている
-- _Middleware_もStateそのものを直接書き換える事はできません
-- この部分が類似の仕組みを持つ[connect](../connect/README.md)との違いになっています
+- Reduxの _Middleware_ はActionオブジェクトに対する処理を書ける
+- _Middleware_ に対しても三原則が適応されている
+- _Middleware_ に対しても扱える機能の制限を適応しやすい
+- _Middleware_ のみで全ての処理が完結するわけではない
 
+## 参考
 
 
 [Redux]: https://github.com/reactjs/redux  "reactjs/redux: Predictable state container for JavaScript apps"