single-spa : itinéraire sans microfrontend supplémentaire

Dans cet article, nous explorerons un moyen de simplifier votre architecture microfrontend à spa unique en supprimant la page d'erreur dédiée au microfrontend

Avoir un projet basé sur une architecture microfrontends présente des avantages, mais aussi certains défis.

L'un des défis est la croissance inévitable du nombre de microfrontends. Cette croissance signifie qu’il y aura davantage de microfrontends à maintenir, mettre à jour et publier. La réduction du nombre de microfrontends garantit une expérience de développement plus fluide.

Afin de réduire le nombre de microfrontends, nous pouvons migrer certaines des fonctionnalités existantes vers un microfrontend déjà existant. Nous devons le faire avec précaution, car cela nous amènerait à enfreindre le principe de responsabilité unique.

Ce serait génial de supprimer une microfrontend dont le seul but est d'afficher une page d'erreur ?

Suppression du microfrontend 404 dans un spa unique

En single-spa, pour ajouter une page 404 écrite en React, vous devez disposer d'un microfrontend d'application distinct qui affiche l'erreur 404.

Habituellement, cela se fait dans la définition de la mise en page :

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

Se débarrasser du microfrontend d'erreur peut être délicat.

A) Refactoriser React to HTML ?

Les routes à spa unique sont définies en HTML, ce qui signifie que si vous souhaitez restituer un composant de réaction, il sera difficile d'inclure toute la logique (surtout si vous utilisez une logique personnalisée dans votre composant). Ce n'est donc pas une option viable.

B) Passage de customProps ?

Vous pouvez également essayer de le remplacer par une microfrontend existante en lui passant 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>

Pour une raison quelconque, cela ne fonctionne pas. Les customProps ne sont pas accessibles dans global-microfrontend.

J'ai essayé plusieurs façons de faire la même chose, même en changeant le loadRootComponent pour global-microfrontend :

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

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

Ce qui n'a pas fonctionné non plus, ce qui est étrange, car si je regarde le retour de 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)

]

Il semble que single-spa soit conscient que le microfrontend global sera monté sur 2 routes, et l'une d'entre elles avec des accessoires personnalisés.

Je suppose que cette méthode ne fonctionne pas à cause de la façon dont le spa unique fusionne les accessoires.

C) Façon piratée ?

Comme rien n'a fonctionné et que je voulais vraiment me débarrasser de l'erreur du microfrontend, j'ai trouvé une solution de contournement :

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

Dans le global-microfrontend, qui se charge au niveau supérieur de l'application :

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;

Cela fonctionne en écoutant l'événement single-spa:routing-event, et chaque fois qu'il est déclenché, nous vérifions si le div que nous avons ajouté dans la définition de mise en page existe. Étant donné que le div est rendu uniquement dans la route par défaut, cela signifie que nous pouvons restituer en toute confiance le contenu de la page 404.

Bien que ce ne soit peut-être pas la solution la plus élégante, elle nous permet d'encapsuler la logique 404 dans une microfrontend existante et de nous débarrasser d'une autre microfrontend qui nécessiterait une maintenance.

Si vous avez trouvé d'autres solutions créatives pour simplifier une architecture basée sur des microfrontends, j'aimerais connaître vos expériences !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!