日本一わかりやすいReact-Redux入門#1~#3

はじめに

この記事は、Youtubeチャンネル『トラハックのエンジニア学習ゼミ【とらゼミ】』の『日本一わかりやすいReact-Redux入門』の学習備忘録です。

前回講座で学んだ React に続き、大規模アプリ開発の必須のライブラリである Redux についても勉強をしていきます。

前回シリーズ『日本一わかりやすいReact入門【実践編】』の記事はこちらからどうぞ。

#1...講座の概要【ECアプリを作ろう】

講座の目標

• React と Redux で SPA の開発ができるようになる
• ECアプリの開発方法を学ぶことができる
• トランザクション処理を入れた決済機能を実装できるようになる

講座の最終成果物

服飾系を商品として取り扱うECアプリを作っていきます。
- 店舗:ユーザー = 1:n(ユニクロやZOZOのように、商品の「出品者」と「購入者」が明確に分かれている設計)
- 店舗は出品、在庫管理、売上管理ができる
- ユーザーは、商品閲覧、カートへの追加、購入、注文履歴の確認ができる

使用技術

• Javascript(JSX)
• React
  • react-dom: 画面遷移（ルーティング）を実装
  • react-router: 画面遷移（ルーティング）を実装
• Redux
  • react-redux: reactとreduxをつなげ、stateを一元管理
  • redux-thunk: データベース通信に欠かせない非同期処理を実装
• Material-UI
• Firebase
  • Auth: アカウント認証機能
  • Firestore: データベース
  • Functions: データベースに対する処理（商品の検索機能に使用）
  • Storage: 画像のアップロード
  • Hosting: アプリの本番環境へのデプロイ
• Stripe(API): アプリへ決済機能を導入するSaaS

講座のAdvanced版

本講座の最後のトピックとなる「決済機能」に関わる部分の講座は、トラハックさんが運営する有料コミュニティ「とらゼミ」から視聴可能です。（そこまではYoutube上で無料公開）

本Qiita記事では無料公開される範囲の講座のみを取り扱います。

Redux に関わる内容については無料範囲で十分に学べると思います。

#2...CRAとFirebaseで環境構築

動画に倣ってreactアプリとFirebaseの設定をすればOKです。

流れは前回講座の「日本一わかりやすいReact入門【実践編】#2...サクッと環境構築しよう」とほぼ同様です。(Redux など、インストールするnpmパッケージには違いがあります)

#3...Fluxフローは絶対に知っておいて

Redux とは？

Reactアプリの state を一元管理するためのライブラリ。

Redux のない純Reactアプリでは、stateはコンポーネント内で定義され、親コンポーネント→子コンポーネントと、バケツリレーの要領で渡されていく。アプリが小さいサイズのときは純Reactでも問題にはならないが、アプリが大きくなってくるについて、バケツリレーがどんどん複雑かつ高階層になる（親→子→孫→ひ孫→...）。

また、特定のコンポーネントで使用しているstateが「そもそもどのコンポーネントで定義されたものか」などの見通しも悪くなり、管理がとても大変になる。

この state 管理問題を解決するために、Reduxが用いられる。Redux を導入することで、アプリ全体の state を保存しておく Storeという場所が作られる。

Reactアプリ側は、このStoreと通信することで、どのコンポーネントからでも state を扱うことができるようになり、無駄なバケツリレーを防ぐことができる。

また、　state自体の定義も全てRedux側で行うことになるので、「このstateどのコンポーネントから来てるんだっけ？」という問題が起こらなくなる。

Fluxフローとは

データフロー設計の1つ。
- 1. データが常に1方向に流れる
- 2. 何らかのイベントをきっかけにデータの状態が変化する（イベント駆動）。

Reduxは、「Reactの状態管理をFlux思想で行う」ことを念頭に開発されたライブラリであり、Flux思想で扱われる単語がしばしば用いられる。

Reduxの登場人物

Reduxの中でのデータの受け渡しは、Fluxフローに則り、いくつかの役割に分担されている。

例えば、「現在1という値が格納されているcountという state の値が、画面に描画されているCOUNT_UPボタンが押されることで、2に変更される」というストーリーを通じて、Reduxにおける登場人物を整理する。

Components

いわゆる普通の React のコンポーネント。ReduxのFluxフローにおいては、イベントが最初に走る発火点という位置付け。

COUNT_UPボタンが定義されており、「countの値を+1したい」といった趣旨の命令が実行される記述が、ボタンのonClickイベントとして定義されている。

Container

Store(=stateが保存されている場所)と接続された、特殊なコンポーネント。個々のComponentsの取りまとめ役。

通常の Components は Redux とは直接接続されていないため、いったんContainerが「COUNT_UPボタンが押された」のようなイベントの情報を受け取る必要がある。

Components「countを+1したいです」
Container「分かった。Reduxに聞いてみる」

Action

Containerからの要求を受け、変更をさらに次へ依頼する。Fluxフローにおいては窓口の役割。

変更を依頼すること自体は、dispatchと言う。

Container「countを+1したいらしいです」
Action「分かりました。担当につなぎます（dispatch）」

Reducer

変更を管理する役割。現在の state の状態と、Action から受けた依頼の内容から、実行すべき処理を解釈する。

Action「countを+1したい、とのことです」
Reducer「分かりました」
↓
Reducer「現在のcountの値が1、依頼内容は『countの値を+1したい』だから、countの値を2にすればいいんだな」

Store

状態を保存する倉庫の役割。Reducerの命令により、stateを取り出すor変更する。

Reducer「countの値を2に変更した上で、再度アプリ側に出してください」
Store「分かりました(ここでstateの変更が実行される)」

mapStateToProps・mapDispatchToProps

変更された state を、再度 Containerに渡す

mapStateToProps・mapDispatchToProps「countの値を2に変わったから、Componentsに渡しておいて」
Container「分かりました」

この後、ContainerからComponentsに、変更後のcountが反映される。

Container「countが+1できたみたいよ」
Components「やったぜ」

大切なのは、
- 1. データが常に1方向に流れる
- 2. 何らかのイベントをきっかけにデータの状態が変化する（イベント駆動）。
というFlux思想がしっかりと守られている点。例えば、Reducer→Actionのような方向のデータの受け渡しは絶対に起こらない。

おわり

今回はここまで。

次回からは実際にコードを書く内容になっていく予定です。