In diesem Artikel untersuchen wir eine Möglichkeit, Ihre Single-Spa-Microfrontend-Architektur zu vereinfachen, indem wir das dedizierte Fehlerseiten-Microfrontend entfernen
Ein Projekt zu haben, das auf einer Microfrontends-Architektur basiert, hat seine Vorteile, aber auch einige Herausforderungen.
Eine der Herausforderungen ist das unvermeidliche Wachstum der Anzahl von Mikrofrontends. Dieses Wachstum bedeutet, dass mehr Mikrofrontends gewartet, aktualisiert und veröffentlicht werden müssen. Die Reduzierung der Anzahl der Mikrofrontends sorgt für ein reibungsloseres Entwicklungserlebnis.
Um die Anzahl der Mikrofrontends zu reduzieren, können wir einen Teil der vorhandenen Funktionalität in ein bereits vorhandenes Mikrofrontend migrieren. Wir müssen dies sorgfältig tun, da wir sonst gegen das Prinzip der Einzelverantwortung verstoßen.
Wie großartig wäre es, ein Microfrontend zu entfernen, das ausschließlich dazu dient, eine Fehlerseite darzustellen?
Um in Single-Spa eine 404-Seite hinzuzufügen, die in React geschrieben wurde, benötigen Sie ein separates Anwendungs-Microfrontend, das den 404-Fehler anzeigt.
Normalerweise erfolgt dies in der Layoutdefinition:
<route default> <application name="error-microfrontend"></application> </route>
Das Entfernen des Fehler-Microfrontends kann schwierig sein.
A) Refactoring React to HTML ?
Die Single-Spa-Routen sind in HTML definiert, was bedeutet, dass es schwierig sein wird, die gesamte Logik einzubeziehen, wenn Sie eine Reaktionskomponente rendern möchten (insbesondere, wenn Sie benutzerdefinierte Logik in Ihrer Komponente verwenden). Das ist also keine praktikable Option.
B) Übergeben von customProps ?
Sie können auch versuchen, es durch ein vorhandenes Microfrontend zu ersetzen, indem Sie ihm customProps übergeben:
// 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>
Aus irgendeinem Grund funktioniert das nicht. Auf die customProps kann in global-micrfrontend nicht zugegriffen werden.
Ich habe mehrere Möglichkeiten ausprobiert, dasselbe zu tun, und sogar die LoadRootComponent für global-microfrontend geändert:
const lifecycles = singleSpaReact({ React, ReactDOM, loadRootComponent: (props) => { console.log(props); return Promise.resolve(() => <Root />); }, });
Was auch nicht funktioniert hat, was seltsam ist, denn wenn ich mir die Rückgabe für „constructApplications“ ansehe:
// 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) ]
Es scheint, dass Single-Spa weiß, dass Global-Microfrontend auf zwei Routen gemountet wird, und eine davon mit benutzerdefinierten Requisiten.
Ich gehe davon aus, dass dieser Weg aufgrund der Art und Weise, wie Single-Spa die Requisiten zusammenführt, nicht funktioniert.
C) Hackiger Weg?
Da nichts funktionierte und ich den Fehler im Microfrontend unbedingt loswerden wollte, habe ich mir einen Workaround ausgedacht:
// single-spa-template <route default> <div id="PAGE_NOT_FOUND"></div> </route>
Im Global-Microfrontend, das auf der obersten Ebene der Anwendung geladen wird:
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;
Dies funktioniert, indem wir auf das Ereignis „single-spa:routing-event“ warten und jedes Mal, wenn es ausgelöst wird, prüfen, ob das Div, das wir in der Layoutdefinition hinzugefügt haben, vorhanden ist. Da das Div nur in der Standardroute gerendert wird, bedeutet dies, dass wir den Inhalt der 404-Seite sicher rendern können.
Obwohl dies vielleicht nicht die eleganteste Lösung ist, ermöglicht sie uns, die 404-Logik in ein vorhandenes Mikrofrontend zu kapseln und ein weiteres Mikrofrontend loszuwerden, das gewartet werden müsste.
Wenn Sie weitere kreative Lösungen zur Vereinfachung einer Architektur auf Basis von Microfrontends gefunden haben, würde ich mich über Ihre Erfahrungen freuen!
Das obige ist der detaillierte Inhalt vonSingle-Spa: Route ohne zusätzliches Microfrontend. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!