現代のアプリケーションは、これまで以上に、それに対応して、内部と外部の両方でより複雑にする必要があります。開発者は、一貫した設計が欠けている複雑なアプリケーションの成長によって引き起こされる混乱に長い間気づいていました。スパゲッティのようなコードは楽しいだけでなく、開発者の開発の進行を遅くし、ビジネスユニットの進行を遅くします。使い捨てソリューションとjQueryプラグインでいっぱいの大規模なコードベースで最後に作業したときのことを覚えていますか？これは面白くないと推定されています。混乱に対処するために、開発者はMVC（Model-View-Controller）などのパラダイムを開発して、アプリケーション機能を編成し、開発をガイドしています。Flux（およびその拡張Redux）はすべて同じであり、アプリケーションの複雑化に対応するために開発者を支援します。
MVCパラダイムに特に慣れていない場合でも、心配する必要はありません。この本では、MVCパラダイムの説明に多くの時間を割くことはありません。ただし、比較のために、FluxとReduxについて説明する前に、MVCについて簡単に説明しましょう。ここにいくつかの基本的な知識があります。
- モデル（model）-アプリケーションデータ。通常、User、Account、Postなどの名詞。モデルには、関連するデータを操作するための基本的なメソッドが少なくとも必要です。最も抽象的な意味では、モデルは生のデータまたは知識を表します。モデルは、データがアプリケーションコードと相互作用する場所です。たとえば、データベースには、accessScope、authenticationなどの属性を格納できます。モデルは、isAllowedAccessForResource（）などのメソッドでこれらのデータを使用でき、これらのメソッドはモデルの基になるデータを操作します。モデルは、元のデータとアプリケーションコードが収束する場所です。
- モデルのビュー表現。ビューは通常、ユーザーインターフェイス自体です。ビューには、データ表現とは関係のないロジックがあってはなりません。フロントエンドフレームワークの場合、これは通常、特定のビューがリソースに直接関連付けられ、CRUD（作成、読み取り、更新、削除）操作が関連付けられていることを意味します。フロントエンドアプリケーションは、常にこのように構築されているわけではありません。
- コントローラー（コントローラー）-コントローラーは、モデルとビューを結び付ける「接着剤」です。コントローラは一般的に単なる接着剤であり、それ以上何もしません（たとえば、複雑なビューやデータベースロジックを含むべきではありません）。一般的に言えば、データを変更するコントローラーの能力は、コントローラーが操作するモデルよりもはるかに低くなければなりません。
この章で説明するパラダイム（FluxとRedux）はこれらの概念とは大きく異なりますが、目標は、開発者がスケーラブルで合理的かつ効果的なアプリケーションアーキテクチャを作成できるようにすることです。
Reduxの起源とデザインは、Facebook内のFluxと呼ばれる人気のあるモデルによるものです。Ruby on Railsやその他のアプリケーションフレームワークで使用されている一般的なMVCパターンに精通している場合、Fluxは慣れているパターンとは異なる場合があります。Fluxはアプリケーションのさまざまな部分をモデル、ビュー、コントローラーに分解しませんが、いくつかの異なる部分を定義します。
- store-storeには、アプリケーションの状態とロジックが含まれています。従来のMVCのモデルに少し似ています。ただし、単一のデータベースレコードを表すのではなく、多くのオブジェクトの状態を管理します。モデルとは異なり、開発者はリソースに制限されることなく、合理的な方法でデータを表現できます。
- Action-Fluxアプリケーションは状態を直接更新しませんが、状態を変更するアクションを作成してアプリケーションの状態を変更します。
- ビューユーザーインターフェイス。通常はReactですが、FluxはReactを必要としません。
- ディスパッチャー-ストアを操作および更新するための集中コーディネーター。
図10-1にFluxの概要を示します。
図10-1簡単なFluxの概要
図10-1に示すように、Fluxモードでは、アクションがビューから作成され（ユーザーが何かをクリックする可能性があります）、ディスパッチャーが着信アクションを処理し、アクションを適切なストアに送信して更新します状態。状態の変更後、通知ビューは新しいデータを使用する必要があります（該当する場合）。これが一般的なMVCスタイルのフレームワークとはどのように異なるのかに注意してください。MVCスタイルのフレームワークでは、ビューとモデル（ここのストアなど）の両方が互いに更新できます。この双方向のデータフローは、Fluxアーキテクチャで一般的な単方向のデータフローとは異なります。さらに、ここにはミドルウェアがないことに注意してください。ミドルウェアはFluxで作成できますが、Reduxのような一流の市民ではないため、ここでは省略します。
以前にMVCスタイルのアプリケーションを開発したことがある場合、一部のコンテンツはおなじみのように聞こえますが、データフロー方式はそうでない場合があります。前述のように、データはFluxパラダイムでより一方向に流れます。これは、MVCタイプの実装が使用する傾向がある双方向の方法とは異なります。これは通常、アプリケーションにデータフローの単一のソースがないことを意味します。システムの多くの異なる部分が状態を変更する権利を持ち、状態は通常、アプリケーション全体に分散しています。この方法は多くの状況でうまく機能しますが、より大きなアプリケーションでは、デバッグと使用が混乱する可能性があります。
これが中規模から大規模のアプリケーションでどのようになるかを想像してみてください。独自のコントローラーとビューに関連付けられた一連のモデル（ユーザー、アカウント、認証）があるとします。状態はアプリケーションのさまざまな部分に分散しているため、アプリケーションのどこにいても、状態の正確な場所を特定することは困難です（ユーザーに関する情報は、前述の3つのモデルのいずれかで見つけることができます）。
小さなアプリケーションの場合、これは必ずしも問題ではなく、大きなアプリケーションでもうまく機能する可能性がありますが、大きなクライアントアプリケーションでは、さらに困難になる可能性があります。たとえば、50の異なる場所でモデルの使用を変更する必要があり、状態の変化を認識する必要がある60の異なるコントローラーがある場合はどうなりますか？状況をより複雑にするために、ビューは一部のフロントエンドフレームワークのモデルのように動作することがあります（そのため、状態はより分散されます）。データの本当の出所はどこですか？ビューや多くの異なるモデルに散らばっており、それらすべてが中程度に複雑な設定になっている場合、すべてを追跡することは困難です。これは、アプリケーションの状態の不整合にもつながり、アプリケーションのバグを引き起こす可能性があるため、これは単に「開発者のみが直面する」問題ではなく、エンドユーザーにも直接影響します。
これが難しい理由の1つは、一般に、時間の経過に伴う変化を推測するのが苦手だからです。この質問を本当に理解するために、あなたの頭の中でチェス盤を想像してみてください。チェス盤のスナップショット、または頭に数枚のスナップショットを撮ることは難しくありませんが、20ラウンドの間、すべてのチェス盤のスナップショットを追跡できますか？ラウンド30はどうですか？ゲーム全体はどうですか？時間の経過に伴うデータの非同期の変化を頭の中で追跡することは難しいので、考えやすく使用しやすいシステムを構築する必要があります。たとえば、リモートAPIを呼び出し、そのデータを使用してアプリケーションの状態を更新することを検討してください。これは少数のケースでは簡単ですが、ユーザーがまだアプリケーションを使用していて、APIインタラクションが増える可能性のある変更を加えている間に、50の異なるAPIサーバーエンドポイントを呼び出して着信応答を追跡する必要がある場合は、それから何が起こりますか？それらを頭の中で整理し、変化の結果を予測することは困難です。
ReactとFluxの類似点に気づいたかもしれません。どちらもユーザーインターフェースを構築する比較的新しい方法であり、開発者が使用するメンタルモデルを改善することを目的としています。これらの2つの方法で、変更は簡単に推測でき、開発者はUIを干渉するのではなく、強化する方法で構築できるはずです。
Fluxは実際のコードではどのように見えますか？これは主にパラダイムであるため、フラックスのコアアイデアを実装する多くのライブラリがあります。これらのライブラリは、Fluxの実装方法が少し異なります。Reduxも同じですが、そのユニークなFluxスタイルは多くのユーザーと注目を集めています。その他のFluxライブラリには、Flummox、Fluxxor、Reflux、Fluxible、Lux、McFly、MartyJSが含まれます（ただし、実際にはこれらのライブラリはReduxと比較して使用されることはめったにありません）。
10.1.1 Reduxとの最初の出会い：Fluxのバリアント
おそらくReduxは、Fluxの背後にあるアイデアを実装する、最も広く使用されている有名なライブラリです。Reduxライブラリは、少し変更された方法でFluxのアイデアを実装しています。Reduxのドキュメントでは、これを「JavaScriptアプリケーションの予測可能な状態コンテナ」として説明しています。具体的には、これはFluxの概念とアイデアを独自の方法で実践することを意味します。
ここでFluxの正確な定義を決定することは重要ではありませんが、FluxパラダイムとReduxパラダイムの重要な違いをいくつか紹介します。
- Reduxは単一のストアを使用します。Reduxアプリケーションは状態情報をアプリケーションの複数のストアに保存せず、すべてを1か所に保存します。Fluxは複数の異なるストアを持つことができます。Reduxはこのルールに違反し、単一のグローバルストアの使用を強制します。
- Reduxはレデューサーを導入し、レデューサーはより不変な方法で変更を行います。Reduxでは、状態は確定的かつ予測可能な方法で変更され、一度に変更されるのは状態の一部のみであり、（グローバルストア内の）1つの場所でのみ発生します。
- Reduxはミドルウェアを導入します。アクションとデータフローが一方向であるため、開発者はミドルウェアをReduxアプリケーションに追加し、データが更新されたときにカスタム動作を注入できます。
- Reduxのアクションはストアに関連付けられていません。アクションの作成者はストアに何もディスパッチせず、代わりに中央のスケジューラーが使用するアクションオブジェクトを返します。
あなたにとって、これらは単なるニュアンスかもしれませんが、それは問題ではありません-あなたの目標はReduxを学ぶことであり、「違いを見つける」ことではありません。図10-2は、Reduxアーキテクチャの概要を示しています。さまざまな部分のそれぞれに飛び込み、それらがどのように機能するかを探り、アプリケーション用のReduxアーキテクチャを開発します。
図10-2 Reduxの概要
図10-2に示すように、アクション、ストア、およびレデューサーは、Reduxアーキテクチャの本体を構成します。Reduxは、特定の確定的な方法で更新される集中状態オブジェクトを使用します。開発者が状態を更新する場合（通常はクリックなどのイベントが原因）、アクションが作成されます。アクションには、特定のレデューサーが処理するタイプがあります。特定のアクションタイプを処理するレデューサーは、現在の状態のコピーを生成し、アクションからのデータを使用してそれを変更した後、新しい状態に戻ります。ストアが更新されると、ビューレイヤー（ここではReactコンポーネント）が更新をリッスンし、それに応じて応答できます。また、図のビューはストアからの更新を読み取るだけであることに注意してください。これらはビューが通信するデータを気にしません。ストアが変更されると、React-reduxライブラリーは新しい小道具をコンポーネントに渡しますが、ビューはまだデータを受け取って表示するだけです。
10.1.2 Reduxの準備
Reduxはアプリケーションアーキテクチャのパラダイムであり、インストール可能なライブラリでもあります。これは、「生の」Flux実装に対するReduxの1つの側面です。Fluxパラダイムには多くの実装（Flummox、Fluxxor、Reflux、Fluxible、Lux、McFly、MartyJSなど）があり、それらはすべて異なるレベルのコミュニティサポートと異なるAPIを持っています。Reduxは強力なコミュニティサポートを備えていますが、Reduxライブラリ自体のAPIは非常に小さくて強力であり、これが最も人気があり、Reactアプリケーションアーキテクチャライブラリに最も依存するライブラリの1つになるのに役立ちます。実際、ReactでのReduxの使用は非常に一般的であるため、2つのコアチームが相互に通信して、機能の互換性と認識を確保することがよくあります。同時に2つのチームに所属している人もいるので、2つのプロジェクト間での視認性とコミュニケーションは良好です。
Reduxを使用するように設定するには、いくつかの作業を行う必要があります。
- すべての正しい依存関係がローカルにインストールされるように、現在の章のソースコードでnpm installを実行してください。この章では、js-cookie、rudux-mock-store、reduxなど、いくつかの新しいライブラリの利用を開始します。
- Redux開発者ツールをインストールします。それらを使用して、ブラウザーでReduxストアとアクションを表示できます。
Reduxは予測可能なように設計されているため、すばらしいデバッグツールを簡単に作成できます。Dan AbramovとReduxおよびReactライブラリに取り組んでいる他のエンジニアは、Reduxアプリケーションを処理するための強力なツールをいくつか開発しました。Reduxの状態は予測可能な方法で変化するため、新しい方法でデバッグすることができます。開発者はアプリケーションの状態の個々の変更を追跡し、変更の違いを確認し、アプリケーションの状態の変化に応じてアプリケーションの状態を巻き戻して再生することもできます。時間は変わります。Redux Dev Tools拡張機能を使用すると、ユーザーはこれらすべてのタスクを完了することができ、さらに、配布用のブラウザー拡張機能としてパッケージ化されます。図10-3は、Redux開発ツールの機能の概要を示しています。
図10-3 Redux Dev Tools拡張機能は、Dan Abramovの人気のRedux Dev Toolsライブラリを便利なブラウザ拡張機能にパッケージ化したものです。これを使用すると、Reduxアプリケーションを巻き戻して再生したり、変更を1つずつ表示したり、状態変更の違いを確認したり、1つの領域でアプリケーション全体の状態を確認したり、テストテンプレートを生成したりできます。
拡張機能をインストールすると、ブラウザのツールバーに新しい開発ツールのアイコンが表示されます。執筆期間の終わりには、開発モードでReduxアプリケーションインスタンスが検出された場合にのみ色が付けられるため、アクセスしたアプリケーションまたはWebサイトがReduxを使用していない場合、拡張機能は機能しません。しかし、アプリケーションが設定されると、アイコンが色付きになり、それをクリックするとツールが開きます。
この記事は「React Actual Combat」からの引用です。
この本は、エキスパートのようにユーザー・インターフェース（UI）について考えるように読者を導き、Reactでそれらを構築するように読者に教えます。この本は非常に実用的であり、多くの実用的な例があり、読者はすぐに始めることができます。この本の目的は、読者がレンダリング、ライフサイクルメソッド、JSX、データフロー、フォーム、ルーティング、サードパーティライブラリとの統合およびテストのコアコンセプトを習得し、本で紹介されているアプリケーション設計の概念を使用してアプリケーションの人気を促進できるようにすることです。Reactをフルスタックアプリケーションに統合する方法を学習する過程で、読者はRedu **を使用して状態管理とサーバー側レンダリングを探索し、モバイルUI向けのReact Nativeに連絡することもできます。この本は、HTML、CSS、およびJavaScriptに精通している開発者向けに特別に書かれています。
この本の主な内容
●Reactを最初から使用します。
●ルーティングシステムをコンポーネントで実装します。
●Node.jsでのサーバー側レンダリング。
●サードパーティのライブラリを使用します。
●Reactコンポーネントをテストします。