シングルスパ: 追加のマイクロフロントエンドを使用しないルート

この記事では、専用のエラー ページ マイクロフロントエンドを削除して、単一スパのマイクロフロントエンド アーキテクチャを簡素化する方法を検討します

マイクロフロントエンド アーキテクチャに基づいたプロジェクトには利点もありますが、いくつかの課題もあります。

課題の 1 つは、マイクロフロントエンドの数が必然的に増加することです。この増加は、より多くのマイクロフロントエンドを維持、更新、リリースする必要があることを意味します。マイクロフロントエンドの数を減らすと、開発エクスペリエンスがよりスムーズになります。

マイクロフロントエンドの数を減らすために、既存の機能の一部を既存のマイクロフロントエンドに移行できます。単一責任の原則を破ることになるため、これは慎重に行う必要があります。

エラー ページを表示するという唯一の目的を持つマイクロフロントエンドを削除できたらどんなに素晴らしいでしょうか?

シングルスパでの 404 マイクロフロントエンドの削除

シングルスパで、React で書かれた 404 ページを追加するには、404 エラーを表示する別のアプリケーション マイクロフロントエンドが必要です。

通常、これはレイアウト定義で行われます:

<route default>
    <application name="error-microfrontend"></application>
</route>

error-microfrontend を取り除くのは難しい場合があります。

A) HTML に反応するリファクタリング?

単一スパのルートは HTML で定義されます。つまり、React コンポーネントをレンダリングする場合、すべてのロジックを含めるのは困難です (特にコンポーネントでカスタム ロジックを使用する場合)。したがって、これは実行可能なオプションではありません。

B) CustomProps を渡す?

customProps を既存のマイクロフロントエンドに渡して、既存のマイクロフロントエンドに置き換えることもできます。

// top-level layout engine API
const singleSpaRoutes = constructRoutes(template, {
    props: {
        errorPage: true
    },
    loaders: {},
});

...

// single-spa-template
<route path="/test">
    <application name="global-microfrontend"></application>
</route>

<route default>
    <application name="global-microfrontend" customProps="errorPage"></application>
</route>

何らかの理由で、これは機能しません。 global-micrfrontend では、customProps にアクセスできません。

これと同じことを行う複数の方法を試してみましたが、global-microfrontend のloadRootComponent も変更しました。

const lifecycles = singleSpaReact({
    React,
    ReactDOM,
    loadRootComponent: (props) => {
        console.log(props);

        return Promise.resolve(() => <Root />);
    },
});

これも機能しませんでしたが、constructApplications の戻り値を見ると次のようになります。これは奇妙です。

// usage
const applications = constructApplications({
    loadApp: ({ name }) => globalThis.System.import(name),
    routes,
});

// result
...
name: 'global-microfrontend',
app: f(),
customProps: f(e, n),
activeWhen: [
    0: f $(),
    1: f(n)

]

single-spa は、global-microfrontend が 2 つのルートにマウントされ、そのうちの 1 つはカスタム props でマウントされることを認識しているようです。

シングルスパがプロップをマージする方法のため、この方法は機能しないと思います。

C) 巧妙な方法?

何も機能せず、マイクロフロントエンドのエラーを本当に取り除きたかったので、次の回避策を考え出しました。

// single-spa-template
<route default>
    <div id="PAGE_NOT_FOUND"></div>
</route>

アプリケーションの最上位にロードされる global-microfrontend 内:

import React, { useEffect, useState } from "react";

const ErrorContent = () => (
    <div>
        <h1>404 not found</h1>
        <h3>Please try visiting another page</h3>
    </div>
);

const ErrorPage = () => {
    const [visible, setVisible] = useState<boolean>(false);

    const checkForPageNotFound = () => {
        const el = document.getElementById("PAGE_NOT_FOUND");

        setVisible(!!el);
    };

    useEffect(() => {
        window.addEventListener("single-spa:routing-event", checkForPageNotFound);

        checkForPageNotFound();

        return () => window.removeEventListener("single-spa:routing-event", checkForPageNotFound);
    }, []);

    return visible ? <ErrorContent /> : null;
};

export default ErrorPage;

これは、single-spa:routing-event イベントをリッスンすることで機能し、イベントが発生するたびに、レイアウト定義に追加した div が存在するかどうかを確認します。 div はデフォルト ルートでのみレンダリングされるため、これは、404 ページのコンテンツを自信を持ってレンダリングできることを意味します。

これは最も洗練されたソリューションではないかもしれませんが、既存のマイクロフロントエンド内に 404 ロジックをカプセル化し、メンテナンスが必要な別のマイクロフロントエンドを取り除くことができます。

マイクロフロントエンドに基づいてアーキテクチャを簡素化するための他の創造的なソリューションを見つけた場合は、ぜひその経験について聞きたいです!

以上がシングルスパ: 追加のマイクロフロントエンドを使用しないルートの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。