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 technicznym. 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 łączy React, Vue i Svelte na jednej stronie?

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 w wieloframeworkowej architekturze wysp

Dyrektywy client:* decydują, kiedy komponent przechodzi hydratację 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 SSR całkowicie — komponent nie dostaje nawet renderowania do HTML.

Koszt runtime wielu frameworków w Astro

Wieloframeworkowość nie jest darmowa, ale jej koszt pozostaje pod Twoją pełną kontrolą. Runtime 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 SPA.

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 wieloframeworkowe wyspy w Astro działają 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 wieloframeworkowa architektura wysp tworzy 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.