Cursor-Regeln für React: Der vollständige Leitfaden zur KI-gestützten React-Entwicklung

Cursor-Regeln für React: Der vollständige Leitfaden für KI-gestützte React-Entwicklung

React ist das Framework, in dem „es rendert“ die längste Lüge verbirgt. Die Komponente wird eingebunden, der Bildschirm sieht korrekt aus, und nichts im Build-Prozess verrät dir, dass das übergeordnete Element den gesamten Baum bei jedem Tastendruck neu rendert, dass ein useEffect in der Entwicklung zweimal fetcht und du es „repariert“ hast, indem du eine Abhängigkeit entfernt hast, oder dass der Context, den du genutzt hast, damit ein Blatt ein Flag lesen kann, jedes Mal 40 Geschwister neu rendert, wenn ein Token aktualisiert wird. Die App funktioniert. Eine Profiler-Trace sechs Monate später zeigt, dass die Hälfte deines Baums jedes Mal eingebunden wird, wenn sich die URL ändert, und drei „gememoisierte“ Callbacks bei jedem Render ihre Referenz ändern. Dann fügst du einen KI-Assistenten hinzu. Cursor und Claude Code wurden auf einer planetengroßen Menge an React-Code trainiert. Der Großteil davon sind Klassenkomponenten, die Hälfte davon stammt aus der Zeit vor Hooks, und ein Großteil der modernen Hälfte hat aus Blogposts gelernt, die jeden Callback aus „Performance-Gründen“ in useCallback einwickeln, ohne es zu messen. Wenn du nach „einem Formular, das einen Benutzer lädt und das Bearbeiten ermöglicht“ fragst, erhältst du eine 250-Zeilen-Komponente mit fünf useStates, einem useEffect ohne AbortController, Props, die als any typisiert sind, einem useMemo um eine String-Konkatenation und einem Context-Provider drei Ebenen höher, weil es einfacher war, als die Prop weiterzureichen. Der Code rendert. Es ist nicht der React-Code, den du ausliefern würdest. Die Lösung sind .cursorrules – eine Datei im Repository, die der KI mitteilt, wie idiomatischer moderner React-Code aussieht. Acht Regeln unten, jede mit dem Fehlermodus, der Regel und einem Vorher/Nachher. Kopiere .cursorrules am Ende.

Wie Cursor Rules für React-Projekte funktionieren

Cursor liest Projektregeln aus zwei Orten: .cursorrules (eine einzelne Datei im Repository-Root, weiterhin unterstützt) und .cursor/rules/*.mdc (modulare Dateien mit Frontmatter, empfohlen für alles, was größer ist als eine SPA). Für React empfehle ich modulare Regeln, damit die Server-Komponenten-Konventionen einer Next.js-App nicht in die Client-only-Muster einer Vite-SPA im selben Monorepo übergreifen: .cursor/rules/react-core.mdc # Komposition, Props, Dateistruktur react-hooks.mdc # useEffect-, useMemo-, useCallback-Disziplin react-state.mdc # Lokale vs. globale Zustände, Server-Zustände, Context-Bereich react-perf.mdc # Memo, Render-Bereich, Listenschlüssel react-testing.mdc # RTL, verhaltensbasiertes Testen

Frontmatter steuert die Aktivierung: globs: ["*/.tsx", "*/.jsx"] with alwaysApply: false.

Jetzt die Regeln.

Regel 1: Komposition über Konfiguration – Kinder und Slots, keine Boolean-Props

Der häufigste KI-Fehler in React ist die Boolean-Explosion. Cursor sieht Card an drei Stellen verwendet und „verallgemeinert“ es mit hasHeader, iconLeft, iconRight, variant, size und einem actions-Array. Sechs Monate später hat diese Card dreißig Props, vier davon gegenseitig ausschließend, und jede Änderung an einem Konsumenten erfordert das Berühren der gemeinsamen Komponente. Die Regel: Bevorzuge Komposition über Konfiguration. Wiederverwendbare Komponenten akzeptieren Kinder und benannte ReactNode-Slots (header, footer, actions) – keine wachsende Liste von Boolean-Toggles, Icon-Namen oder Content-Arrays. Boolean-Props sind echten Zuständen vorbehalten (disabled, loading, selected). Niemals, um zu steuern, ob ein Unterelement rendert. Für polymorphe Wrapper verwende den as-Prop oder das Render-Prop-Muster – niemals parallele linkTo / buttonHref-Props, die denselben Job erledigen.

Vorher – Boolean-Explosion: interface CardProps { title: string; hasHeader?: boolean; hasFooter?: boolean; iconLeft?: 'user' | 'cart' | 'star'; actions?: { label: string; onClick: () => void; variant: string }[]; variant?: 'default' | 'bordered' | 'elevated'; collapsible?: boolean; }

Jeder Konsument fügt ein weiteres Flag hinzu. Die Komponente wächst endlos.

Nachher – Komposition mit Slots: interface CardProps { header?: React.ReactNode; footer?: React.ReactNode; children: React.ReactNode; }

function Card({ header, footer, children }: CardProps) {
  return (

<section className="rounded-lg border bg-white shadow-sm"> {header && <header className="border-b p-4">{header}</header>} {children} {footer && <footer className="border-t p-4">{footer}</footer>} </section> );