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

## はじめに
この記事は、Youtubeチャンネル『トラハックのエンジニア学習ゼミ【とらゼミ】』の『[日本一わかりやすいReact-Redux入門](https://www.youtube.com/watch?v=FBMA34gUsgw&t=109s)』の学習備忘録です。

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

前回シリーズ『[日本一わかりやすいReact入門【実践編】](https://www.youtube.com/watch?v=MzJkWO73S70&t=1s)』の記事は[こちら](https://qiita.com/ddpmntcpbr/items/77a2db9d8dab6e3b2525)からどうぞ。

## #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版

本講座の最後のトピックとなる「決済機能」に関わる部分の講座は、トラハックさんが運営する有料コミュニティ「[とらゼミ](https://www.youtube.com/watch?v=tIzE7hUDbBM)」から視聴可能です。（そこまではYoutube上で無料公開）

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

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

## #2...CRAとFirebaseで環境構築
動画に倣ってreactアプリとFirebaseの設定をすればOKです。

流れは前回講座の「[日本一わかりやすいReact入門【実践編】#2...サクッと環境構築しよう](https://qiita.com/ddpmntcpbr/items/77a2db9d8dab6e3b2525#2%E3%82%B5%E3%82%AF%E3%83%83%E3%81%A8%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89%E3%81%97%E3%82%88%E3%81%86)」とほぼ同様です。(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のような方向のデータの受け渡しは絶対に起こらない。

### おわり
今回はここまで。

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