Help us understand the problem. What is going on with this article?

Reduxを使ってみたのでざっと概要をまとめる

More than 1 year has passed since last update.

この記事はGizumoエンジニア Advent Calendar 2015の10日目の記事です。

僕のここ最近の心境として、今はフロントエンドエンジニアとしてひたすらSPAを書きまくっていたいなあというのがあってとりあえず自分のブログをSPAで作り直してみよっかなと思い立ったのでReact使ってやりましょうとなってそしてフレームワークはReduxを使ってみた。

なんでReactとReduxを選んだのかってのは特にしっかり考えたわけではなく、流行ってるので勉強としてとりあえず使ってみようって感じ。
しかしやってみて気付いたことだが事前になんの考えもなくとりあえず導入してSPA作ろうみたいなのは確実に間違っているということ。ブログの管理画面をSPAにするならまだしもユーザーがなんの状態も持たないただのブログの表側と管理画面をいっしょくたにSPAにしちゃった僕の考えは浅はかだと言わざるを得ない。

いやまあ勉強のためにやっただけだからいいんだけれど。
とりあえず言えることとしては、業務で使うのであればなんのためにSPAにするのか、なんのためにそのフレームワークを選定するのかってとこで明確な理由・メリットを提示できなければ導入なんてするもんじゃないんだなっていう、そんなわかりきってることを学びました。

そんなわけで本題に入ります。

はじめに

fluxをとりあえず勉強してそのままReduxに入ったら概念がいろいろごっちゃになってしまったのでまずそれぞれに出てくる単語の役割をまとめようと思う。

flux

  • Store
  • Action Creators
  • Dispatcher
  • React Views

Store

StoreはMVCでいうModelみたいなものだけれど同じではない。
Action Creatorsからのイベントの通知を受けて状態を変更して状態の変更をReact Viewsに通知するっていう役割に徹する。

Action Creators

ユーザーの操作によって起こるイベントをReact Viewsから受け取ってStoreに対して通知を送る。

React Views

描画の役割。MVCのViewと同じ。ここでReact使う。
Storeから状態の変更の通知を受け取ったらDOMの再描画。
ユーザーの操作が起きたらAction Creatorsにイベントを通知する。

Dispatcher

EventEmitterと考えて良い。
それぞれの要素をイベントの発火と監視によって繋げる役割。

それぞれの役割はこれだけだと思う。
fluxの特徴はデータが一方向にしか流れないということであってこれさえ確実に守っていればおっけーだと思う。

そんでfluxを勉強するためにfacebookのexampleの実装を見て真似したりしてた。
facebook/flux example

fluxはアーキテクチャであってフレームワークとかではないので自分でぱぱっと実装できちゃう。一応Dispatcherの部分だけfacebookが提供しているけれどEventEmitterでいいのではって感じではある。
とりあえずやってみて理解できたのかできてないのかどうなんだろうってところでいろんな人の記事とか見てみた結果わりとみんな好きなようにオレオレ実装をやっていて、やっぱり一方向にデータが流れるっていうところだけ押さえとけばいいのかってなった段階でfluxの勉強はもうやめた。

次のReduxが本題。

Redux

Reduxはfluxのフレームワーク。fluxのフレームワークは色々出てきたけどみんな口を揃えてRedux良いって言ってるイメージ。
状態管理に重きを置いているフレームワークということです。
Reduxには以下の要素がある。fluxのフレームワークなのでfluxの言葉を使っているんだけれど役割がわりと違っている。

  • Action
  • Reducer
  • Store
  • Middleware

Action

ただのオブジェクトを返すピュアな関数。どんなイベントが起きたかというtypeとそしてそのときの値を渡す。

Reducer

それまでの状態とアクションを受け取って次の状態を返すピュア関数。
Reducerはピュアな関数でないといけないので、もらった引数の中身を変えたりAPIを読んだりルーティングの遷移をしたりDate.now()とかMath.random()とかそういうの全部だめ。
同じ引数が渡されたら毎回同じ値を返すものでないといけない。

Store

fluxのStoreと違ってアプリケーションの全ての状態を一つのステートツリーとして保持するシングルトンなStore。

Middleware

Middlewareを使うことでdispatchする前や後に好きな処理を追加することができる。非同期処理を書いたり状態更新のたびにログだしたりとか色々とできる。

概念としてはこんな感じ。
それぞれの要素が簡単な処理でできていてそれらを連結してく感じなのでやることはそこまで難しくないけど始めは理解するの大変だった。

Reduxはドキュメントがすごく充実していて公式のexampleをやれば大体理解できる。

rackt/redux examples

examplesを見るとViewがcomponentとcontainerに分かれていて、最初はよくわからなかったけれどreduxと絡む部分はcontainer、reduxと絡まない部分はcomponentとなるみたい。
大体Viewの子要素はcomponentになる。

おわりに

ほんとはここから概念はわかったからじゃあ実際に実装はどんな感じにするのかって話をしようかと思っていたのだけれど、なかなか遅々として実装が進まない状態なので今日はこれくらいで終わりにします。

またSPAのブログが完成したらgithubと実際のサイトを出した状態で実装についてまとめようかなーと思う。

正直redux知らない人がこの記事読んでもまったくわからないと思うのですがとにかくReduxは公式のドキュメントがとても良いからそっち見ろと言いたい。以上です。

nabeliwo
うぇっぶふろんとえんどえんじにゃー😸
https://blog.nabeliwo.com
smarthr
社会の非合理を、ハックする。
https://smarthr.co.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした