Hilft dabei, Astro v6 Projekte nach einer HTML-zuerst und Islands-Architektur zu planen. Der Prompt legt Regeln für Komponenten, Hydration, Serverlogik, Zustand, Performance und Projektstruktur fest.
Diese Uebersetzung dient nur dem Verstaendnis. Zum Verwenden, Kopieren, Ausfuehren und Herunterladen bleibt der Originalprompt massgebend.
# Astro v6 Architekturregeln (Strikter Modus) ## 1. Grundphilosophie - Folge dem Prinzip von Astro: HTML zuerst und standardmaessig kein JavaScript: - Alles ist statisches HTML, ausser Interaktivitaet ist ausdruecklich erforderlich. - JavaScript ist ein Kostenfaktor, fuege es nur hinzu, wenn es echten Nutzen fuer Benutzende schafft. - Denke immer in Islands Architecture: - Die Seite ist statisches HTML. - Interaktive Teile sind isolierte Islands. - Behandle nie die ganze Seite als App. - Frage dich vor jedem JavaScript immer: "Kann dies mit HTML und CSS oder mit serverseitiger Logik geloest werden?" --- ## 2. Komponentenmodell - Verwende `.astro` Komponenten fuer: - Layout - Komposition - Statische Benutzeroberflaeche - Datenabruf - Serverseitige Logik im Frontmatter - `.astro` Komponenten: - Laufen zur Build-Zeit oder serverseitig. - Liefern standardmaessig kein JavaScript aus. - Muessen frameworkunabhaengig bleiben. - Verwende NIE React, Vue oder Svelte Hooks innerhalb von `.astro`. --- ## 3. Islands (interaktive Komponenten) - Verwende Framework-Komponenten wie React, Vue oder Svelte nur fuer Interaktivitaet. - Behandle jede interaktive Komponente als isolierte Island: - Unabhaengig - In sich geschlossen - Mit minimalem Umfang - NIE: - Ganze Seiten oder Layouts hydrieren. - Grosse Baeume in eine einzelne Island einpacken. - Unnoetig viele kleine Islands in Schleifen erstellen. - Bevorzuge: - Statisches Rendern von Listen. - Hydriere nur die kleinste interaktive Einheit. --- ## 4. Hydrationsstrategie (kritisch) - Definiere Hydration immer ausdruecklich mit `client:*` Direktiven. - Waehle die niedrigst moegliche Prioritaet: - `client:load` → Nur fuer kritische Interaktivitaet oberhalb des sichtbaren Bereichs. - `client:idle` → Fuer sekundaere Benutzeroberflaeche nach dem Laden der Seite. - `client:visible` → Fuer Komponenten unterhalb des sichtbaren Bereichs oder schwere Komponenten. - `client:media` → Fuer responsive oder bedingte Benutzeroberflaeche. - `client:only` → NUR wenn SSR bricht, etwa wegen `window` oder `localStorage`. - Standardregel: ❌ Nie standardmaessig `client:load` verwenden. ✅ Bevorzuge `client:visible` oder `client:idle`. - Hydration ist ein Performance-Budget: - Jede Island fuegt JavaScript hinzu. - Halte das gesamte JavaScript minimal. 📌 Astro hydriert Komponenten NICHT, ausser es wird ausdruecklich ueber `client:*` angegeben :contentReference[oaicite:0]{index=0} --- ## 5. Serverlogik gegenueber Clientlogik - Bevorzuge serverseitige Logik innerhalb des `.astro` Frontmatters fuer: - Datenabruf - Transformationen - Filtern und Sortieren - Abgeleitete Werte - Verwende clientseitigen Zustand nur, wenn: - Benutzerinteraktion ihn erfordert. - Echtzeitaktualisierungen noetig sind. - Vermeide: - Logik auf dem Client zu duplizieren. - Serverlogik in Islands zu verschieben. --- ## 6. Zustandsverwaltung - Vermeide Clientzustand, ausser er ist strikt notwendig. - Falls noetig: - Begrenze den Zustand auf die Island. - Erzeuge keinen globalen App-Zustand, ausser er ist erforderlich. - Fuer Zustand ueber mehrere Islands hinweg: - Verwende leichtgewichtige gemeinsame Stores, zum Beispiel Nano Stores. - Vermeide standardmaessig schwere globale Zustandssysteme. --- ## 7. Performance-Vorgaben (harte Regeln) - Minimiere JavaScript, das an den Client ausgeliefert wird: - Astro laedt JavaScript nur fuer hydrierte Komponenten :contentReference[oaicite:1]{index=1} - Bevorzuge: - Statisches Rendering - Partielle Hydration - Lazy Hydration - Vermeide: - Grosse Listen zu hydrieren. - Wiederholte Islands in Schleifen. - Uebermaessigen Einsatz von `client:load`. - Jede Island: - Hat ihr eigenes Bundle. - Laedt unabhaengig. - Sollte klein und fokussiert bleiben :contentReference[oaicite:2]{index=2} --- ## 8. Datei- und Projektstruktur - `/pages` - Einstiegspunkte fuer SSG oder SSR. - Keine Clientlogik. - `/components` - Gemeinsame Benutzeroberflaeche. - Islands liegen hier. - `/layouts` - Nur statische Wrapper. - `/content` - Markdown oder CMS-Daten. - Halte `.astro` Dateien auf Komposition fokussiert, nicht auf Verhalten. --- ## 9. Anti-Patterns (streng verboten) - ❌ Hooks in `.astro` verwenden. - ❌ Astro in eine SPA-Architektur verwandeln. - ❌ Ganze Layouts oder Seiten hydrieren. - ❌ `client:load` ueberall verwenden. - ❌ Listen in hydrierte Komponenten mappen. - ❌ Client-JavaScript fuer statische Probleme verwenden. - ❌ Serverlogik durch Clientlogik ersetzen. --- ## 10. Bevorzugte Muster - ✅ Static-first Rendering. - ✅ Minimale, isolierte Islands. - ✅ Lazy Hydration mit `visible` und `idle`. - ✅ Serverseitige Berechnung. - ✅ HTML und CSS vor JavaScript. - ✅ Progressive Enhancement. --- ## 11. Entscheidungsrahmen (sehr wichtig) Fuer jede Funktion: 1. Kann dies statisches HTML sein? → JA → Verwende `.astro`. 2. Erfordert es Interaktion? → NEIN → Bleibe statisch. 3. Erfordert es JavaScript? → JA → Erstelle eine Island. 4. Wann soll es laden? → Waehle die niedrigste `client:*` Prioritaet. --- ## 12. Denkmodell (nicht verhandelbar) - Astro ist NICHT: - Next.js - Ein SPA-Framework - Ein React-first System - Astro IST: - Ein Static-first Renderer. - Ein System fuer partielle Hydration. - Eine performanceorientierte Architektur. - Denke: ❌ Eine App bauen. ✅ HTML ausliefern und etwas JavaScript darueberstreuen.# Astro v6 Architecture Rules (Strict Mode)
## 1. Core Philosophy
- Follow Astro’s “HTML-first / zero JavaScript by default” principle:
- Everything is static HTML unless interactivity is explicitly required.
- JavaScript is a cost → only add when it creates real user value.
- Always think in “Islands Architecture”:
- The page is static HTML
- Interactive parts are isolated islands
- Never treat the whole page as an app
- Before writing any JavaScript, always ask:
"Can this be solved with HTML + CSS or server-side logic?"
---
## 2. Component Model
- Use `.astro` components for:
- Layout
- Composition
- Static UI
- Data fetching
- Server-side logic (frontmatter)
- `.astro` components:
- Run at build-time or server-side
- Do NOT ship JavaScript by default
- Must remain framework-agnostic
- NEVER use React/Vue/Svelte hooks inside `.astro`
---
## 3. Islands (Interactive Components)
- Only use framework components (React, Vue, Svelte, etc.) for interactivity.
- Treat every interactive component as an isolated island:
- Independent
- Self-contained
- Minimal scope
- NEVER:
- Hydrate entire pages or layouts
- Wrap large trees in a single island
- Create many small islands in loops unnecessarily
- Prefer:
- Static list rendering
- Hydrate only the minimal interactive unit
---
## 4. Hydration Strategy (Critical)
- Always explicitly define hydration using `client:*` directives.
- Choose the LOWEST possible priority:
- `client:load`
→ Only for critical, above-the-fold interactivity
- `client:idle`
→ For secondary UI after page load
- `client:visible`
→ For below-the-fold or heavy components
- `client:media`
→ For responsive / conditional UI
- `client:only`
→ ONLY when SSR breaks (window, localStorage, etc.)
- Default rule:
❌ Never default to `client:load`
✅ Prefer `client:visible` or `client:idle`
- Hydration is a performance budget:
- Every island adds JS
- Keep total JS minimal
📌 Astro does NOT hydrate components unless explicitly told via `client:*` :contentReference[oaicite:0]{index=0}
---
## 5. Server vs Client Logic
- Prefer server-side logic (inside `.astro` frontmatter) for:
- Data fetching
- Transformations
- Filtering / sorting
- Derived values
- Only use client-side state when:
- User interaction requires it
- Real-time updates are needed
- Avoid:
- Duplicating logic on client
- Moving server logic into islands
---
## 6. State Management
- Avoid client state unless strictly necessary.
- If needed:
- Scope state inside the island only
- Do NOT create global app state unless required
- For cross-island state:
- Use lightweight shared stores (e.g., nano stores)
- Avoid heavy global state systems by default
---
## 7. Performance Constraints (Hard Rules)
- Minimize JavaScript shipped to client:
- Astro only loads JS for hydrated components :contentReference[oaicite:1]{index=1}
- Prefer:
- Static rendering
- Partial hydration
- Lazy hydration
- Avoid:
- Hydrating large lists
- Repeated islands in loops
- Overusing `client:load`
- Each island:
- Has its own bundle
- Loads independently
- Should remain small and focused :contentReference[oaicite:2]{index=2}
---
## 8. File & Project Structure
- `/pages`
- Entry points (SSG/SSR)
- No client logic
- `/components`
- Shared UI
- Islands live here
- `/layouts`
- Static wrappers only
- `/content`
- Markdown / CMS data
- Keep `.astro` files focused on composition, not behavior
---
## 9. Anti-Patterns (Strictly Forbidden)
- ❌ Using hooks in `.astro`
- ❌ Turning Astro into SPA architecture
- ❌ Hydrating entire layout/page
- ❌ Using `client:load` everywhere
- ❌ Mapping lists into hydrated components
- ❌ Using client JS for static problems
- ❌ Replacing server logic with client logic
---
## 10. Preferred Patterns
- ✅ Static-first rendering
- ✅ Minimal, isolated islands
- ✅ Lazy hydration (`visible`, `idle`)
- ✅ Server-side computation
- ✅ HTML + CSS before JS
- ✅ Progressive enhancement
---
## 11. Decision Framework (VERY IMPORTANT)
For every feature:
1. Can this be static HTML?
→ YES → Use `.astro`
2. Does it require interaction?
→ NO → Stay static
3. Does it require JS?
→ YES → Create an island
4. When should it load?
→ Choose LOWEST priority `client:*`
---
## 12. Mental Model (Non-Negotiable)
- Astro is NOT:
- Next.js
- SPA framework
- React-first system
- Astro IS:
- Static-first renderer
- Partial hydration system
- Performance-first architecture
- Think:
❌ “Build an app”
✅ “Ship HTML + sprinkle JS”