大規模なReactアプリケーションを整理してスケーラブルにする方法

Reactの最も優れた機能の1つは、プロジェクトのファイル構造に制限を課さないことです。 したがって、StackOverflowには非常に多くの質問があり、Reactアプリケーションを構成する方法については同様のリソースがあります。 これは非常に物議を醸すトピックです。 正しい方法はありません。 Jack Franklinの記事の助けを借りてこの問題を理解することを提案します。JackFranklinは、大規模なReactアプリケーションを構造化するアプローチについて説明しています。 ここでは、ツールの選択、ファイルの構造化、コンポーネントをより小さな部分に分解することについて、Reactアプリケーションを作成するときにどのような決定を下すことができるかを説明します。

コード構築および検証ツール

Webpackは、プロジェクトを収集するための優れたツールです。 その複雑さにもかかわらず、チームがバージョン2と新しいドキュメントサイトで素晴らしい仕事をしたという事実は、問題を大幅に簡素化します。 明確なコンセプトを念頭に置いてWebpackを使用すると、すぐに信じられないほど強力なツールが手に入ります。 Babelを使用して、React固有の変換を含むコードをコンパイルできます。たとえば、サイトのローカル「ホスティング」用のJSXおよびwebpack-dev-serverです。 おそらくHMRは大きな利点をもたらさないので、webpack-dev-serverを自動ページ更新とともに使用するだけで十分です。



また、依存関係のインポートとエクスポートには、ES2015モジュール（Babelによって変換される）の構文を使用します。 この構文は長い間存在しており、WebpackはCommonJS（ノードスタイルのインポート構文）をサポートしていますが、最新かつ最高のものを使用するのが最善です。 さらに、WebpackはES2015モジュールを使用してバンドルからデッドコードを削除できます。これは、理想的ではありませんが、コミュニティがES2015標準のnpmでコードの公開を開始する際に役立つ便利な機能です。

Webpackモジュールの解決の構成

添付ファイル構造を持つ大規模なプロジェクトで作業するときに失望することができる唯一のことは、ファイル間の相対パスの決定です。 次のようなコードがたくさんあることがわかります。

import foo from './foo' import bar from '../../../bar' import baz from '../../lib/baz'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Webpackを使用してアプリケーションを作成するときに、Webpackがファイルを見つけられない場合にWebpackがファイルを検索するディレクトリを指定できます。 これにより、インポート全体が属するベースフォルダを決定できます。 たとえば、いつでもコードをsrcディレクトリに置くことができます。 また、Webpackに常にこのディレクトリを表示させることができます。 これは、使用している可能性のある他のファイル拡張子、たとえばjsxをWebpackに通知するのと同じ場所で行われます。

 // inside Webpack config object { resolve: { modules: ['node_modules', 'src'], extensions: ['.js', '.jsx'], } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

resolve.modulesのデフォルト値は['node_modules']



なので、追加する必要があります。追加しないと、Webpackはnpmまたはyarnを使用してインストールされたファイルをインポートできません。



その後、srcディレクトリに関連するファイルをいつでもインポートできます。

 import foo from './foo' import bar from 'app/bar' // => src/app/bar import baz from 'an/example/import' // => src/an/example/import
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これによりWebpackアプリケーションのコードが拘束されますが、コードの実行が容易になり、インポートの追加がはるかに簡単になるため、これはおそらく有益な妥協案です。

ディレクトリ構造

すべてのReactアプリケーションに単一の正しいディレクトリ構造はありません。 この記事の残りの部分と同様に、好みに合わせて構造を変更する必要があります。 適切に機能する構造の一例を以下に説明します。

コードはsrcにあります

整理するために、すべてのアプリケーションコードをsrcというディレクトリに配置します。 これにはコードのみが含まれており、最終的なバンドルになりますが、それ以上のものはありません。 これは、Babel（またはコードを処理する他のツール）に1つのディレクトリを調べて、必要のないコードを処理しないように指示できるため便利です。 Webpack構成ファイルなどの他のコードは、適切なディレクトリにあります。 たとえば、トップレベルのディレクトリ構造には次のものが含まれます。

 - src => app code here - webpack => webpack configs - scripts => any build scripts - tests => any test specific code (API mocks, etc)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常、最上位のファイルは、index.html、package.json、および.babelrcなどのドットファイルのみです。 package.jsonにBabel設定を含めることを好む人もいますが、多くの依存関係を持つ大規模なプロジェクトでは、これらのファイルが大きくなりすぎる可能性があるため、.eslintrc、.babelrcなどを使用することをお勧めします。



アプリケーションコードをsrcにresolve.modules



ことによりresolve.modules



上記のresolve.modules



設定を使用することもできます。これにより、インポートが容易になります。

反応コンポーネント

srcディレクトリを決定したら、コンポーネントの構造化方法を決定する必要があります。 それらのすべてがsrc / componentsなどの1つの大きなフォルダーに配置されている場合、大規模なプロジェクトでは非常にすばやく混乱します。



一般的な傾向は、スマートコンポーネントと愚かなコンポーネント（コンテナコンポーネントおよびプレゼンテーションコンポーネントとも呼ばれる）に個別のフォルダが使用できることですが、このような明示的な分割は必ずしも有用ではありません。 また、おそらく「スマート」と「バカ」に分類できるコンポーネントがありますが（詳細は以下）、これらのカテゴリごとにフォルダーを作成する必要はありません。



使用されるアプリケーション領域に基づいてコンポーネントをグループ化し、どこでも使用される一般的なコンポーネント（ボタン、ヘッダー、フッター-ユニバーサルで再利用可能なコンポーネント）のコアディレクトリを使用しました。 残りのディレクトリは、アプリケーションの特定の領域に対応しています。 たとえば、ショッピングカートに関連付けられたすべてのコンポーネントを含むcartというカタログと、ユーザーがページで購入できるもののリストのコードを含むListingsというカタログがあります。



また、ディレクトリでグループ化すると、コンポーネントが使用されるアプリケーション領域を指す不要なプレフィックスを避けることができます。 たとえば、ユーザーのバスケットの合計コストを表示するコンポーネントがある場合、カートディレクトリからインポートされるため、CartTotalではなくTotalと呼ぶことができます。

 import Total from 'src/cart/total' // vs import CartTotal from 'src/cart/cart-total'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この規則に違反する場合があります。特に類似した名前のコンポーネントが2〜3個ある場合は、プレフィックスを追加すると明確になる場合があります。 しかし、多くの場合、この方法では名前の重複が回避されます。

大文字ではなくJSX拡張子

多くの人は、Reactコンポーネントの名前に大文字を使用して、通常のJavaScriptファイルと区別しています。 したがって、上記のインポートでは、ファイルはCartTotal.jsまたはTotal.jsと呼ばれます。 ただし、区切り文字としてハイフンを使用して小文字に固執することができます。つまり、Reactコンポーネントを区別するには、.jsx：cart-total.jsxファイル拡張子を使用します。



これにより、わずかな追加の利点が得られます。Reactファイルのみを簡単に検索し、.jsxでファイル内の検索を制限でき、必要に応じて特定のWebpackプラグインを適用することもできます。



どのファイル命名規則を選択しても、それに固執することが重要です。 アプリケーションでいくつかの規則を組み合わせて使用​​すると、すぐに悪夢に陥り、どうにかしてナビゲートする必要があります。

ファイル内の1つのコンポーネントのみ

前の規則に従って、1つのファイルに常に1つのコンポーネントのみを配置し、そのコンポーネントを常にデフォルトのエクスポートにする必要があるという合意に準拠します。



通常、Reactファイルは次のようになります。

 import React, { Component, PropTypes } from 'react' export default class Total extends Component { ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Reduxデータウェアハウスなどに接続するためにコンポーネントをラップする必要がある場合、完全にラップされたコンポーネントがデフォルトのエクスポートになります。

 import React, { Component, PropTypes } from 'react' import { connect } from 'react-redux' export class Total extends Component { ... } export default connect(() => {...})(Total)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

元のコンポーネントをまだエクスポートしていることに気づきましたか？ これは、ユニットテストでReduxを構成するのではなく、「単純な」コンポーネントで作業できる場合のテストに非常に役立ちます。



デフォルトでコンポーネントをエクスポートする場合、正確な名前を探すのではなく、コンポーネントをインポートして取得する方法を知るのは簡単です。 このアプローチの欠点の1つは、インポートするユーザーがコンポーネントを自由に呼び出すことができることです。 繰り返しになりますが、これには同意があります。インポートはファイル名で実行する必要があります。 したがって、total.jsxをインポートする場合、コンポーネントの名前はTotalにする必要があります。 user-header.jsxはUserHeaderなどになります。

スマートおよびダムReactコンポーネント

上記では、コンポーネントをスマートとバカに分離することについて簡単に言及しました。 また、これらを別々のディレクトリに配置しませんが、アプリケーションを次の2つのタイプのコンポーネントに大きく分けることができます。

• スマートコンポーネントは、データを操作し、Reduxに接続し、ユーザーの操作を処理します。
• 愚かなコンポーネントは、画面にデータを表示するためのプロパティセットのみを提供します。

愚かなコンポーネントが私たちのアプリケーションの大部分を占めており、可能であれば、それらに常に好みを与えるべきです。 作業が簡単で、問題が少なく、テストが簡単です。



スマートコンポーネントを作成する必要がある場合でも、すべてのJavaScriptロジックを別のファイルに保存しようとします。 理想的には、データ操作コンポーネントはこのデータをJavaScriptに渡し、実際にそれを実行する必要があります。 その後、Reactとは別に操作コードをテストできます。Reactコンポーネントをテストするときに、コードを使用して何でもできます。

大きなレンダリング方法を避ける

私たちが目指していることの1つは、少数の大きなReactコンポーネントではなく、多数の小さなReactコンポーネントを使用することです。 コンポーネントが大きくなりすぎていることを示す良い指標は、レンダリング関数のサイズです。 面倒になる場合、またはいくつかの小さな機能に分割する必要がある場合は、コンポーネントを分割することを検討する時間です。



これは厳密な規則ではありません。 あなたとあなたのチームは、数を増やす前に、あなたにとって「大きな」コンポーネントとみなされるものを明確に理解する必要があります。 ただし、コンポーネントのrender



関数のサイズは適切なガイドです。 状態にある小道具やアイテムの数を別の良い指標として使用することもできます。 コンポーネントが7つの異なる小道具を受け入れる場合、これはそれが多すぎることを示している可能性があります。

常に支柱タイプを使用する

Reactでは、prop-typesパッケージを使用して、コンポーネントに渡されると予想されるプロパティの名前とタイプを文書化できます。 これはReact 15.5には当てはまらないことに注意してください;以前は、proptypeはReactモジュールの一部でした。



予想されるプロパティの名前とタイプ、およびそれらがオプションであるかどうかを宣言する場合、コンポーネントの操作に自信を持ち、プロパティの名前を忘れたり、間違ったタイプを割り当てたりした場合のデバッグ時間を短縮する必要があります。 これは、ESLint-React PropTypesルールを使用して実現できます。



それらを追加する時間が無駄になるように思われるかもしれません。 ただし、これを行う場合は、6か月前に作成したコンポーネントを再利用することに感謝します。

Redux

Reduxを使用して、多くのアプリケーションでデータを管理しています。また、Reduxアプリケーションの構造化は、さまざまな意見を持つ非常に一般的な質問です。



私たちの勝者はDucksで、アプリケーションの各部分のアクション、レデューサー、アクションクリエーターを1つのファイルに入れます。



それぞれが互いに通信するためのコードの断片を含むreducers.jsとactions.jsを使用する代わりに、Ducksシステムは、関連するコードを単一のファイルにグループ化することが理にかなっていると主張しています。 2つの最上位キーuser



とposts



を持つReduxストアがあるとします。 フォルダ構造は次のようになります。

 ducks - index.js - user.js - posts.js
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

index.jsには、メインのレデューサーが作成するコードが含まれます。おそらくReduxのcombineReducers



を使用し、user.jsおよびposts.jsにそれらのすべてのコードを配置します。通常は次のようになります。

 // user.js const LOG_IN = 'LOG_IN' export const logIn = name => ({ type: LOG_IN, name }) export default function reducer(state = {}, action) { .. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、異なるファイルからアクションとアクション作成者をインポートする必要がなくなり、リポジトリのさまざまな部分の近くのコードを保存できます。

スタンドアロンJavaScriptモジュール

この記事ではReactコンポーネントに焦点を当てましたが、Reactアプリケーションを作成するときに、Reactとは完全に分離した多くのコードを書くことができます。



コンポーネントから削除できるビジネスロジックを持つコンポーネントを見つけるたびに、これを行うことをお勧めします。 通常、libまたはservicesという名前のディレクトリはうまく機能します-特定の名前は重要ではありませんが、「非Reactコンポーネント」でいっぱいのディレクトリが本当に必要なものです。



これらのサービスは、機能のグループ、または関連する機能のオブジェクトをエクスポートする場合があります。 たとえば、ネイティブのwindow.localStorage



APIの小さなラッパーを提供するservices/local-storage



があります。

 // services/local-storage.js const LocalStorage = { get() {}, set() {}, ... } export default LocalStorage
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ロジックをそのようなコンポーネントから分離しておくことには、いくつかの本当に大きな利点があります。

• Reactコンポーネントをレンダリングする必要なく、このコードを単独でテストできます。
• Reactコンポーネントでは、サービスをスタブ化して、特定のテストに必要なデータを取得できます。

テスト

Jest Facebookフレームワークは、テスト用の優れたツールです。 多くのテストを非常に迅速かつ適切に処理し、表示モードで迅速に実行し、すぐにフィードバックを提供し、Reactのテストに便利な機能を提供します。 テストの構成方法を検討してください。



誰かが、すべてのタスクのすべてのテストを含む別のディレクトリを用意する方が良いと言うでしょう。 src / app / foo.jsxがある場合は、tests / app / foo.test.jsxもあります。 しかし実際には、アプリケーションが大きくなると、必要なファイルを見つけることが難しくなります。 また、ファイルをsrcに移動すると、テストのためにファイルを移動するのを忘れてしまい、構造の同期が失われます。 また、srcからファイルをインポートする必要があるテストにファイルがある場合、非常に長いインポートを取得します。 きっと誰もが出くわしました：

 import Foo from '../../../src/app/foo'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

操作が難しく、ディレクトリ構造を変更した場合は修正が困難です。



ただし、各テストファイルをソースファイルと共に配置すると、これらの問題がすべて回避されます。 それらを区別するために、テストに接尾辞.specを追加しますが、他のものは.testまたは単に-testを使用しますが、すべて同じ名前のソースファイルの隣にあります。

 - cart — total.jsx — total.spec.jsx - services — local-storage.js — local-storage.spec.js
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ディレクトリ構造が変更されると、正しいテストファイルを簡単に移動できます。 また、ファイルにテストがない場合にもすぐにわかります。 これらの問題をすばやく特定して修正できます。

結論

目標を達成する方法はたくさんありますが、これはReactについて言えることです。 フレームワークの最も優れた機能の1つは、ツール、ビルドツール、ディレクトリ構造に関するほとんどの決定をどのように行うことができるかです。 この記事が、より大きなReactアプリケーションを構築する方法についてのアイデアを与えてくれることを願っています。