Class Components zu Hooks migrieren: der systematische Fahrplan

1. Warum Class Components zu Hooks migrieren noch relevant ist

Viele Teams glauben, dass die Frage, wie man Class Components zu Hooks migriert, seit React 16.8 durch ist und heute keine Rolle mehr spielt. In der Praxis sieht das anders aus: Codebasen aus 2018 bis 2020 enthalten oft Hunderte Klassenkomponenten, die nie angefasst wurden, weil sie funktionierten. Sobald ein neues Feature aber Context, Concurrent Rendering oder React 19 Actions braucht, stoesst man an die Grenzen der alten Klassenschreibweise, und die Migration wird plotzlich dringend statt optional.

Der zweite Grund, warum Teams heute noch Class Components zu Hooks migrieren, ist der Fachkraeftemarkt. Neue Entwickler lernen React fast ausschliesslich mit Hooks, kennen this Bindings und Lifecycle Methoden oft nur aus der Dokumentation und brauchen doppelt so lange, um in einer Klassenkomponente einen Bug zu finden. Eine konsequente Migration reduziert also nicht nur technische Schulden, sondern auch Einarbeitungszeit und Fehlerquote im Team.

Der dritte Grund ist subtiler: der React Compiler und viele neue Bibliotheken wie TanStack Query oder Zustand sind auf Function Components und Hooks ausgelegt. Wer Class Components zu Hooks migriert, oeffnet sich diese Werkzeuge erst wirklich, statt sie ueber Wrapper Komponenten muehsam an Klassen anzudocken.

2. Inventar und Reihenfolge: welche Komponente zuerst

Bevor eine einzige Zeile Code geaendert wird, braucht die Migration ein Inventar. Ein einfaches Skript zaehlt alle Vorkommen von extends React.Component oder extends Component im Projekt und sortiert sie nach Groesse und Anzahl der Lifecycle Methoden. Komponenten mit nur render() und vielleicht constructor() sind der ideale Einstieg, weil sie in Minuten migriert sind und dem Team schnell Erfolgserlebnisse liefern.

Komplexe Klassenkomponenten mit componentDidUpdate, mehreren setState Aufrufen und internen Timern sollten bewusst zuletzt migriert werden, wenn das Team bereits Routine hat. Eine gute Faustregel: wer Class Components zu Hooks migrieren will, sollte pro Sprint eine feste Anzahl an Komponenten einplanen, statt alles in einem grossen Big Bang Refactoring zu erledigen. Ein Big Bang Ansatz erhoeht das Risiko von Regressionen massiv und blockiert parallel laufende Feature Arbeit.

Wichtig ist auch, Komponenten zu identifizieren, die von aussen ueber Refs angesprochen werden, etwa fuer imperative Methodenaufrufe. Diese brauchen spaeter forwardRef und useImperativeHandle, was den Aufwand pro Komponente erhoeht und in der Planung beruecksichtigt werden muss.

# Find all class components in a React codebase, sorted by lifecycle complexity
grep -rl "extends React.Component\|extends Component" src/ \
  | while read -r file; do
      lifecycles=$(grep -cE "componentDid|componentWill|shouldComponentUpdate" "$file")
      lines=$(wc -l < "$file")
      echo "$lifecycles $lines $file"
    done \
  | sort -rn > migration-inventory.txt

# Read the inventory: fewest lifecycle methods first (easy wins)
sort -n migration-inventory.txt | head -20

3. this.state zu useState migrieren

Der einfachste Teil, wenn man Class Components zu Hooks migriert, ist meistens der State selbst. Ein this.state Objekt mit mehreren Feldern wird in mehrere unabhaengige useState Aufrufe aufgeteilt, statt es als ein grosses Objekt zu belassen. Das hat einen wichtigen Vorteil gegenueber der Klasse: jedes Feld kann unabhaengig aktualisiert werden, ohne die anderen Felder explizit zu spreaden, wie es this.setState({ ...this.state, feld: wert }) noch erfordert hat.

Ein haeufiger Fehler bei dieser Migration: Entwickler behalten aus Gewohnheit ein einziges grosses State Objekt mit useState bei und muessen dann bei jedem Update weiterhin manuell spreaden. Das verschenkt genau den Vorteil, den useState gegenueber this.setState bietet. Getrennte States pro fachlichem Konzept, etwa isLoading, error und data als drei separate useState Aufrufe, machen den Code lesbarer und die Migration nachvollziehbarer fuer Reviewer.

// BEFORE: class component with a combined state object
class UserProfile extends React.Component {
  constructor(props) {
    super(props);
    this.state = { user: null, isLoading: true, error: null };
  }

  componentDidMount() {
    fetchUser(this.props.userId)
      .then(user => this.setState({ user, isLoading: false }))
      .catch(error => this.setState({ error, isLoading: false }));
  }

  render() {
    const { user, isLoading, error } = this.state;
    if (isLoading) return <Spinner />;
    if (error) return <ErrorMessage error={error} />;
    return <ProfileCard user={user} />;
  }
}

// AFTER: function component with separate useState calls per concern
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let cancelled = false;
    fetchUser(userId)
      .then(data => { if (!cancelled) { setUser(data); setIsLoading(false); } })
      .catch(err => { if (!cancelled) { setError(err); setIsLoading(false); } });
    return () => { cancelled = true; };
  }, [userId]);

  if (isLoading) return <Spinner />;
  if (error) return <ErrorMessage error={error} />;
  return <ProfileCard user={user} />;
}

4. Lifecycle Methoden zu useEffect migrieren

Der schwierigste Teil, wenn Teams Class Components zu Hooks migrieren, ist fast immer die Zusammenfuehrung von componentDidMount, componentDidUpdate und componentWillUnmount in einen oder mehrere useEffect Aufrufe. Die drei Lifecycle Methoden decken unterschiedliche Zeitpunkte im Lebenszyklus ab, waehrend ein einziger useEffect mit Dependency Array alle drei Faelle abdecken kann, aber eben nur, wenn die Abhaengigkeiten korrekt angegeben werden.

Ein typischer Fehler bei dieser Migration: eine Klassenkomponente registriert einen Event Listener in componentDidMount und entfernt ihn in componentWillUnmount, aber nutzt in componentDidUpdate zusaetzlich Logik, die bei jeder Prop Aenderung neu ausgefuehrt werden muss. Beim Uebertrag in useEffect vergessen Entwickler haeufig, die Cleanup Funktion korrekt zurueckzugeben, was zu doppelten Event Listenern und Memory Leaks fuehrt. Der ESLint Plugin eslint-plugin-react-hooks mit der Regel exhaustive-deps ist hier Pflicht, weil es genau solche fehlenden Abhaengigkeiten aufdeckt.

Wichtig ist auch die Trennung von Effekten nach fachlichem Zweck. Statt einen einzigen riesigen useEffect zu schreiben, der Mounting, Updates und Unmounting gleichzeitig behandelt, sollten unabhaengige fachliche Belange in separate useEffect Aufrufe aufgeteilt werden. Das entspricht der urspruenglichen Intention der Hooks API und macht jede Migration einer Klassenkomponente deutlich uebersichtlicher.

// BEFORE: three lifecycle methods handling subscription and prop updates
class ChatRoom extends React.Component {
  componentDidMount() {
    this.connection = createConnection(this.props.roomId);
    this.connection.connect();
  }

  componentDidUpdate(prevProps) {
    if (prevProps.roomId !== this.props.roomId) {
      this.connection.disconnect();
      this.connection = createConnection(this.props.roomId);
      this.connection.connect();
    }
  }

  componentWillUnmount() {
    this.connection.disconnect();
  }

  render() {
    return <div>Connected to {this.props.roomId}</div>;
  }
}

// AFTER: a single useEffect with a correct dependency array replaces all three
function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(roomId);
    connection.connect();
    return () => connection.disconnect(); // covers unmount AND roomId change
  }, [roomId]);

  return <div>Connected to {roomId}</div>;
}

5. setState Batching: Unterschiede und Fallstricke

Ein Detail, das bei der Migration von Class Components zu Hooks gerne uebersehen wird, ist das unterschiedliche Batching Verhalten. In Klassenkomponenten wurden mehrere this.setState Aufrufe innerhalb eines React Event Handlers zu einem einzigen Re Render zusammengefasst, aber ausserhalb von React Events, etwa in einem setTimeout oder einem nativen DOM Event, loeste jeder Aufruf sofort ein eigenes Re Render aus. Seit React 18 batcht useState auch ausserhalb von React Events automatisch, was zwar meistens ein Performance Gewinn ist, aber bestehende Annahmen ueber die Reihenfolge von Re Renders veraendern kann.

Ein zweiter Fallstrick betrifft funktionale Updates. In Klassenkomponenten war this.setState(prevState => ({ count: prevState.count + 1 })) die empfohlene Form, wenn der neue Wert vom alten abhaengt. Bei useState gilt dieselbe Regel weiterhin, wird aber von vielen Entwicklern beim Uebertrag vergessen, weil sie faelschlich setCount(count + 1) mehrfach hintereinander aufrufen und sich wundern, warum der Zaehler nur um eins statt um mehrere Schritte erhoeht wird.

// WRONG: relies on the closure value of count, only increments once effectively
function handleClick() {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
} // count ends up +1, not +3

// RIGHT: functional update reads the latest pending state
function handleClick() {
  setCount(prev => prev + 1);
  setCount(prev => prev + 1);
  setCount(prev => prev + 1);
} // count ends up +3, matches the class component behaviour of this.setState(fn)

6. Context Consumer und Provider zu useContext migrieren

Klassenkomponenten, die Context ueber <MyContext.Consumer> mit Render Prop konsumiert haben, lassen sich beim Uebertrag zu Hooks deutlich vereinfachen. Statt eine verschachtelte Render Prop Funktion zu schreiben, liest useContext(MyContext) den Wert direkt und flach im Funktionskoerper. Das reduziert Einrueckungstiefe und macht den Datenfluss auf einen Blick sichtbar, was besonders bei mehreren verschachtelten Contexts einen grossen Unterschied macht.

Bei dieser Migration lohnt es sich, gleichzeitig einen eigenen Hook wie useAuth() zu extrahieren, der intern useContext(AuthContext) aufruft und zusaetzlich prueft, ob der Context ueberhaupt vorhanden ist. Das verhindert den haeufigen Laufzeitfehler, dass eine Komponente ausserhalb des passenden Providers gerendert wird und undefined statt der erwarteten Werte erhaelt.

7. Error Boundaries: warum sie Class Components bleiben

Ein wichtiger Punkt, den viele Teams beim Plan, Class Components zu Hooks zu migrieren, uebersehen: Error Boundaries lassen sich mit Stand React 19 nicht vollstaendig als Function Component mit Hooks abbilden. Die Methoden static getDerivedStateFromError und componentDidCatch existieren nur in Klassenkomponenten, weil React intern auf diese Lifecycle Hooks angewiesen ist, um Rendering Fehler in der Elternhierarchie abzufangen.

Die pragmatische Loesung ist, genau diese wenigen Error Boundary Komponenten bewusst als Ausnahme von der Migration zu behandeln und sie als kleine, isolierte Klassenkomponenten im Projekt zu belassen, idealerweise aus einer geteilten Bibliothek wie react-error-boundary importiert statt selbst geschrieben. So bleibt der Rest der Codebasis konsequent auf Function Components, ohne dass die Migration an dieser einen Stelle blockiert.

8. Tests als Sicherheitsnetz waehrend der Migration

Ohne Tests wird jede Migration von Class Components zu Hooks zum Blindflug. Bevor eine Komponente angefasst wird, sollte mindestens ein Test mit React Testing Library existieren, der das sichtbare Verhalten aus Nutzersicht prueft, etwa welche Texte gerendert werden und wie die Komponente auf Klicks reagiert. Diese Tests bleiben nach der Migration unveraendert gueltig, weil Testing Library bewusst Implementierungsdetails wie Klasse versus Funktion ignoriert und nur das gerenderte Ergebnis prueft.

Snapshot Tests sind bei dieser Migration mit Vorsicht zu geniessen, weil sich die interne Struktur einer Komponente durch den Uebertrag zu Hooks nicht aendert, wohl aber manchmal Ladezustaende oder Reihenfolgen von Effekten. Ein Snapshot, der stur auf Zeichenidentitaet prueft, produziert dann Fehlalarme, die nichts mit einem echten Bug zu tun haben. Verhaltensbasierte Tests mit expliziten Erwartungen sind fuer diese Migration die deutlich robustere Wahl.

9. Codemods und Automatisierung im Vergleich

Fuer grosse Codebasen lohnt sich die Frage, welche Schritte beim Uebertrag von Class Components zu Hooks automatisiert werden koennen und welche manuelle Sorgfalt brauchen. Die folgende Tabelle vergleicht die gaengigen Ansaetze.

Die Tabelle zeigt ein klares Muster: mechanische, syntaktische Aenderungen lassen sich gut automatisieren, waehrend Aenderungen am Verhalten, insbesondere bei Lifecycle Methoden, fachliches Verstaendnis und manuelle Sorgfalt brauchen. Wer Class Components zu Hooks migriert und versucht, diesen Teil vollstaendig einem Codemod zu ueberlassen, produziert erfahrungsgemaess mehr Bugs, als er einspart.

10. Zusammenfassung

Wer Class Components zu Hooks migrieren will, sollte zuerst ein Inventar erstellen und nach Komplexitaet priorisieren, statt planlos die naechstbeste Datei zu oeffnen. Einfache Komponenten mit wenig State und ohne Lifecycle Methoden sind der ideale Einstieg. this.state wird in separate useState Aufrufe pro fachlichem Konzept aufgeteilt, waehrend componentDidMount, componentDidUpdate und componentWillUnmount in einen sorgfaeltig konfigurierten useEffect mit korrektem Dependency Array zusammengefuehrt werden.

Batching Unterschiede zwischen this.setState und useState, Context Migration zu useContext und die bewusste Ausnahme fuer Error Boundaries runden die technische Seite ab. Tests mit React Testing Library sind das Sicherheitsnetz, das jede Migration von Class Components zu Hooks erst risikofrei macht, waehrend Codemods nur die mechanischen, nicht die verhaltensbezogenen Teile der Migration sinnvoll automatisieren koennen.

11. FAQ: Class Components zu Hooks migrieren