Reduxの新しいContext APIが発表され、2ヶ月くらいが経過した。
\n\n\n\n
私は少しバージョンの古いReactを主に使っているため、しばらく情報を追わずにいたが、
\n\n\n— Reactの新Context APIとRedux is deadはどう関係するのか？ – terrierscript – Medium
\n
\n\n\n
などの記事が登場するようになったので、自分は新しいContext APIとどう向き合うのかを考えてみた。
\n\n新しいContext APIはとても有用で、それ自体は活用しようと思う。\nただしContext APIがReduxを置き換えるものではないと思っており、引き続きReduxを使用する
\nconst { Provider, Consumer } = React.createContext()\n\nconst Counter = () => (\n <Consumer>\n {({ state, increment }) => (\n <React.Fragment>\n <div>\n <span>Count:</span>\n <span>{state.count}</span>\n </div>\n <button onClick={increment}>+1</button>\n </React.Fragment>\n )}\n </Consumer>\n)\n\nclass App extends React.Component {\n state = {\n \tcount: 0,\n }\n\n increment = () => {\n this.setState({ count: this.state.count + 1 })\n }\n\n render () {\n return (\n <Provider value={{\n state: this.state,\n increment: this.increment,\n }}>\n <Counter />\n </Provider>\n )\n }\n}\n\nReactDOM.render(\n <App />,\n document.getElementById('container')\n);このように使える。\nProvider, Consumerという二役に分かれ、とても宣言的なAPIになったと思う。
これまでのContextは、childContextTypes、getChildContext、contextTypesなど色々なメソッドをコンポーネントに実装して利用する、実質的なインタフェースとして機能していた。
\nこの方式ではprop-typesの利用も必須であるため、せっかくReact本体とは切り離されたライブラリをわざわざnpm installして利用することを強いられていた。
\nそれに比べると、はるかに扱いやすいAPIに変わったと思う。
軽いstate操作なら確かにこれだけでも足りるかもしれないし、多言語対応（文言定義）やテーマなど、宣言的に渡すデータにおいてはとても有用だと思う。
\nでは、Reduxはこれだけで無くすことができるのだろうか？\n私は違うと思う。
\nRedux（というかReact Redux）を「どこでもconnectできてstateを共有できるHoC」と捉えると、Contextさえあれば事足りているのかもしれない。
\nContext APIだけを用いて、React Reduxのconnectっぽい関数を実現するとしたら、例えばこんな感じで雑に実装できる。
const connectLike = (mapStateToProps, mapDispatchToProps) => (Component) => (props) => (\n <Consumer>\n {(context) => (\n <Component\n {...props}\n {...mapStateToProps(context.state)}\n {...mapDispatchToProps(context.dispatch)}\n />\n )}\n </Consumer>\n)これを利用して先ほどのサンプルコードを置き換えると、このように書けると思う
\nconst CounterComponent = ({ count, increment }) => (\n <React.Fragment>\n <div>\n <span>Count:</span>\n <span>{count}</span>\n </div>\n <button onClick={increment}>+1</button>\n </React.Fragment>\n)\n\nconst mapStateToProps = (state) => ({ count: state.count })\nconst mapDispatchToProps = (dispatch) => ({\n increment () {\n // action, reducerを端折ったかなり簡素な実装\n dispatch((state) => ({\n ...state,\n count: state.count + 1,\n }))\n },\n})\n\nconst Counter = connectLike(mapStateToProps, mapDispatchToProps)(CounterComponent)\n\nclass App extends React.Component {\n state = {\n \tcount: 0,\n }\n\n reduce = (reducer) => {\n this.setState(reducer)\n }\n\n render () {\n return (\n <Provider value={{\n state: this.state,\n \tdispatch: this.reduce,\n }}>\n <Counter />\n </Provider>\n )\n }\n}Reduxの処理の大部分を端折って実現したが、connectLikeの使い心地はそれっぽいものにはなったと思う。\nでは、**Reduxを用いてやりたいことは、たったこれだけなのだろうか。**私は違うと思う。
\n私は、state管理やFluxアーキテクチャを提供してくれる他に、何よりミドルウェアがReduxの魅力だと思っている。
\nまず、3rdパーティのミドルウェアが豊富にある。
\n例えば、redux-loggerのように開発時に便利なロガーだったり、redux-thunkのような非同期に対するアプローチ、redux-persistのようなstateの永続化などが挙げられる。
ではContextを内部的に包み隠してくれる3rdパーティのライブラリがたくさん登場したらReduxは不要なのだろうか。
\nそれでもまだ私はReduxに価値があると思っている。
なぜなら、3rdパーティなミドルウェアが豊富にあることもさることながら、
\nActionそのものと、Action handlerを分離するためにRedux Middlewareを利用しているからだ。
React Nativeの開発をしていると、どうしてもプラットフォームに依存する処理が多数登場する。
\n例えばHTTP通信やPush通知、Alert、AsyncStorageなど。
\nネイティブに限らず、webでもAjax、LocalStorageやWebWorkerなど、プラットフォームに依存した処理は登場すると思う。
これらの処理がロジックの中に混じっていると非常にテストがしにくい。メンテナンスしにくく気軽じゃないテストになる。
\nこういったプラットフォームに依存した処理をMiddleware側に逃して、ActionCreatorやThunkActionはUniversalに書いておくと、とてもテストがしやすい。
例えばアラートを抽象化するとこのような感じにできると思う。
\nこのアクションがdispatchされると、別途書いてあるMiddleware側でアラートを表示するように作れる。
} catch (error) {\n dispatch(feedback({\n title: 'エラーが起こった',\n message: error.message,\n }))\n}このようにプラットフォームに依存した処理をAction creatorの中に直接書かずに、Middlewareの中に書く。\nそうするとMiddlewareをapplyしなければどの環境でも動く処理になり、「dispatchされたアクションは何か？」にだけ注力すればよくなる。
\n例が少なくて恐縮だが、ミドルウェアにプラットフォームへの依存を閉じ込めて使いたい私にとって、\nContext APIはReduxを置き換えるものではないと思った。
\nなお、Reduxに過度に拘っているわけではない。ミドルウェアを扱う処理はたかだか20行程度なので、いざとなればオレオレで置き換えることもできる。
\nただ、メンテナンスされているライブラリがあるならば、わざわざオレオレ実装する意味はなく、それを利用したらいいと思っている。
\nContextについて触れている記事を読んでいて、「大規模ならReduxを使うケースもある」とかふわっとした意見が多いなと思ったので、\n具体的になぜReduxが必要なのかの一ケースについて書きたかった。
\nAction/Action handler(Middleware)の考えは、CQRSの狭義のCommand/Command handlerと捉えることもできそうだなと思った。
\nredux-thunkとミドルウェアと活用したユースケース駆動開発についてはもっと詳しく書きたいので、別途記事を書こうと思う。
以上、私にとってのReduxはこんな感じでした。
\n誰かにとってのReduxが、あなたにとってのReduxだとは限らないので、あなたにとってReduxは何であって何ではないのか、という記事が増えると色々な目線が得られてとても勉強になるので、記事たくさん書かれてほしい。