Du erbst eine große Codebasis voller Klassenkomponenten. Wie würdest du die Migration auf Hooks angehen?

Schrittweise, und nur dort, wo es etwas bringt. Klassen und Funktionskomponenten funktionieren problemlos nebeneinander, ein Big-Bang-Rewrite ist also unnötig. Konvertier zuerst Blattkomponenten, zieh geteilte Logik aus Higher Order Components und Render Props in Custom Hooks, und lass Error Boundaries Klassen, denn das müssen sie weiterhin sein. Häng jede Konvertierung an Arbeit, die ohnehin ansteht, mit Tests auf Verhalten statt auf Implementierung.

Ich würde es nicht als Projekt machen, sondern als Gewohnheit. Klassen und Funktionskomponenten sitzen friedlich nebeneinander, es gibt also keinen Zwang, alles zu konvertieren, und ein Rewrite ohne Nutzen für den User ist schwer zu verkaufen und ein hervorragender Weg, Bugs einzubauen. Die Regel wird also: Wenn du eine Datei ohnehin änderst und sie ein Blatt oder fast ein Blatt ist, konvertier sie. Der eigentliche Gewinn sind ohnehin nicht die Komponenten, sondern die geteilte Logik, die in Higher Order Components und Render Props feststeckt, denn daraus werden Custom Hooks, die alle nutzen können. Zur Abbildung: componentDidMount und componentWillUnmount werden ein Effect mit Cleanup, componentDidUpdate zerfällt meist nach Zuständigkeit in mehrere Effects, und getDerivedStateFromProps entpuppt sich fast immer als abgeleiteter State, den man schlicht während des Renders berechnen sollte. Error Boundaries bleiben Klassen, daran hat sich nichts geändert. Bevor ich etwas Nichttriviales konvertiere, will ich Tests auf Verhaltensebene darum herum, die prüfen, was der User sieht, statt internen State, damit die Konvertierung nachweislich neutral ist.