大規模なReactアプリケーションの開発の組織

この投稿は、Reactを使用したjQueryフロントエンドの最新化に関するシリーズに基づいています。この記事が書かれた理由をよりよく理解するために、このシリーズの最初の記事を参照することをお勧めします。 最近では、小さなReactアプリケーションの開発を整理したり、最初から始めたりするのは非常に簡単です。特にcreate-react-appを使用する場合。一部のプロジェクトでは、（たとえば、アプリケーションの状態を管理し、プロジェクトを国際化するために）いくつかの依存関係と、少なくともディレクトリを含むフォルダのみが必要になる可能性があります。







srccomponents..。これがほとんどのReactプロジェクトが始まる構造だと思います。ただし、通常、プロジェクトの依存関係の数が増えると、プログラマーは、その構造に含まれるコンポーネント、レデューサー、およびその他の再利用可能なメカニズムの数の増加に直面します。時にはそれはすべて非常に不快になり、管理が困難になります。たとえば、特定の依存関係が必要な理由と、それらをどのように組み合わせるかが明確でなくなった場合はどうすればよいですか？または、プロジェクトに非常に多くのコンポーネントが蓄積されているため、それらの中から適切なコンポーネントを見つけることが困難になった場合はどうなりますか？プログラマーが名前を忘れた特定のコンポーネントを見つける必要がある場合はどうすればよいですか？



これらは、Karifyでフロントエンドを作り直しているときに答えを見つけなければならなかった質問のほんの一例です。依存関係とプロジェクトコンポーネントの数がいつか手に負えなくなる可能性があることはわかっていました。これは、プロジェクトが成長するにつれて、自信を持って作業を継続できるように、すべてを計画する必要があることを意味しました。この計画には、ファイルとフォルダーの構造およびコードの品質に関する合意が含まれていました。これには、プロジェクトの全体的なアーキテクチャの説明が含まれていました。そして最も重要なことは、プロジェクトに参加する新しいプログラマーがこれらすべてを簡単に認識できるようにする必要がありました。そうすることで、プロジェクトに参加するために、プロジェクトを長く研究しすぎず、すべての依存関係とコードのスタイルを理解する必要がなくなります。



この記事の執筆時点で、私たちのプロジェクトには約1200のJavaScriptファイルがあります。それらの350はコンポーネントです。コードは80％ユニットテスト済みです。以前に作成したプロジェクトアーキテクチャのフレームワーク内で確立および作業する契約を引き続き順守しているため、これらすべてを一般の人々と共有することをお勧めします。このようにしてこの記事が生まれました。ここでは、大規模なReactアプリケーションの開発を整理する方法と、それに取り組んだ経験から学んだ教訓について説明します。

ファイルやフォルダを整理するにはどうすればよいですか？

プロジェクトのいくつかの段階を経た後、Reactフロントエンドの資料を便利に整理する方法を見つけました。最初は、jQueryベースのフロントエンドコードが保存されているのと同じリポジトリでプロジェクト資料をホストする予定でした。ただし、使用しているバックエンドフレームワークによってプロジェクトに課せられたフォルダー構造の要件のため、このオプションは機能しませんでした。次に、フロントエンドコードを別のリポジトリに移動することを検討しました。最初はこのアプローチはうまく機能しましたが、時間の経過とともに、プロジェクトの他のクライアント部分、たとえばReactNativeに基づくフロントエンドの作成について考え始めました。これにより、コンポーネントライブラリについて考えるようになりました。その結果、新しいリポジトリを2つの別々のリポジトリに分割しました。 1つはコンポーネントライブラリ用で、もう1つは新しいReactフロントエンド用でした。最初はこのアイデアは成功したように見えましたが、その実装により、コードレビュー手順が大幅に複雑になりました。 2つのリポジトリの変更の関係が不明確になりました。その結果、コードを単一のリポジトリに保存するように再度切り替えることにしましたが、現在は単一のリポジトリになっています。



コンポーネントのライブラリとプロジェクトのフロントエンドアプリケーションを分離したかったので、モノリポジトリに決めました。モノリポジトリと他の同様のリポジトリの違いは、リポジトリ内でパッケージを公開する必要がなかったことです。私たちの場合、パッケージは開発のモジュール性を確保する手段であり、懸念を分離するためのツールでした。アプリケーションのバリアントごとに異なるパッケージを用意すると、それぞれに異なる依存関係を定義し、それぞれに異なるスクリプトを適用できるため、特に便利です。ルートファイルで次の構成を使用して、yarnワークスペースを



使用してモノリポジトリを設定します。package.json

"workspaces": [
    "app/*",
    "lib/*",
    "tool/*"
]

他のモノリポジトリと同じように、なぜパッケージフォルダを使用しなかったのか疑問に思われる方もいらっしゃるかもしれません。これは主に、アプリケーションとコンポーネントライブラリを分離したかったためです。さらに、独自のツールをいくつか作成する必要があることもわかっていました。その結果、上記のフォルダ構造に到達しました。これらのフォルダがプロジェクトでどのように再生されるかを次に示します。

• app：このフォルダ内のすべてのパッケージは、Karifyフロントエンドやその他の内部フロントエンドなどのフロントエンドアプリケーションに関連しています。ストーリーブックの資料もここに保存されています。
• lib: -, , . , , . , , typography, media primitive.
• tool: , , Node.js. , , , . , , webpack, , ( « »).

すべてのパッケージには、保存されているフォルダーに関係なく、サブフォルダーsrcと、オプションでフォルダーがありますbin。srcディレクトリappとに保存されているパッケージフォルダにlibは、次のサブフォルダが含まれている場合があります。

• actions：reduxまたはから関数をディスパッチするために戻り値を渡すことができるアクションを作成するための関数が含まれていますuseReducer。
• components：コンポーネントのフォルダーとそのコード、翻訳、ユニットテスト、スナップショット、履歴（特定のコンポーネントに該当する場合）が含まれます。
• constants：このフォルダには、さまざまな環境で変更されていない値が格納されます。ユーティリティもここに保存されます。
• fetch：これは、APIから受信したデータを処理するためのタイプ定義と、そのようなデータを受信するために使用される対応する非同期アクションが格納される場所です。
• helpers: , .
• reducers: , redux useReducer.
• routes: , react-router history.
• selectors: , redux-, , API.

このフォルダ構造により、依存関係によって定義されたさまざまな概念間で責任を分割するための明確なシステムが作成されるため、真にモジュール式のコードを記述できます。これにより、リポジトリで変数、関数、コンポーネントを検索できます。さらに、それらを探している人がそれらの存在を知っているかどうかに関係なく、検索できます。さらに、最小限のコンテンツを別々のフォルダーに保持するのに役立ちます。これにより、コンテンツの操作が簡単になります。



このフォルダ構造を適用し始めたとき、そのような構造の一貫した適用を保証するという課題に直面しました。さまざまなパッケージを操作する場合、開発者はこれらのパッケージのフォルダーにさまざまなフォルダーを作成し、これらのフォルダー内のファイルをさまざまな方法で整理することができます。必ずしも悪いことではありませんが、そのようなまとまりのないアプローチは混乱を招きます。上記の構造を体系的に適用できるように、「ファイルシステムリンター」と呼ばれるものを作成しました。これについては今から話します。

スタイルガイドが適用されていることをどのように確認しますか？

プロジェクトでは、ファイルとフォルダーの構造の統一に努めました。コードについても同じことを実現したかったのです。その時までに、プロジェクトのjQueryバージョンで同様の問題を解決することに成功した経験がありましたが、特にCSSに関しては、改善すべき点がたくさんありました。その結果、スタイルガイドを一から作成し、リンターと一緒に使用することにしました。リンターで施行できなかったルールは、コードレビュー中に管理されました。



モノリポジトリでのリンターの設定は、他のリポジトリと同じ方法で行われます。これは、1回のリンター実行でリポジトリ全体をチェックアウトできるので便利です。リンターに慣れていない場合は、ESLintとStylelintをご覧になることをお勧めします。私たちはそれらを正確に使用します。



JavaScriptリンターの使用は、次の状況で特に役立つことが証明されています。

• コンテンツのアクセシビリティを念頭に置いて構築されたコンポーネントが、対応するHTMLの代わりに使用されるようにします。スタイルガイドを作成する際に、リンク、ボタン、画像、アイコンのアクセス可能性に関するいくつかのルールを導入しました。次に、コードでこれらのルールを適用し、将来、それらを忘れないようにする必要がありました。これは、eslint-plugin-reactのreact / forbid- elementsルールを使用して行いました。

これがどのように見えるかの例です：

'react/forbid-elements': [
    'error',
    {
        forbid: [
            {
                element: 'img',
                message: 'Use "<Image>" instead. This is important for accessibility reasons.',
            },
        ],
    },
],

• . , , , , . import/no-restricted-paths eslint-plugin-import.

JavaScriptとCSSのリンティングに加えて、独自の「ファイルシステムリンター」もあります。私たちが選んだフォルダ構造の均一な使用を保証するのは彼です。これは自分で作成したツールなので、別のフォルダ構造に切り替えることにした場合は、いつでもそれに応じて変更できます。ファイルやフォルダを操作するときに制御するルールの例を次に示します。

• コンポーネントのフォルダ構造を確認します。フォルダと同じ名前のファイルindex.tsと.tsx.fileが常に存在することを確認します。
• ファイルの検証package.json：パッケージごとにそのようなファイルが1つあり、パッケージが誤って公開privateさtrueれないようにプロパティが設定されていることを確認します。

どのタイプのシステムを選択する必要がありますか？

今日、このセクションのタイトルにある質問への答えは、おそらく多くの人にとって非常に簡単です。TypeScriptを使用する必要があります。場合によっては、プロジェクトのサイズに関係なく、TypeScriptを実装すると開発が遅くなることがあります。しかし、これはコードの品質と厳密さを改善するために支払う妥当な価格であると私たちは信じています。



残念ながら、私たちがプロジェクトに取り組み始めたとき、prop-typesシステムはまだ非常に広く使用されていました。..。作業の開始時にはこれで十分でしたが、プロジェクトが成長するにつれて、コンポーネントではないエンティティの型を宣言する機能を失い始めました。これにより、たとえば、レデューサーやセレクターの改善に役立つことがわかりました。ただし、プロジェクトに別のタイピングシステムを導入するには、コードベース全体をタイピングするために多くのコードリファクタリングが必要になります。



結局、私たちはプロジェクトにタイプサポートを装備しましたが、最初にFlowを試すという間違いを犯しました。..。Flowはプロジェクトに統合する方が簡単であるように思われました。それは事実でしたが、私たちは定期的にフローに関してあらゆる種類の問題を抱えていました。このシステムはIDEとうまく統合できませんでした。不明な理由でバグが検出されなかった場合もあり、汎用タイプの作成は本当に悪夢でした。これらの理由から、すべてをTypeScriptに移行することになりました。私たちが今知っていることを知っていれば、すぐにTypeScriptを選択します。



TypeScriptが近年開発された方向性により、この移行は私たちにとって非常に簡単でした。TSLintからESLintへの移行は、私たちにとって特に役に立ちました。

コードをテストするにはどうすればよいですか？

私たちがプロジェクトに取り組み始めたとき、どのテストツールを選択するかはあまり明確ではありませんでした。今考えてみると、ユニットテストと統合テストでは、それぞれジェストとサイプレスを使用するのが最善だと思います。これらのツールは十分に文書化されており、使いやすいです。唯一の残念な点は、サイプレスがFetch APIをサポートしていないことです。悪い点は、このツールのAPIがasync / await構文を使用するように設計されていないことです。ヒノキを使い始めてすぐにはわかりませんでした。しかし、近い将来、状況が改善されることを願っています。



最初は、ユニットテストを書くための最良の方法を見つけるのは困難でした。時間の経過とともに、スナップショットテスト、テストレンダラー、浅いレンダラーなどのアプローチを試してきました。テストライブラリを試してみました。最終的には浅いレンダリングになり、コンポーネントの出力をテストするために使用され、テストレンダリングを使用してコンポーネントの内部ロジックをテストしました。



テストライブラリは、小規模なプロジェクトに適したソリューションであると確信しています。しかし、このシステムがDOMレンダリングに依存しているという事実は、ベンチマークのパフォーマンスに大きな影響を与えます。また、その批判は非常に「深い」コンポーネントに関しては、サーフェスレンダリングを使用したスナップショットテストは関係ありません。私たちにとって、スナップショットは、コンポーネントを出力するためのすべての可能なオプションをチェックするのに非常に役立つことがわかりました。ただし、コンポーネントコードは過度に複雑にしないでください。読みやすくするように努める必要があります。これは、コンポーネントを小さくtoJSONし、スナップショットに関係のないコンポーネント入力のメソッドを定義することで実現できます。



ユニットテストを忘れないように、テストによるコードカバレッジしきい値を設定します..。冗談で、これは非常に簡単で、考えることはあまりありません。テストによってグローバルコードカバレッジのインジケータを設定するだけで十分です。そのため、作業の開始時に、この数値を60％に設定しました。時間の経過とともに、コードベースのテストカバレッジが拡大するにつれて、80％に増加しました。テストで100％のコードカバレッジを目指して努力する必要はないと考えているため、この指標には満足しています。テストでこのレベルのコードカバレッジを達成することは、私たちには現実的ではないようです。

新しいプロジェクトの作成を簡素化する方法は？

通常、Reactアプリケーションの作業の開始は非常に簡単ですReactDOM.render(<App />, document.getElementById(‘#root’));。ただし、SSR（サーバー側レンダリング、サーバーレンダリング）をサポートする必要がある場合、このタスクはより複雑になります。さらに、アプリケーションの依存関係にReact以外のものが含まれている場合、クライアントとサーバーのコードで異なるパラメーターを使用する必要がある場合があります。たとえば、国際化にはreact-intl、グローバル状態管理にはreact- redux、ルーティングにはreact-router、非同期アクションの管理にはredux-sagaを使用します。これらの依存関係には、いくつかの調整が必要です。これらの依存関係を構成するプロセスは難しい場合があります。



この問題に対する私たちの解決策は、「戦略」と「抽象ファクトリー」の設計パターンに基づいていました。以前は、2つの異なるクラス（2つの異なる戦略）を作成していました。1つはクライアント構成用で、もう1つはサーバー構成用です。これらのクラスは両方とも、名前、ロゴ、レデューサー、ルート、デフォルト言語、sagas（redux-sagaの場合）などを含む、作成されたアプリケーションのパラメーターを受け取りました。レデューサー、ルート、サガは、モノリポジトリのさまざまなパッケージから取得できます。次に、この構成を使用して、reduxストア、sagasミドルウェア、ルーター履歴オブジェクトを作成します。また、翻訳をロードしたり、アプリケーションをレンダリングしたりするためにも使用されます。たとえば、クライアントとサーバーの戦略の署名は次のとおりです。

type BootstrapConfiguration = {
  logo: string,
  name: string,
  reducers: ReducersMapObject,
  routes: Route[],
  sagas: Saga[],
};
class AbstractBootstrap {
  configuration: BootstrapConfiguration;
  intl: IntlShape;
  store: Store;
  rootSaga: Task;
abstract public run(): void;
  abstract public render<T>(): T;
  abstract protected createIntl(): IntlShape;
  abstract protected createRootSaga(): Task;
  abstract protected createStore(): Store;
}
//   
class WebBootstrap extends AbstractBootstrap {
  constructor(config: BootstrapConfiguration);
  public render<ReactNode>(): ReactNode;
}
//   
class ServerBootstrap extends AbstractBootstrap {
  constructor(config: BootstrapConfiguration);
  public render<string>(): string;
}

コードが実行される環境に応じて、ストレージ、サガ、国際化オブジェクト、および履歴の設定にいくつかの違いがあるため、この戦略の分離が役立つことがわかりました。たとえば、クライアント上のreduxストアは、サーバーからプリロードされたデータとredux-devtools-extensionを使用して作成されます。これはサーバーでは必要ありません。もう1つの例は、クライアントではnavigator.languagesから、サーバーではAccept-LanguageHTTPヘッダーから現在の言語を取得する国際化オブジェクトです。



私たちがこの決定に至ったのはずっと前のことであることに注意することが重要です。クラスはまだReactアプリケーションで広く使用されていましたが、アプリケーションのサーバー側レンダリングを実行するための簡単なツールはありませんでした。時間の経過とともに、Reactライブラリは機能的なスタイルに向けて一歩を踏み出し、Next.jsのようなプロジェクトが登場しました。このことを念頭に置いて、同様の問題の解決策を探している場合は、現在の技術を調査することをお勧めします。これにより、おそらく、使用しているものよりも単純で機能的なものを見つけることができます。

コードの品質を高レベルに保つにはどうすればよいですか？

リンター、テスト、タイプチェック-これらはすべて、コードの品質に有益な効果をもたらします。しかし、プログラマーは、ブランチにコードを含める前に、適切なチェックを実行することを簡単に忘れることができますmaster。最善の方法は、このようなチェックを自動的に実行することです。一部の人々は、Gitフックを使用してすべてのコミットでこれを行うことを好みます。、コードがすべてのチェックに合格するまでコミットできません。しかし、このアプローチでは、システムがプログラマーの作業に干渉しすぎると考えています。結局のところ、たとえば、特定のブランチでの作業には数日かかる場合があり、これらすべての日は、リポジトリへの送信に適しているとは認識されません。したがって、継続的な統合システムを使用してコミットをチェックします。マージ要求に関連付けられているブランチのコードのみがチェックされます。これにより、失敗することが保証されているチェックの実行を回避できます。これは、これらの結果がすべてのチェックに合格できることが確実な場合に、プロジェクトのメインコードに作業の結果を含めるように要求することがほとんどだからです。



自動コード検証のフローは、依存関係のインストールから始まります。続いて、タイプチェック、リンターの実行、ユニットテストの実行、アプリケーションの構築、およびヒノキテストの実行が行われます。これらのタスクのほとんどすべてが並行して実行されます。これらのステップのいずれかでエラーが発生すると、チェックアウトプロセス全体が失敗し、対応するブランチをメインプロジェクトコードに含めることができなくなります。これは、機能するコードレビューシステムの例です。





自動コード検証



このシステムのセットアップ中に遭遇した主な問題は、チェックの実行を高速化することでした。このタスクはまだ関連しています。多くの最適化を実行しましたが、これらのチェックはすべて約20分で安定しています。おそらく、この指標は、いくつかのヒノキテストの実行を並列化することで改善できますが、今のところ私たちに適しています。

結果

大規模なReactアプリケーションの開発を整理するのは簡単な作業ではありません。それを解決するには、プログラマーは多くの決定を下す必要があり、多くのツールを構成する必要があります。同時に、そのようなアプリケーションをどのように開発するかという質問に対する単一の正しい答えはありません。



私たちのシステムはこれまでのところ私たちに合っています。それについて話すことが、私たちが直面したのと同じタスクに直面している他のプログラマーに役立つことを願っています。私たちの例に従うことにした場合は、最初に、ここで説明したことがあなたとあなたの会社にとって正しいことを確認してください。最も重要なことは、ミニマリズムに努めることです。アプリやツールキットの作成に使用したものを過度に複雑にしないでください。



大規模なReactプロジェクトの開発を組織化するタスクにどのようにアプローチしますか？