Frontend-Komponenten-Review

Das Problem

Frontend-Komponenten starten einfach und wachsen zu verflochtenen Massen. Eine “einfache” Card-Komponente sammelt 15 Props, 3 useState-Hooks, 2 useEffect-Seiteneffekte und Inline-Styles. Props drillen durch 4 Verschachtelungsebenen, weil “Context uebertrieben wirkte.” Jeder Tastendruck in einem Suchfeld rendert 200 Listenelemente neu, weil die Filterfunktion bei jedem Render neu erstellt wird.

Der Prompt

Pruefe die folgenden Frontend-Komponenten. Handle als Frontend-Architekt, der auf Skalierbarkeit, Performance und saubere Komposition bewertet.

FRAMEWORK: [React / Vue / Svelte / Astro]
KOMPONENTENTYP: [z.B. Formular, Datentabelle, Navigation, Dashboard-Widget]

CODE:
[Komponenten-Code hier einfuegen]

Bewerte in diesen Dimensionen:

1. **Komponentenverantwortung**
   - Tut jede Komponente eine Sache (Darstellung ODER Logik)?
   - Sind Komponenten unter 150 Zeilen?
   - Sollte dies in Container (Logik) + Presentational (UI) aufgeteilt werden?

2. **Props & API**
   - Ist das Prop-Interface sauber (unter 7 Props)?
   - Drillen Props durch 3+ Ebenen (sollte Context/Store verwenden)?
   - Sind Callback-Props stabil (in useCallback gewrappt)?

3. **State Management**
   - Ist State so nah wie moeglich an der Nutzung?
   - Wird abgeleiteter State berechnet (useMemo) statt via useEffect synchronisiert?
   - Gibt es redundante State-Variablen, die aus anderen ableitbar sind?

4. **Rendering-Performance**
   - Sind Listenelemente in React.memo gewrappt?
   - Sind teure Berechnungen memoisiert?
   - Enthalten useEffect-Dependencies instabile Referenzen?

5. **Seiteneffekte**
   - Haben useEffects korrekte Cleanup-Funktionen?
   - Sind Fetch-Aufrufe dedupliziert (useSWR/React Query statt rohem useEffect)?
   - Gibt es Loading/Error/Empty-States fuer async Daten?

6. **Komposition**
   - Ist der Komponentenbaum flach oder tief verschachtelt?
   - Werden Slots/Children/Render Props fuer flexible Komposition genutzt?

Fuer jedes Problem liefere:
- **Komponente**: Name und Datei
- **Schweregrad**: Umschreiben / Refactor / Optimierung / Stil
- **Problem**: Warum dies Skalierbarkeit oder Performance schadet
- **Fix**: Refactored Code

Beispielausgabe

## Frontend-Komponenten-Review: 5 Probleme gefunden

### Refactor: Prop Drilling durch 4 Ebenen
Komponente: App → Layout → Sidebar → NavItem (user Prop)
Fix: React Context verwenden:
  const UserContext = createContext<User | null>(null);

### Optimierung: Liste rendert bei jedem Tastendruck neu
Komponente: SearchResults.tsx
Fix:
  const filtered = useMemo(
    () => results.filter(r => r.name.includes(query)),
    [results, query]
  );

### Refactor: useEffect synchronisiert abgeleiteten State
Code:
  const [fullName, setFullName] = useState('');
  useEffect(() => setFullName(first + ' ' + last), [first, last]);
Fix: Direkt ableiten: const fullName = `${first} ${last}`;

Wann verwenden

Beim Review von Komponenten-PRs, wenn eine Seite sich traege anfuehlt oder wenn eine Komponente ueber 200 Zeilen gewachsen ist. Unverzichtbar beim Aufbau eines Design Systems, bei dem Komponenten-APIs sauber genug fuer teamweite Adoption sein muessen.

Profi-Tipps

• Komponentenbaum einbeziehen — viele Probleme leben in der Beziehung zwischen Komponenten, nicht innerhalb einer einzelnen.
• Erst profilieren, dann memoisieren — React DevTools Profiler nutzen, um tatsaechliche Re-Render-Bottlenecks zu identifizieren.
• Zerlegungsplan anfordern — “Zerlege dies in Atomic-Design-Schichten: Atome, Molekuele, Organismen.”