Reduxのアプリケーション作成の際のメモ

概要

基本的なことは、公式ドキュメント及びそれらの解説ブログ等を参考にした。
ゼロからではなく、サンプルを流用

• 公式のサンプル

目的

• Reduxの機能を一通り覚える
• Reduxでの実装の勘所を押さえる
• サンプルの修正から始めることで、機能追加・変更が起きた際にどこを修正すれば良いかを理解する

作ったもの

アンケートアプリ
https://github.com/sugiii8/react-redux-enquete-app

• 問題に回答して、回答に応じた結果を表示するというもの
• 以前に作ったことがあるので設計は把握している

ハマったところ

• Container Component(以降Container)/Presentation Component(以降Component)の分け方

  • Container: Componentに渡すデータ・関数を定義・設定する。dispatchを行う。
  • Component: Containerから渡されたデータを表示する。イベントハンドラで、Containerから渡された関数を呼ぶ。 - Componentはただ渡されたものを表示・実行するだけ。中身については関知しない。
  • ※ render() はComponentでやるべきと思っていたが、他サンプル見てるとContainerでやってるのもあるのでそうでもないみたい。

• 非同期処理

  • redux-thunkをMiddlewareとして適用する
  • ※ Middlewareについてはふわっとした理解になっているので後で改めて調べる

• ビジネスロジックはどこに

  • modelを追加してそこに集約する
    • 実体はimmutable.jsのRecord()
  • reducerはmodelのメソッドを呼ぶだけにする

• document.ready() 的なことがしたい

  • componentDidMount()
    • 今回はこのタイミングでリモートのjsonを取りに行った

• ループ内でComponentを呼ぶ

  • key属性に一意になる値を設定しないと警告が出る
  • React側でどのComponentの特定ができなくなるから(?要調査)

やってわかったこと

• 役割が分割されることのメリットは大規模アプリケーションで威力を発揮しそう
  • ロジックの見通し、action/reducer(model)を見れば、何が行われるかがひと目で分かること
• ContainerのmapDispatchToProps() で必要な関数のみに絞ることで、子の何でもあり状態を制限することができる
  • バグの温床を作りづらい
• ただやはりメリットは大規模開発時の時に享受できるもので、今回の規模だた、手間のほうがかかるという感じもした。
  • もちろん今回は学習のためなので、そうなるだろうと予測はしていた。
• reduxに限らず何か作る際は、完成されたものを弄くりながら進めたほうが理解も完成も早いということを実感した。