書籍「React in action」

こんにちは、habrozhiteli！ React in Actionという本は、フロントエンド開発者にReactフレームワークと関連ツールを紹介しています。 最初に、Reactライブラリーに精通し、このコンテキストでいくつかの基本的なアイデアを更新し、コンポーネントの操作について学習します。 実際には、純粋なReactをマスターし（トランスパレーションなし、構文ヘルパーなし）、最も単純な静的コンポーネントから動的でインタラクティブなものに移行します。



本の後半では、Reactと対話するさまざまな方法について説明します。 ライフサイクルの基本的な方法、データストリーム、フォームの作成方法、およびアプリケーションのテスト方法を学びます。 手始めに、Reactアプリケーションのアーキテクチャ、Reduxとの相互作用、サーバーレンダリングへの遠足、React Nativeのレビューに関する資料があります。

抜粋 第11章ReduxとReactの統合

• レデューサーは、Reduxが状態の変更方法を決定する方法です。
• ReactでReduxを使用します。
• Reduxアプリケーションアーキテクチャを使用するためのSocialレターの変換。
• いいねやコメントの機能をアプリケーションに追加します。

ここでは、前の章で行った作業を続けて、Reduxアーキテクチャの基本要素を作成します。 ReactのReduxアクションおよびリポジトリーとの統合に取り組み、リデューサーの仕組みを学びます。 Reduxは、Reactを念頭に置いて設計されたFluxテンプレートのバリアントであり、単方向のデータフローとReact APIでうまく機能します。 これは普遍的な選択ではありませんが、多くの大規模なReactアプリケーションでは、状態管理ソリューションを実装するための最適なオプションの1つとしてReduxを使用しています。 彼らの例をフォローして、Letters Socialに適用してください。

ソースコードを取得する



以前と同様に、この章からgithub.com/react-in-action/letters-socialの GitHubリポジトリにアクセスして、サンプルのソースコードを取得できます。 ここから最初から作業を開始する予定がある場合は、第7章と第8章のサンプルのソースコードを取得するか（自分で学習して例を完了した場合）、この章に関連するブランチを参照してください（第10章の11）。



各ブランチには、章の最終コードが含まれていることに注意してください（たとえば、chapter-10-11には、10章と11章の最後に取得したコードが含まれています）。 コマンドラインシェルで選択した次のコマンドのいずれかを実行して、現在の章からサンプルコードを取得できます。 リポジトリがまったくない場合は、次のコマンドを実行します。

git clone git@github.com:react-in-action/letters-social.git
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リポジトリのクローンをすでに作成している場合、次の手順を実行します。

 git checkout chapter-10-11
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別の章からここに移動したので、コマンドを使用して必要な依存関係がすべてインストールされているかどうかを確認する価値があります。

 npm install
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

11.1。 ギアボックスは状態の変化方法を決定します

アクションを作成して送信し、エラーを処理することはできますが、それらは状態に一切影響しません。 着信アクションを処理するには、ギアボックスを構成する必要があります。 アクションは、イベントが発生したことを報告し、何が起こったのかに関する情報を提供するための単なる方法であり、それ以上のものではないことに注意してください。 レデューサーのタスクは、これらのアクションに応じてストアの状態がどのように変化するかを示すことです。 図 11.1は、すでに見たより一般的なRedux画像にギアボックスがどのように適合するかを示しています。



しかし、ギアボックスとは何ですか？ まだReduxのシンプルさを楽しんでいるなら、失望することはありません。これらは1つの目的を持つ単純な機能です。 ギアボックスは、前の状態とアクションを引数として取り、次の状態を返す純粋な関数です。 Reduxのドキュメントによると、メソッドのシグネチャはArray.prototype.reduceに渡されるデータのように見えるため、リデューサーと呼ばれます（たとえば、[1,2,3] .reduce（（a、b）=> a + b、0）。



ギアボックスは純粋な関数である必要があります。つまり、入力が与えられると、毎回同じ対応する出力が生成されます。 これは、副作用が生成され、API呼び出しが頻繁に発生するアクションまたはミドルウェアとは対照的です。 レデューサーで非同期またはクリーンでないものを実行する（たとえば、Date.nowまたはMath.random（）を呼び出す）ことは、アプリケーションのパフォーマンスまたは信頼性を低下させるアンチパターンです。 Reduxのドキュメントには次の句が含まれています。「同じ引数を受け取ったら、次の状態を計算して返す必要があります。 驚きはありません。 副作用はありません。 API呼び出しはありません。 変更なし。 計算だけです。」 詳細については、 redux.js.org / basics / reducersを参照してください。

11.1.1。 状態フォームと初期状態

レデューサーは、唯一のReduxストアを変更する作業を開始するので、今度はストアがどのような形態を取るかについて話します。 アプリケーションの状態フォームの設計は、アプリケーションのユーザーインターフェイスの動作に影響します（同時に、この動作の影響も受けます）が、原則として、ユーザーインターフェイスデータから可能な限り生データを保存することをお勧めします。 これを行う1つの方法は、識別子などの値をデータとは別に保存し、識別子を使用してデータを検索することです。



状態の形状と構造を決定するのに役立つ初期状態ファイルを作成します。 定数フォルダーに、initialState.jsというファイルを作成します。









これは、アクションが送信または変更される前のReduxアプリケーションの状態です。 エラー、ダウンロード状態、およびメッセージ、コメント、ユーザーに関する情報を入力します。 コメントとメッセージの識別子を配列に保存し、それらの基本情報を参照しやすいオブジェクトに保存します。 リスト11.1は、初期状態の構成の例を示しています。

11.1.2。 受信アクションに応答するギアボックスの設定

初期状態を設定する場合、リポジトリを更新できるように、着信アクションを処理するための複数のリデューサーを作成する必要があります。 ギアボックスは通常、switchステートメントを使用して、受信アクションのタイプに従って状態を更新します。 これらは、状態の新しいコピー（変更された同じバージョンではない）を返し、リポジトリの更新に使用されます。 ギアボックスもキャッチオールの原則に従って、未知のアクションが単に既存の状態に戻るようにします。 私はすでにこれを指摘しましたが、ギアボックスは計算を実行し、与えられた入力に基づいて毎回同じ結果を返さなければならないことをもう一度言うことが重要です-副作用や不明瞭なプロセスはありません。



ギアボックスは、ストレージの変更方法を計算する責任があります。 ほとんどのアプリケーションでは、多くのギアボックスがあり、それぞれがストレージの一部を担当します。 これにより、ファイルを簡潔かつ集中的に保つことができます。 最後に、Reduxで利用可能なcomposeReducersメソッドを使用して、レデューサーを1つに結合します。 ほとんどのレデューサーは、さまざまなタイプのアクションの場合にswitchステートメントを使用し、他のすべてにはデフォルトでcatch-allコマンドを使用して、不明なタイプのアクション（おそらく偶然に作成される）が状態に影響しないようにします。



また、Reducerは状態のコピーを作成し、リポジトリの既存の状態を直接変更しません。 図を見れば 11.1では、ギアボックスがジョブを実行するときに状態を使用することがわかります。 このアプローチは、不変のデータ構造が通常どのように機能するかに似ています。直接的な変更の代わりに、変更されたコピーが作成されます。 リスト11.2は、負荷軽減機能の設定方法を示しています。 この場合、状態のフラットスライス（ブール型プロパティの読み込み）を扱っているため、新しい状態に対してtrueまたはfalseを返すことに注意してください。 多くの場合、多くのキーまたはアタッチされたプロパティを持つ状態オブジェクトを使用します。この場合、リデューサーはtrueまたはfalseを返すだけでなく、それ以上のことを行う必要があります。









ダウンロードアクションが送信されたので、Reduxリポジトリはそれを使用して何かできるようになります。 アクションが到着し、既存のミドルウェアを通過すると、Reduxはリデューサーを使用して、アクションから作成する新しい状態を決定します。 レデューサーを設定する前に、リポジトリがアクションに含まれる変更情報を見つける方法がありませんでした。 これを示すために、図 11.2フローからギアボックスを取り外しました。 アクションがリポジトリに到達しない理由を確認してください。









次に、Reduxスキルを適用する別の減速機を作成します。 最終的に、多くのレデューサーは単純にtrueまたはfalseを返しません。 または、少なくとも計算では、trueまたはfalse以上のものがあります。 Letters Socialアプリケーションのもう1つの重要な部分は、メッセージの表示と作成です。メッセージをReduxに移植する必要があります。 アプリケーションが使用する既存のロジックのほとんどを保存し、Reduxを使用するように実際のReactアプリケーションを適合させたかのように、それをReduxに適した形式に変換する必要があります。 メッセージ自体を処理する2つのレデューサーと、メッセージ識別子を追跡する1つのレデューサーを作成します。 大規模なアプリケーションでは、異なるキーの下でそれらを組み合わせることができますが、今は別々に保存するのが良いです。 これは、単一のアクションを処理するために複数のギアボックスを構成する方法の例でもあります。 リスト11.3は、コメント用のレデューサーの作成方法を示しています。 ここでは、多くのギアボックスを作成します。これが完了すると、アプリケーションは発生する可能性のあるイベントの詳細な説明だけでなく、状態を変更する方法も受け取ります。









これで、コメントに関連するアクションを送信すると、それに応じてストアの状態が更新されます。 厳密に同じタイプではないアクションにどのように対応できるかに気づきましたか？ ギアボックスは、同じタイプではない場合でも、能力内のアクションに応答できます。 これは、ステータスメッセージスライスがメッセージを制御するという事実にもかかわらず、それに影響を与える可能性のある他のアクションがあるためです。 結論：ギアボックスは、どのアクションまたはアクションのタイプが来るかに関係なく、特定の状態インジケーターがどのように変化するかという問題を解決する責任があります。 一部のレデューサーは、モデル化するリソース（メッセージ）に関連しないさまざまなタイプのアクションについて知る必要がある場合があります。



これで、コメントレデューサーを作成したら、メッセージを処理するコメントレデューサーを実行できます。 識別子とオブジェクトとして別々に保存する同じ戦略を使用するため、コメントレデューサーに非常に似ています。 また、同類の有無にかかわらずメッセージを処理する方法を知る必要があります（この機能のアクションは、第10章で作成しました）。 リスト11.4は、これらすべてを実装する方法を示しています。















私（著者）はこれらのファイルに2つのレデューサーを含めました。これらは互いに非常に密接に関連しており、両方が同じ基本データ（メッセージとコメント）に作用するためです。ファイル内。 ほとんどの場合、ギアボックスのインストールは、ストレージの構造を反映するか、少なくともそれに対応します。 ストレージ状態フォーム（この章で前述した初期状態を参照）の開発は、リデューサーの定義方法と、それほどではないがアクションに大きな影響を与えることに気づいたかもしれません。 このことから得られる結論の1つは、光沢を与えるよりも、状態のフォームの開発により多くの時間を費やす方が良いということです。 デザインに割り当てられる時間が短すぎると、状態フォームを改良して改善するのにおそらく時間がかかりますが、注意深いデザインとReduxテンプレートにより、新しい機能の追加が簡単なアクションになります。

Reduxへの移行：必要ですか？



この章では、Reduxが初期セットアップに多くの作業を必要とする可能性があることを何度も述べました（既に経験している可能性があります）が、最終的には実を結ぶでしょう。 これは、私と他の使い慣れた開発者が取り組んだプロジェクトに特に当てはまります。 私が参加したプロジェクトには、FluxアーキテクチャからReduxへのアプリケーションの完全な移行が含まれていました。 チーム全体で約1か月働きましたが、アプリケーションの書き直しを開始し、不安定性を最小限に抑え、エラーの数を最小限に抑えることができました。



そして全体的な結果は、Reduxが適切な場所に配置するのに役立ったテンプレートを使用して、製品のより速い反復再生の可能性でした。 Reduxの移行から数か月後、アプリケーションの一連の完全な再設計を完了しました。 Reactアプリケーションのほとんどを再設計しましたが、Reduxアーキテクチャにより、アプリケーションの状態管理とビジネスロジックにほとんど変更を加えることができませんでした。 さらに、Reduxテンプレートにより、必要に応じてアプリケーションの状態に簡単に追加できます。 Reduxの統合により、Redux上でアプリケーションを構成および翻訳する作業が正当化され、引き続き配当が支払われます。

»本の詳細については、出版社のウェブサイトをご覧ください

» コンテンツ

» 抜粋



ホーカーのクーポンが20％オフ-React