Wie entscheidest du, wo ein bestimmtes Stück State leben soll?

Fang so lokal wie möglich an, in der Komponente, die ihn nutzt, und zieh ihn erst zum nächsten gemeinsamen Vorfahren hoch, wenn Geschwister ihn wirklich teilen müssen. Sind es Serverdaten, gehören sie in eine cachende Datenschicht und nicht in Komponenten-State. Soll ein User darauf verlinken können, etwa Filter oder den aktuellen Tab, gehört es in die URL. Ein globaler Store ist die letzte Option.

Mein erster Schritt ist herauszufinden, um welche Art State es geht, denn das meiste, was Leute State nennen, ist gar kein lokaler State. Kommt es vom Server, geht es in einen Query-Cache, damit ich Deduplizierung, Revalidierung und Staleness-Handling bekomme, statt das per useState und Effect nachzubauen. Soll es einen Reload überleben oder als Link teilbar sein, wie aktive Filter oder der offene Tab, geht es in die URL. Was übrig bleibt, ist echter UI-State, und der startet in der Komponente, die ihn nutzt. Ich ziehe erst hoch, wenn eine zweite Komponente ihn wirklich braucht, und dann nur bis zum nächsten gemeinsamen Parent. Globale Stores hebe ich mir für Dinge auf, die tatsächlich app-weit sind, etwa den aktuellen User oder eine WebSocket-Verbindung. Das Problem, das ich am häufigsten aufgeräumt habe, ist State, der in einen Top-Level-Provider gezogen wurde, weil zwei Komponenten ihn einmal brauchten, und zwei Jahre später rendert alles bei jedem Tastendruck neu, und keiner traut sich, ihn wieder runterzuziehen.