Wie wählst du zwischen lokalem State, Context und einer State-Library wie Redux oder Zustand?

Pass das Werkzeug zur Art des States an. Lokales useState für alles, was eine Komponente besitzt, die URL für alles Teilbare oder Bookmarkbare, ein Query-Cache für Serverdaten und Context für stabile Werte wie Theme oder den aktuellen User. Zu einem Store greifst du erst, wenn du wirklich globalen Client-State hast, den viele unzusammenhängende Komponenten lesen und schreiben, und wo du Selektoren brauchst, um nicht alles neu zu rendern.

Ich versuche herauszufinden, um welche Art State es geht, bevor ich irgendetwas auswähle, denn die größten Gewinne kommen daher, ihn gar nicht erst in einen Store zu legen. Serverdaten gehen in einen Query-Cache, weil sie Deduplizierung, Revalidierung und Invalidierung brauchen, und nichts davon ist State-Management, das ist Caching. Alles, worauf ein User verlinken oder wohin er neu laden können soll, wie Filter oder der offene Tab, geht in die URL. Alles, was eine einzelne Komponente besitzt, bleibt in useState. Context nehme ich für stabile Dinge, Theme, den eingeloggten User, eine Client-Instanz, denn er hat keine Selektoren und häufige Updates sind entsprechend teuer. Was übrig bleibt, ist wirklich globaler Client-State, etwa ein Editor mit mehreren Panels und geteiltem Undo, und dann hole ich einen Store dazu. Für ein neues Projekt tendiere ich zu einem kleinen Store mit Hook-basierten Selektoren statt Redux, aber wenn ein Team Redux Toolkit schon kann und die Devtools-Gewohnheiten hat, schlägt Konsistenz meine Vorliebe jedes Mal.