Fluxアーキテクチャのお勉強

アプリ開発するんだから、実装より先にアーキテクチャの部分を決めて行かないといけないよね。

# 今回作るアプリ
今回はレシピ管理アプリみたいなやつを作ろうと思う。

- レシピ一覧
- iOSでいうところのTableView。セルをタップすると詳細画面に遷移する
- レシピ作成
- データはとりあえずローカルに保存する。でも将来はサーバーに持ちたい。

# ReactNativeのアーキテクチャってどんなん？
Reactと同じようにReduxを用いたFluxパターンが王道っぽい。
まあ、勉強だと思ってReduxを採用しましょう。
ちなみに筆者はReactも初心者なのでReduxをちゃんと理解していません。

# Fluxってなんなん？
https://github.com/facebook/flux/tree/master/examples/flux-concepts
以下、意訳。
> Fluxはデータフローを管理するためのアーキテクチャパターンです。一番大事なのは、Fluxはデータの流れが単方向であることです。

ふむふむ

> Fluxには4つの部品があります。

## Dispatcher
> DispatcherはActionを受け取り、そのアクションをDispatcherに登録したStoreへ送ります。全てのStoreが全てのActionを受け取ります。アプリケーションの中でDispatcherはシングルトンであるべきです。

ふむふむ。Actionとは？Storeとは？

## Store
> Storeはアプリケーションのデータを保持しておくものです。StoreはActionを受け取るためにDispatcherを登録します。StoreのデータはActionを受け取った時にしか変更されません。publicでいいのはゲッターだけで、publicなセッターをStoreに持つべきではありません。StoreはなんのActionを受け取るか決めます。Storeのデータが変更されるといつも、changeイベントが発火します。アプリケーション内にStoreはたくさんあります。

ふむふむ。
どこか（Viewとか？）でActionがDispatcherに送られて、DispatcherがそのActionを然るべきStoreに振り分けるみたいなイメージかな？

## Actions
>アクションはアプリケーション内部のAPI定義です。どんな種類のインタラクトが発生したかを捕捉します。Actionはtypeフィールドといくつかのデータを持った単純なオブジェクトです。Actionはセマンティックで、発生したアクションを説明するものであるべきです。Actionの実装の詳細を説明するものではありません。「ユーザーIDを消す」「ユーザーデータを消す」みたいなものではなく、「ユーザーを消す」というようなものを使いましょう。全てのStoreは同じAction、例えば「ユーザーを消す」Actionをハンドリングして、データを消すのか、クレデンシャルを更新するのかなどを判別します。

よくわからんけど、Storeでなんらかの操作を行うそのトリガーとその引数、みたいなことであってるかな。

## Views
>StoreからのデータはViewに表示されます。 Viewはあなたが望むどんなフレームワークも使用できます（ここでのほとんどの例では、Reactを使用します）。 ViewがStoreからのデータを使用する場合、そのStoreからの変更イベントをサブスクライブする必要もあります。その後、Storeが変更を発行すると、Viewは新しいデータを取得して再レンダリングします。コンポーネントがStoreを使用し、それをサブスクライブしない場合、微妙なバグが存在する可能性があります。 Actionは通常、ユーザーがアプリケーションのインターフェイスの一部を操作するときにViewから送出されます。

ViewがStoreをサブスクライブ（購読/監視）する。Storeのデータが更新される。それを検知して新しいデータで再レンダリングする。なるほど。

## Example
>
- ViewはTodoStoreをサブスクライブ（購読/監視）する。
- todoを追加するActionを定義する。

```
   {
     type： 'add-todo',
     title： 'タイトル',
   }
```

>
- ユーザーが新しいTodoのタイトルを入力して完了すると、ViewはDispatcherにタスクのタイトルを含む「add-todo」アクションををディスパッチするよう指示する。
- すべてのストアがディスパッチされたアクションを受け取る。
- 自分に関係のあるActionだったら、そのActionを処理する。
- この場合TodoStoreはアクションを処理し、別のTodoを内部データ構造に追加してから、changeイベントを発行する。
- Viewはchangeイベントをリッスンしています。イベントを取得し、TodoStoreから新しいデータを取得して、Todoのリストを再レンダリングする。

ぐるっと回って帰ってくる、みたいなことね！！つまり単方向のデータフローだ！！！
この中でDispatcherは全てのActionを受け取って全てのストアにそれをぶん投げる、Actionの問屋みたいなことね！
（一元管理したいのでシングルトンであることが望ましい、と）

## Data Flow
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/248316/29c139b1-c955-3888-e6ea-4b5bc4ed6879.png)
よくみる画像を拝借。うんうん。こうやってみると、わかりやすい。

# なんでReact系はFluxアーキテクチャがいいんだろう？
モバイルアプリとかではあまり聞かないよね。サクッと調べたらVue.jsはMVVMが有名っぽい？うーん。詳しい人がいたら教えて欲しい。

## Reduxってなんだ？
さて。Reduxってなんだ？
https://redux.js.org/basics/basic-tutorial
公式のチュートリアルを追ってみよう

> ReducerとかミドルウェアとかStoreへの派手な話に騙されないで。Reduxってマジで単純なんだ

信じよう。

## Actions
> Actionは、アプリケーションからStoreにデータを送信する情報のペイロードです。 Storeの唯一の情報源です。それらは、store.dispatch（）を使用してStoreに送信します。

ここの役割というか定義はFluxと同じっぽい。

```
{
type: ADD_TODO,
text: 'Build my first Redux app'
}
```

## Reducers
これはなんだ？

> Reducerは、Storeに送信されたActionに応じてアプリケーションの状態がどのように変化するかを指定します。 Actionは何が起こったかを説明するだけで、アプリケーションの状態がどのように変化するかを説明しないことに注意してください。

つまり？
https://redux.js.org/basics/reducers

全然わかんないじゃん！？
誰か助けて。。。ということで
https://qiita.com/tkow/items/9da7062f9bfa99e848c3

つまり、ReducerがActionを受け取って、そのタイプに応じて適切な関数によって値を変化させる、ということっぽい。
めちゃめちゃざっくり。