最初に、フロントエンドのキーテクノロジーとしてReactを選択したとき、さまざまなフラックスの実装で多くの実験を行いました。実装を書きたくありませんでした。 altとreduxの2つの実装を見ました。 reduxは開発への機能的なアプローチを促進し、オブジェクト指向プログラミングに慣れているスタッフに多くのJava開発者がいたため、altの方が簡単であることがわかりました。 主観的な観点から見ると、これには大きな利点がありました。altには魔法のコンポーネントAltContainerが含まれており、これがインスタンス ストアをPropsを介して子コンポーネントに渡しました。 当初、これは完全に機能しました。小さなアプリケーションがあり、その中にはいくつかのストアがあり、接続されていません。 しかし、機能が増加するにつれて、このテクノロジーが私たちにとって誤りであり、アプリケーションが巨大で制御不能になっていることに気付き始めました。
すべてを支配する一つの真実
アプリケーションでのルーターの実装が検討されたとき、react-routerに依存しました。 バックエンドでは、Spring WebFlowを使用し、WebFlowで友人に反応ルーターを作りたいという要望がありました。 その結果、react-routerの実装の仕様により、何も実装することはできませんでしたが、どのように実装されるのかを探りました。 コンポーネントでアクティブな作業が開始され、最終的にSWFRouterという名前が付けられました。バックエンドはページに表示するフォームのIDを通知し、バックエンドから特別なフィールドを介してリアクションコンテキストにデータを渡しました。 テクノロジーを実験しているだけではありません。 バックエンドの開発者は、ワークフローと呼ばれる独自の開発を支持してSWFを放棄しました。 次に行うこと-SWFRouterは不要になりました。別のソリューションが必要です。 WFRouterと呼ばれるわずかに変更されたバージョンに切り替えることで、現在の実装を大幅に書き換えたくありませんでした。 しかし、彼は私たちの野心を満たすことができませんでした。 私たちは次に進むべき道を導くことができる真実の単一の情報源を必要としていました。 ルーターのことを考えるのをやめたので、少し違うコンセプトに切り替えました：ルーターなし-フラックスのみ。 altはアプリケーションの一般的なロジックの実装に適していないという結論に達し、最終的にreduxに戻りました。
reduxとは何か、どのように機能するかについては、すでに多くの記事がありますが、小さな紹介記事に焦点を当てます。 アクションがトリガーされるたびに、対応するレデューサーがトリガーされ、新しい状態が返されます。 Reduxは、いつでもアプリケーションの任意の状態に戻ることができる不変のパターンを順守しています。 とりわけ、ミドルウェアのサポートがあります。 状態更新プロセスに関数を埋め込むことができます。
reduxでのアプリケーションの切り替えが簡単になりました。特別なアクションがデータをバックエンドに送信し、次のフォームのIDまたは後続のダウンロード用にバンドルするURLを返しました。 私たちは、互いに独立して職場向けのアプリケーションを開発し、リリース時に、その後の展開のために組み立てたバンドルを転送します。 これは、異なる開発グループによって作成された個別のアプリケーションからビジネスプロセスを組み立てることができるため便利です。
タスクスケジューラがあるとします。 タスクをクリックすることで、私たちはあなたがそれを完了することができるアプリケーションに自分自身を見つけます。 必要な操作が完了したら、スケジューラに戻り、彼の状態が移行前の状態と似ていることを確認します。 タスクへの移行時に、スケジューラをメモリから完全にアンロードしましたが、その状態は永続ストレージに保存されていたため、復帰時に再びロードすることができました。 これを行うために、特別なミドルウェアを使用し、その後のストレージの状態を渡しました。
では、職場はどのように機能しますか？ 基本的に、iframeを使用するという考えを捨てました。 これにより、オーバーヘッドが発生し、ポップアップの場合の回避策が必要になります。
職場はいくつかのコンポーネントで構成されています：AppContainer-AMDモジュールを非同期的にロードするためのコンポーネント、UFSProvider-react-reduxモジュールからProviderコンポーネントのラッパーコンポーネント、ストアを作成し、レデューサーのセットを渡してアーキテクチャ全体を単一の全体に接続します。 しかし、まず最初に。
Appcontainer
小道具
- loadUrl-{ （）=> Promise <React.Component> }-Promiseを返し、React.Componentを返す関数
- defaultUrl-{ string }-デフォルトのアプリケーションURL
- defaultData-{ オブジェクト }-ロードされたアプリケーションに転送されたデータ
プロジェクトでは、フォームの数が数千を超えていました。これをモノリシックアプリケーションにするのは間違いです。 各フォームには、独自の開発、テスト、および展開サイクルがあります。 AMDはモジュラーシステムとして選択されました。各プロジェクトは、ReactコンポーネントであるAMDモジュールに独自のフォームセットをパックします。 SystemJSを使用すると、次のアプリケーションがロードされます;ロードすると、Promiseが返され、PromiseがAppContainerコンポーネントに渡されます。 ロード後、アプリケーションはAppContainer内に描画され、ロードされたアプリケーションの特別なreducerフィールドは、アプリケーションロジックを担当し、プロパティとしてUFSProviderコンポーネントに渡されるルートレデューサーを渡します。
UFSProvider
小道具
- レデューサー-{関数}-職場のロジックのレデューサー
前述のように、UFSProviderは事前に構成されたレデューサーでストアを作成します。 アプリケーションごとに個別のストアを作成するのではなく、既存のストアの一部を提供します。 ストアロジックを5つのコンポーネントに分割しました。
- appContainer-アプリケーションをロードするためにAppContainerコンポーネントによって使用されるロジック
- ワークスペース-職場のロジック、つまり アプリケーション全体のラッパー
- app-ロードされたアプリケーションのロジック
- ワークフロー- バックエンドによって指定されたバックエンドロジック
ヒント-フォームにツールチップを実装するための特別なレデューサー
AppContainerのアプリケーションが置き換えられるたびに、アプリのレデューサーのセットが置き換えられます。 必要に応じて、以前に保存された状態がinitialStateに転送されます。
ヒント
多くのアプリケーションの基本は、単純なユーザーには理解できない手がかりであり、プログラマーはそれをホイップしました。 インターフェース内のすべてのプロンプトがユーザーに理解されるように努めています。 これを行うために、ヒント用の特別な管理パネルを作成しました。 コンポーネントライブラリから、ブロック、ポップアップ、その他の特定のツールチップセットを提供します。 ライブラリレベルのそれらはすべて、状態に接続されています。 既に接続機能でラップされています。 開発者がヒントコードのみを指定すれば十分であり、テキスト自体は状態から取得されます。 それでは、どのように機能しますか？ サーバーにアクセスするたびに、応答にヒントフィールドが存在するかどうかを確認し、存在する場合はこのフィールドの内容をstateに渡すため、「接続された」コンポーネントはコードではなくテキストを受け取ります。
複数のアプリをダウンロードする
ページにアプリケーションが1つしかない場合、上記のすべてが正常に機能します。 しかし、そのようなアプリケーションを同時に2つ以上ロードする必要がある場合はどうすればよいでしょうか？ 同時に、アプリケーションは互いにデータを交換できる必要があります。 この場合、アクションごとにイベントが共有データバスに送られるようにUFSProviderを構成しました。 さらに、州の申請書を渡します。 これは、アクションと状態を特別なオブジェクトに渡す特別なミドルウェアのおかげで可能になりました。 ここで、ページにAppContainer-UFSProviderのペアをいくつか挿入し、ロジックを設定します。 アプリケーションAがアプリケーションBのイベントに応答する必要があるとします。これは、アプリケーションAがアプリケーションBのアクションをサブスクライブし、独自のロジックを実装するためです。
おそらく、これがプログラムでReduxテクノロジーについて話したいと思った主なものです。 主なことは、実験を恐れず、あなたに合ったそのようなアーキテクチャを作成することです。
この記事およびフロントエンド開発のその他の関連トピックについては、記事へのコメントでお話しします。