そのため、会社のアプリをマイクロフロントエンドアプローチに移行することに取り組んでいます。https://micro-frontends.org/で説明されている標準に従っています。現在、内部ではすべてが React を使用していますが、将来的にフレームワークにとらわれない自由と柔軟性が得られるように、Web コンポーネントでラップしています。私たちは動作するアーキテクチャを稼働させており、これまでのところうまく機能しています。オブジェクト、配列、さらには関数を含む React のような props を Web コンポーネントに渡すことを可能にする、Web コンポーネント仕様の上に素晴らしい互換性レイヤーを作成しました。これにより、それらの間のより良い相互作用が可能になります。
私たちが現在抱えている主な懸念は、ライブラリの重複です。私たちは React ショップなので、このフレームワークにとらわれないアプローチを取っていますが、すべて React を使用しています。この新しいアプローチにより、アプリの一部を (最終的に) 新しい React バージョンに個別にアップグレードできるようになりますが、React ライブラリの重複が多すぎるという考えはまだ好きではありません。
概観すると、Gzip で圧縮されたものでも、React/ReactDOM は 40kb を超えています。それは個々に非常に小さいですが、スケールアップすると、ますます多くの帯域幅を占有し始めます. RAMに関してはそれほど問題ではなく、これらのライブラリの場合は約130kbであり、ほとんどのデバイスのRAM容量を考えると、今では大したことではありません.
しかし、もちろん、可能な限り最適化され、合理化されることを望んでいます。だから私は誰かがマイクロ フロントエンド アプリ (Web コンポーネントにラップされたアプリ) が親アプリから React やその他のライブラリを取得できる方法を提案できることを願っています。
親アプリの JavaScript は、マイクロ フロントエンドの前に読み込まれることを知っておく必要があります。各マイクロフロントエンドは<script>タグを介してロードされます。最後に、現時点では Shadow DOM を使用していません。これは、既存のコードを新しいマイクロ フロントエンド アーキテクチャに移行する方法を改善するために行ったトレードオフです。