Wieloframeworkowa architektura wysp w Astro: React, Vue i Svelte w jednym projekcie

Kluczem do sukcesu jest zrozumienie, kiedy wieloframeworkowość jest narzędziem, a kiedy długiem technicznymDług techniczny to koszt przyszłych zmian wynikający z decyzji, które dziś przyspieszają wdrożenie, ale później zwiększają złożoność utrzymania.. Ten artykuł rozbraja tę granicę dla CTO, tech leadów i zespołów frontendowych rozważających Astro jako warstwę łączącą istniejące komponenty albo różne kompetencje w organizacji.

Jak Astro miesza frameworki

Astro obsługuje frameworki przez integracje, ponieważ w konfiguracji możesz dodać React, Vue i Svelte:

// astro.config.ts
import { defineConfig } from 'astro/config'
import react from '@astrojs/react'
import vue from '@astrojs/vue'
import svelte from '@astrojs/svelte'
 
export default defineConfig({
  integrations: [react(), vue(), svelte()],
})

Potem importujesz komponenty w pliku .astro:

---
import ReactForm from '../components/ReactForm.tsx'
import VueConfigurator from '../components/VueConfigurator.vue'
import SvelteChart from '../components/SvelteChart.svelte'
---
 
<ReactForm client:load />
<VueConfigurator client:idle />
<SvelteChart client:visible />

Kluczowe ograniczenie: pliki komponentów frameworka pozostają komponentami swojego frameworka. Reactowy komponent nie miesza w środku Vue, a komponent Svelte nie importuje bezpośrednio komponentu React. Plik .astro jest warstwą kompozycji i jest to jedyne miejsce, gdzie frameworki spotykają się na jednej stronie.

Dyrektywy hydratacji

Dyrektywy client:* decydują, kiedy komponent przechodzi hydratacjęHydratacja polega na podłączeniu kodu JavaScript do HTML-a wyrenderowanego wcześniej, aby fragment strony stał się interaktywny. i dostaje JavaScript w przeglądarce:

• client:load hydratuje natychmiast po załadowaniu strony,
• client:idle czeka, aż przeglądarka będzie mniej zajęta,
• client:visible hydratuje po wejściu komponentu w viewport,
• client:media hydratuje po spełnieniu media query,
• client:only renderuje komponent wyłącznie po stronie klienta, pomijając SSRSSR, czyli Server-Side Rendering, to generowanie HTML na serwerze przy żądaniu — komponent client:only je pomija i renderuje się wyłącznie w przeglądarce. całkowicie — komponent nie dostaje nawet renderowania do HTML.

Koszt runtime

Wieloframeworkowość nie jest darmowa, ale jej koszt pozostaje pod Twoją pełną kontrolą. RuntimeRuntime frameworka to kod biblioteki potrzebny w przeglądarce do uruchamiania i aktualizowania interaktywnych komponentów. danego frameworka trafia do przeglądarki wyłącznie wtedy, gdy świadomie hydratujesz przypisaną do niego wyspę. Jeśli komponent ma pozostać statyczny, klient nie pobiera ani jednego bajta JavaScriptu — i to właśnie ta fundamentalna różnica architektoniczna oddziela Astro od klasycznego SPASPA (Single Page Application) to aplikacja webowa, w której cała strona renderuje się i działa po stronie przeglądarki w jednym dokumencie HTML — typowe podejście Reacta, Vue czy Angulara bez SSR..

Praktyczna zasada:

• jedna wyspa React z client:load oznacza runtime React na stronie,
• wiele wysp React współdzieli ten sam runtime,
• statyczny komponent React bez client:* renderuje HTML,
• trzy frameworki na jednej stronie mają sens tylko wtedy, gdy każda wyspa uzasadnia swój koszt.

Gdzie to działa najlepiej

Najlepsze scenariusze to:

• migracja przyrostowa z legacy Vue do React albo odwrotnie,
• dokumentacja techniczna z interaktywnymi przykładami,
• strony marketingowe z pojedynczymi komponentami produktu,
• organizacje, w których kilka zespołów utrzymuje różne fragmenty UI,
• użycie gotowej biblioteki, najlepszej w jednym frameworku.

Gdzie zaczyna się dług

Wieloframeworkowość zamienia się w dług techniczny dokładnie w momencie, gdy przestaje być narzędziem migracji i staje się stylem pracy. Zaczyna się chaos, bo trzy frameworki to trzy sposoby testowania, trzy zestawy konwencji, różne biblioteki formularzy i różne wzorce stanu — wszystkie utrzymywane równolegle.

Wdrażamy jeden framework tam, gdzie jest to możliwe, ponieważ wielość frameworków uzasadnia się tylko przez konkretny problem. Szczególnie uważaj w sytuacjach, kiedy:

• komponenty muszą współdzielić dużo stanu,
• zespół ma już spójny stack i nie potrzebuje migracji,
• każdy nowy komponent powstaje w innym frameworku bez kryterium,
• nie masz budżetu performance dla hydratowanych wysp,
• debugowanie przepływu danych zaczyna wymagać znajomości kilku ekosystemów.

W takich sytuacjach lepszy będzie jeden framework aplikacyjny albo Next.js z jasno rozdzielonymi Server i Client Components. Ten temat rozwijam w artykule jak server-first Next.js wpływa na SEO i performance.