Mikrofrontendarkitektur med Module Federation · Lektion

Implementering af federeret routing

Implementér routing, hvor hver Micro Frontend håndterer sine egne routes, som integreres i en global router.

Lektion 2 af 411 trin

Implementering af federeret routing er en gratis Mikrofrontendarkitektur med Module Federation-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Mikrofrontendarkitektur med Module Federation, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Mikrofrontendarkitektur med Module Federation-kurset indeholder 4 lektioner i alt.

Hvad er federeret routing?

I en mikrofrontend-arkitektur betyder federeret routing, at hver enkelt MFE er ansvarlig for at håndtere sine egne specifikke ruter. I stedet for at én central applikation bestemmer alle ruter, erklærer hver MFE sine egne stier.

Denne tilgang giver teams større selvstændighed, så de kan udvikle og implementere routinglogik uafhængigt uden en tæt kobling til routingsystemet i en primær værtsapplikation.

Fordele ved federerede ruter

Federeret routing har flere vigtige fordele:

  • Selvstændighed: MFE-teams styrer deres egen navigation.
  • Uafhængig implementering: Ændringer i en MFE's ruter kræver ikke, at hele værtsapplikationen implementeres igen.
  • Skalerbarhed: Det bliver lettere at håndtere routinglogik, efterhånden som antallet af MFE'er vokser.
  • Teknologiuafhængighed: Forskellige MFE'er kan bruge forskellige routingbiblioteker.

Grundprincip: Ejerskab over ruter

Den grundlæggende idé bag federeret routing er, at hver mikrofrontend udgiver sit eget sæt ruter. Se det som en miniapplikation i det større system, der er ansvarlig for sin interne navigationsstruktur.

Værtsapplikationen fungerer derefter som en aggregator, der finder og integrerer disse MFE-ejede ruter i en samlet og sammenhængende routingoplevelse for brugeren.

MFE definerer lokale ruter

Sådan kan en mikrofrontend (lad os kalde den "MFE A") definere sine interne ruter. Det er specifikke stier, som MFE A er ansvarlig for at gengive.

Vi bruger en simpel array-struktur til at repræsentere ruter, hvor hver rute har en path og en komponent eller visning, som den skal gengive.

// mfe-a-routes.js
// This MFE owns routes starting with '/app-a'

export const mfeARoutes = [
  {
    path: '/app-a',
    component: 'MFE_A_Dashboard'
  },
  {
    path: '/app-a/profile',
    component: 'MFE_A_UserProfile'
  }
];

En anden MFE's ruter

Tilsvarende definerer en anden mikrofrontend ("MFE B") sit eget sæt ruter. Bemærk, hvordan dens stier er forskellige og ofte har et præfiks for at undgå konflikter, så ejerskabet er tydeligt.

Denne adskillelse gør det muligt for MFE A og MFE B at videreudvikle deres navigation uafhængigt af hinanden.

// mfe-b-routes.js
// This MFE owns routes starting with '/app-b'

export const mfeBRoutes = [
  {
    path: '/app-b',
    component: 'MFE_B_HomePage'
  },
  {
    path: '/app-b/settings',
    component: 'MFE_B_SettingsPage'
  }
];

Værten samler MFE-ruter

Værtsapplikationens rolle er at fungere som den centrale orkestrator. Den skal finde og importere rutedefinitionerne fra hver mikrofrontend.

Med Module Federation kan disse rutedefinitioner eksponeres af eksterne MFE'er og bruges af værten, så der effektivt opbygges et globalt rutekort fra distribuerede kilder.

Integration i en global router

Værtsapplikationen tager derefter alle de samlede ruter og integrerer dem i sin egen globale routerinstans. Dette eksempel simulerer, hvordan en værtsapplikation kan indlæse og behandle ruter fra forskellige MFE'er for at håndtere navigation.

Prøv at ændre variablen currentPath i koden, og kør den!

// mfe-a-routes.js (Simulated Remote MFE)
export const mfeARoutes = [
  { path: '/app-a', component: 'MFE_A_Dashboard' },
  { path: '/app-a/profile', component: 'MFE_A_UserProfile' }
];

// mfe-b-routes.js (Simulated Remote MFE)
export const mfeBRoutes = [
  { path: '/app-b', component: 'MFE_B_HomePage' },
  { path: '/app-b/settings', component: 'MFE_B_SettingsPage' }
];

// host-app.js (Main Application Entry Point)
// In a real app, these would be dynamically imported
// via Module Federation.
const allFederatedRoutes = [
  ...mfeARoutes,
  ...mfeBRoutes
];

function globalRouter(currentPath) {
  console.log(`Attempting to navigate to: ${currentPath}`);
  const matchedRoute = allFederatedRoutes.find(
    route => route.path === currentPath
  );

  if (matchedRoute) {
    console.log(`Match found! Rendering: ${matchedRoute.component}`);
  } else {
    console.log(`No route found for: ${currentPath}. Showing 404.`);
  }
}

// Simulate user navigation
console.log("--- Global Routing Simulation ---");
globalRouter('/app-a');
globalRouter('/app-b/settings');
globalRouter('/app-a/profile');
globalRouter('/unknown-path');
globalRouter('/app-b');

Problemfri navigation på tværs af MFE'er

Når værtens globale router har integreret alle federerede ruter, bliver navigationen mellem forskellige mikrofrontends problemfri. Fra brugerens perspektiv føles det som én samlet applikation.

Når en bruger klikker på et link til /app-b/settings, identificerer den globale router, at denne sti tilhører MFE B, og uddelegerer gengivelsen eller aktiveringen af MFE B i overensstemmelse hermed.

Undgå konflikter mellem ruter

Når flere MFE'er definerer ruter, kan der opstå konflikter, hvis to MFE'er definerer den samme sti (f.eks. hvis begge har en /dashboard-rute).

Almindelige strategier til at forhindre dette omfatter:

  • Navnerum: Tilføj præfikser til MFE-ruter (f.eks. /mfea/dashboard, /mfeb/dashboard).
  • Unikke stier: Sørg for, at hver MFE's ruter er unikke i sig selv.
  • Overskrivning fra værten: Giv værten mulighed for at prioritere eller omkoble ruter, der er i konflikt.

Test din forståelse

Forestil dig, at du har en værtsapplikation, der integrerer ruter fra to mikrofrontends, MFE-A og MFE-B. MFE-A definerer /products og /products/:id. MFE-B definerer /cart og /checkout.

Hvilken af følgende beskriver bedst værtsapplikationens rolle i denne federerede routingopsætning?

Opsummering: federeret routing

Du har lært om federeret routing, hvor hver mikrofrontend ejer og definerer sine egne ruter. Vi så, hvordan en værtsapplikation samler disse ruter for at skabe en samlet navigationsoplevelse.

  • Hver MFE erklærer sine egne ruter.
  • Værtsapplikationen indsamler og integrerer MFE-ruter.
  • Det sikrer MFE'ernes selvstændighed og uafhængige implementering.
  • Navnerum hjælper med at forhindre konflikter.

Denne tilgang er afgørende for MFE-systemer i stor skala, fordi den skaber balance mellem uafhængighed og en ensartet brugeroplevelse.

Gratis at komme i gang

Lær JavaScript med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser
12
Lektioner
48

Ofte stillede spørgsmål

Er lektionen “Implementering af federeret routing” gratis?

Ja — hele teksten til “Implementering af federeret routing” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Mikrofrontendarkitektur med Module Federation-kurset, skal du opgradere til CoddyKit PRO. Mikrofrontendarkitektur med Module Federation-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Implementering af federeret routing”?

Implementér routing, hvor hver Micro Frontend håndterer sine egne routes, som integreres i en global router. Du øver dig i Mikrofrontendarkitektur med Module Federation med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Mikrofrontendarkitektur med Module Federation?

Der kræves ingen tidligere erfaring. Mikrofrontendarkitektur med Module Federation på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.

Hvor lang tid tager lektionen “Implementering af federeret routing”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Mikrofrontendarkitektur med Module Federation-lektion?

Ja. Alle Mikrofrontendarkitektur med Module Federation-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

  1. Centraliseret routingstrategi
  2. Implementering af federeret routing
  3. Deep linking og URL-håndtering
  4. Håndtering af indlejret navigation og navigation på tværs af apps
← Tilbage til Mikrofrontendarkitektur med Module Federation