React巨大なビジネスアプリケーションのアーキテクチャ

Question

そのため、私たちは最近、巨大なビジネスWebアプリケーションを構築するためのフロントエンドテクノロジーとして、Reactを採用しました。最近言ったのは、React（AngularJSの大きな背景があります）の経験がまったくないということです。そして、巨大なアプリケーションと言うことは、たくさんあり、たくさんの非常にダイナミックなことを意味します。さまざまな部分と機能の。

すべてが非常に重要な役割を果たし、内部に複雑なロジックを持つ巨大なコンポーネントがたくさんあるので、それらを簡単にプラグインおよび再利用できるようにしたいので、それらを外の世界や他のものから可能な限り隔離する必要がありますそれ以外の場合は、サイズと複雑な機能のために、それらを開発および保守することはほとんど不可能だからです。これが、少なくとも最初はReduxを使用しないことにした理由です。これは、コンポーネントの分離を損ない、アプリケーションデータフローロジック全体が非常に複雑な場合に理解できなくなるため、個別のコンポーネントのみを開発している間ですコンポーネント。既に述べたように、Reactの経験がないため、選択が間違っている可能性があると思います。

すでに述べたように、アプリケーションは非常に動的です。つまり、コンポーネントは実際にはデータによってレンダリングされるということです。 APIエンドポイントと対話するさまざまな構成プロバイダークラスを使用して、ナビゲーション、ページ、さまざまなフォーム、リストなどの構成など、アプリケーションの構成の一部を取得し、その構成から読み取られるコンポーネントをレンダリングしようとします。

問題は、数週間Reactで勢いを得て、問題に対する正しいパターンと一般的な解決策を見つけるのに苦労した後、私たちは乗組員と話し合ってきた、おそらくReactはフレームワークではなくUIライブラリであり、あまり役に立ちませんが、ダイナミクスとコンポーネントを実現するために時々破らなければならないレンダリングルールを追加するだけなので、適切なテクノロジではありません。私たちが望む独立。

コンポーネントの分離とデータフロー管理を考慮すると、フロントエンド開発用の言語があり、エルムには非常に堅牢なデータフローアーキテクチャがあり、各コンポーネントには他とは異なる独自のモデルがありますが、私は知りません試してみる価値があるかどうかは、すぐに大きな要件に遅れることがあります。

ここでこの質問を書いているのは、巨大なフロントエンドアプリケーションでの作業に確かな背景を持つ人々から洞察を得たいと思っているからです。 Reactを使用してこのようなアプリケーションを開発できるかどうか、Reactがそのような複雑さとダイナミクスに適しているかどうか、Reduxなどが本当に必要かどうか、どのパス、プラクティス、イデオロギーが必要かを知りたい従う。あなたが私の質問を正しく理解していれば、技術的というよりも、私たちが苦労しているのはアーキテクチャ側です。たぶん、私たちはますます苦労と複雑さをもたらすが、生産への道を歩んでいるだけではありません。

flexicious.com · Answer

React/Reduxが、あなたが説明する種類のアプリケーションを開発するために使用できる（そして広く使用されている）ことは絶対にありません。説明に何も含まれていないため、構築するものが非常にユニークになるため、Reactを構築するためのプラットフォームとして使用します。 + ReactのSPA（シングルページアプリケーション）これは、2〜3年のプロジェクトで100人を超える開発者から成るチームです。

これを構成する方法は非常に重要です-

まず、UIコンポーネントライブラリを選択します。以下のいくつかの例：

コンポーネントは非常にカスタムスタイルであるため、基本的にこれらのいずれかを使用して、コンポーネントライブラリを構築しました。

次に、各モジュール（SPA）がメインコンテナコンポーネントとreduxストアを持つnpmパッケージであるモジュラーアーキテクチャを作成しました。

最後に、各サーバーが登録されている中央サーバーパッケージがあります。サーバーパッケージは、認証、承認、ログ、ルーティングなどを担当します。

この答えの本質は、大規模なReact=アプリケーションを構築する方法について助言することではなく、Reactあなたが記述しているものに似たアプリケーションを開発するために使用されます。

Jared G · Answer

あなたはあなたの質問に問題を釘付けにしました-反応はアプリケーションライブラリではなくビューライブラリです。本当の問題は、React + Redux（または他の状態管理システム）が大規模なLOBアプリに適しているかどうかです。

この領域でのチームの経験からいくつかの洞察を共有します。大規模なLOBアプリは、MVC/MVP/MVVMデザインパターンを使用して何十年も開発されてきました。これらは、ソフトウェアを出荷する試行済みの真のパターンです。それを依存性注入と組み合わせると、モジュール化された、テスト可能で保守可能なアプリケーションができます。 AngularJS（2.0+）はこれらの原則に基づいており、それらを深く活用しています。このため、すべての企業の基幹業務アプリにAngularJSを使用しています。

一方、Reactは、軽量のスプライトビューレンダリングであり、小規模なアプリケーションやクライアント向けの部分に最適です（たとえば、動的な調査や簡単なダッシュボードの取得など）。完全なAngularJSスタックはあまりにも過剰で重すぎるため、ここではしばしばReactとVueJSを使用します。

Jakob Lind · Answer

Reactでより複雑なアプリの作成を始めようとすると、本当に苦労することがあります。

あなたが言うように、ReactはUIフレームワークであり、イベントフレームワークではありません。そのため、通常、Reduxなどのイベントを処理するためのライブラリが必要です。あなたも大文字を使用していません:)）。私があなただったら、一歩下がって、その決定を再考します。 Reduxを使用しない理由は、Reduxを使用する際にコンポーネントを簡単にプラグ可能および再利用可能に保つことができないためです。私はそれが真実ではないと主張します。 Reduxは、Reactコンポーネントから完全に切り離されています。Reduxは、イベントの受信と状態の管理のみを処理します。Reactコンポーネントの観点から、通常の関数を呼び出してイベントをプロップおよび送信しますが、単体テスト、再利用なども可能です。

これを考慮して、Reduxをもう一度確認することをお勧めします。さらに質問がある場合は、お気軽にお問い合わせください！

Marfu · Answer

私は今、同様の状況にいます。私は大規模なデスクトップアプリケーション（ERP、LOB-WinForms、WPF）のバックグラウンドを持っています-1000以上のモジュール、非常に動的（UIの70％以上が入力データ/構成によって生成されました）、新しい機能の追加は構成の一部を拡張するだけでした（ソースコードに触れることなく）。

私は現在のウェブ技術を深く調査しており、Reactはそれに適していないと確信しています。Reactあなた（および他のチームメンバー）がすべてのページ/コンポーネントを（手動で）（動的に生成せずに）開発し、1つのグローバルな状態にしたい中規模のアプリケーションですが、大規模なアプリケーションをすぐに構築するのに役立ちません- UIライブラリのみであるため（モジュール、ルーティング、フォーム、バインディング、httpリクエスト、静的タイピング（TypeScript）などはサポートされていません）、驚いたことに、スタイルのシャドーイング/カプセル化はサポートされていません（統合する必要があり、たとえば、CSSモジュールなど）、最後に、ライブラリのバージョン管理を常に気にする必要があります（それらを常に連携させるには、本当に時間とエネルギーがかかります）。

Angular 2/4 +で素晴らしい経験があり、今のところ、それはその種のアプリケーションに最適なテクノロジー（WPFを知っているなら、非常に似ています）。これは完全なフレームワークであり、すぐに拡張できるように準備されています。アプリを独立したモジュールに分割し（どのコンポーネントが外部に表示されるかを指定）、すべてのコンポーネントにパブリックAPI（静的に型指定された入力/出力）とカプセル化されたcssスタイルがあります（他との干渉はありません）。グローバル状態（ログインユーザー、グローバル構成など）の場合、引き続きライブラリngrx/storeを使用できます（これはReduxパターンを実装し、「効果」などの追加の素敵なものが付属し、Angular ecosystem）。

Angular本当にクレイジーなもの（バックエンド設定からアプリケーション全体を動的に生成）でやろうとしましたが、期待通りにすべてが完全に機能しました。

Gopinath Kaliappan · Answer

React、Reduxは、複雑なアプリケーションに関しては、適切に構造化されたデータオブジェクトを作成できるため、物事を簡単にします。次に、ReactおよびそのMaterialsを使用してComplete UIを管理できます...これが正しい選択である理由はいくつかあります

状態管理、
ツリー構造データ処理、
コードを減らして、
変更が行われた場所（アクション、レデューサー）がわかります。
コンポーネントはUIの処理のみを行います

あなたがしなければならないことはデータの構造化です

Ivan Mjartan · Answer

ReactとReduxで始めるときのあなたの気持ちを完全に理解してください。当社でReact=で始めたときと同じ状況にありました。最初はReactは他のフレームワークとは異なるアプローチを持っています。もちろんフレームワークではなく、単なるライブラリです。あなたはReact方法で考え始める必要があります：Reactコンポーネントは単に状態をレンダリングします（最初にシーンを準備してからレンダリングできるようにグラフィックカードにシーンをレンダリングするようなものです）、コンポーネントができることはすべてアクションをディスパッチするか、アクションクリエーターだけを呼び出すことです。

その時点で状態を保存するためのスマートな方法が必要です。Reduxの使用をお勧めします。

また、React、Reduxの組み合わせでTypeScriptを使用します。純粋なJSよりも多くのコードを記述する必要がありますが、大規模プロジェクトで作業する場合、静的型制御は貴重です。

コンポーネントロジックの分離は、反応のネイティブアプローチです。ロジックを分離して「ダミーコンポーネント」を記述し、接続でこれを再利用する必要があります。または、小道具として値を渡します。

サンクミドルウェアをアクションクリエーターとして使用しています。接続されたコンポーネントがメソッドを呼び出すだけであり、ロジックはアクションクリエーターにあるため、これは良いことです。アプリの状態全体にアクセスでき、何かを取得して、結果に基づいてさまざまなアクションをディスパッチできます。

リアクション/リデュースで気に入っているのは、非同期呼び出しなどを実装する方法です。すべての状態をマップする最初の設計コンポーネント

1）データがないように2）データの読み込み3）読み込み完了4）読み込みエラー

そのためには、状態のセマフォが1つとrenderメソッドのいくつかのチェックだけが必要です。次に、データをロードし、進行状況を記述する進行状況ディスパッチアクションに基づいてアクションを作成する1人のアクション作成者。

また、react/reduxアプリでは、単一のデータフローがあるため、新しい開発者がプロジェクトにジャンプするときに便利です。

UIにはマテリアルUIを使用しています。はい、このフレームワークにはいくつかの問題がありますが、対処できないものはありません。

アプリ内を移動するためにルーターも使用しています。

最初は、クライアント側のレンダリングと初期状態から始める方がはるかに簡単になるため、サーバー側のレンダリングは避けます。

私たちが始めたときは、すべてが1つのプロジェクトで機能するこのテンプレートが役に立ちました JavaScriptServices

それからもちろん素晴らしい Abramov チュートリアル。

設計コンポーネントにとって非常に便利 Storybook

React長い間...を使用するかしないかを書くことができます...しかし私が言えることは...私たちにとってそれは良い選択であり、物ggingいに苦痛を伴いましたが、今では良い見返りがあります。

Janith Widarshana · Answer

フロントエンドテクノロジーとしてReactjsを使用して、大規模なビジネスアプリケーションを開始しました。チームには30人以上の従業員がおり、製品には15を超えるモジュールがあります。

私のアプローチは、プロジェクトに対する認証、承認、およびルーティングと、個別のnpm反応ライブラリとして開発された他のすべてのコンポーネントのみを処理する一般的な反応プロジェクトを開発することです。

私が使用したライブラリを開発するために https://www.npmjs.com/package/create-react-hook

このライブラリは、ライブラリのテストに使用できるサンプルアプリを含むテンプレートを生成します。

以下はプロジェクトの構造です

-ライブラリ1（create-react-hookを使用して開発）

-ライブラリ2（create-react-hookを使用して開発）

...

-ライブラリn

--Common Container App（create reactアプリを使用して開発され、npm installを使用して上記のすべてのライブラリを使用しました）

このアプローチの主な利点は、開発者がnpmパッケージのみに集中でき、関連するコンポーネントを個別に開発およびテストできることです。また、テスト済みバージョンのnpmパッケージを更新し、コンテナーアプリを再構築して、アプリケーションの他の部分に影響を与えずに展開を実行できるため、展開も非常に簡単になります。

これを数ヶ月使用し、問題なく大規模なチームでプロジェクトを実行しています。これは他の人にも役立つと思います。