React + Reduxのデータフローがいまいちイメージできてないのでまとめてみた

React + Reduxのデータフローがいまいちイメージできてないのでまとめてみた

現在React + Reduxで開発をしていてようやく慣れてきてどんな風に書けばどんな風に動くかっていうのがわかってきたところです。ですが、Reduxのデータフローはわかっているつもりになっているだけなんじゃないかなと思ってまとめてみました。

はじめに

基本的な流れとしては

View → Action → Middleware → Reducer → Store → View

って感じで流れていきます。流れの追っていきかたはわかるんだけど実際それぞれは何をやっているのかなって思って調べてみました。
すると結構難しいんですよね。

・Reduxのフローは常に一方向で行われる
・Action CreatorがViewやスケジューリングされている非同期のイベントなどをトリガーにActionを生成する
・Middlewareがステート変更前後で任意の処理を実行
・Actionに対して横断的処理を行なうMiddlewareを通じてActionはReducerへ届けられる
・Reducerが変更後のstateをStoreに知らせる
・Storeがstateを更新した後、Viewが変更を検知し自らを更新

調べてみるとだいたいこんな感じ。初めてReact + Reduxやる人には結構難しい気がするんですよねー。
実際、僕も一方向なのはわかるけど、実際よくわかっていなかったです。

ってことで自分なりに商品を注文したっていう例でご紹介したいと思います!!

とりあえず手書きでイメージがしました

ざっくりこんな感じだと思う!!というか字きたねー
10

View

ここはブラウザに表示させる仕事をします。例えるなら「自分」と思っていいと思います。
こんな商品が欲しいとかって思いますよね。その「欲しい」がJavaScriptで言うところの「イベント」です。
例えば、Formが送信されたとか、ボタンが押されたとかですね。

Action

欲しいと思ったことをもとに注文書(Action)を作成します。

あと、Actionは何を行うものかを識別するためにtypeプロパティを必ず持っているという特徴があります。
いわば書き方に決まりがある感じですね。

何かする時は必ず注文書を作らなければ次に進むことはありません。例えばModalを出したいとかTabを切り替えたい時もAction(注文書)を作成します。

Middleware

ここでは注文書(Action)を受け取り、商品(State)を作り配送をします。工場みたいなものですね。
で、実際開発している時は、最初に作ったらその後ほとんど触ることすらありません。

なので、制作している時はほとんど意識する必要はないかもしれません。
正直、Actionを発行したら次のReducerで変更しているって解釈でもいいかもくらい。

Reducer

ここでは新商品(State)が届いたことを店舗に知らせます。
ここもよくいじりますね。

基本的にAction作ったらReducerで知らせる!!

Store

店舗(Store)で商品(State)が新しくなったので更新を行います。

ここはほぼほぼいじることがありません。ちなみに、一つのアプリケーションにStoreは一個です。
ようはいくつも店舗があるわけではなく自分が受け取る窓口はここだけです。

なので、実際作っている時はそんなに意識しなくてもいいです。ようはReducerから知らせがあったら絶対にここを通っているんで。

最後に自分(View)が店舗でStateを受け取ります。この時StateはView受け取ると(props)という名前に変わります。

終わりに

イメージ的にはこれで概ね合っているのかなと思います。イメージが頭の中にあるとコーディングもしやすいので、
こうゆう時間を作るのは意外に大事だったりますよね。

## オススメの本



WebデベロッパーのためのReact開発入門 JavaScript UIライブラリの基本と活用

イチからわかる!Reactの仕組みと使い方UIコードの再利用化と速度向上を図る!Reactのコンセプト、コンポーネント、JSX、活用テクニック、一歩進んだ使い方を解説!

イチマルニデザインブログをフォローしよう

イチマルニデザインブログではTwitterアカウントでWebに関する情報をつぶやいています。フォローすることで最新情報をすぐに受け取ることができます

いいなと思ったらシェアお願いします

同じカテゴリーの記事

ページの先頭へ