💻 Programmierung & Entwicklung

Astro.js

📁 Programmierung & Entwicklung 👤 Beigetragen von @tuanductran 🗓️ Aktualisiert
Der Prompt
# 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”

So nutzt du diesen Prompt

Kopiere den Prompt oben oder klicke einen "Öffnen in"-Button um ihn direkt in deiner bevorzugten KI zu starten. Du kannst den Text dann an deinen Anwendungsfall anpassen — z.B. Platzhalter wie [dein Thema] durch echten Kontext ersetzen.

Welches KI-Modell funktioniert am besten

Claude Opus 4 und Sonnet 4.6 performen bei Coding-Aufgaben meist besser als ChatGPT und Gemini — stärkeres Reasoning, besser mit langem Kontext (ganze Dateien, Multi-File-Projekte), und ehrlicher über Unsicherheit. ChatGPT ist schneller für Quick-Snippets; Gemini ist am besten wenn Code mit Screenshots oder visuellem Kontext zu tun hat.

Diesen Prompt anpassen

Tausche die im Prompt erwähnte Sprache (Python, JavaScript, etc.) gegen deinen Stack. Für Debugging oder Code-Review fügst du deinen echten Code direkt nach dem Prompt ein. Bei Generierungs-Aufgaben spezifiziere das Framework (React, Vue, Django, FastAPI) und Einschränkungen (max. Zeilen, keine externen Libraries, muss async sein).

Typische Anwendungsfälle

  • Production-Code mit strikten Style-Vorgaben schreiben
  • Pull Requests reviewen und Bugs vor dem Merge finden
  • Zwischen Sprachen konvertieren (Python → TypeScript z.B.)
  • Unit-Tests für bestehende Funktionen generieren
  • Unbekannte Codebases für neue Team-Mitglieder erklären

Variationen

Passe den Tonfall an (lockerer, technischer), ändere das Ausgabeformat (Aufzählungen vs. Absätze) oder füge Einschränkungen hinzu (Wortlimits, Zielgruppe).

Verwandte Prompts