Kontext vs Zustand wird oft als eine „Gewinner-nimmt-alles“-Argumentation dargestellt. Das ist nicht der Fall. Sie lösen verschiedene Probleme, und das Gespräch über die Leistung macht nur Sinn, wenn dies klar ist.
Kontext ist gut darin, Werte durch den Baum zu verteilen. Zustand ist gut darin, einen externen Store mit gezielten Abonnements zu pflegen.
Wo Kontext das bessere Werkzeug ist
Kontext eignet sich besonders gut, wenn der Wert konzeptionell umgebend ist:
- Thema
- Sprache
- authentifizierter Benutzer
- Feature-Flags
Solcher Art von Zustand gehört in die Nähe des Baumes, da der Baum der entscheidende Punkt ist.
Wo Zustand hilft
Zustand wird attraktiv, wenn viele Komponenten einen gemeinsam nutzbaren veränderbaren Zustand benötigen, aber nicht alle von ihnen jede Aktualisierung benötigen:
const useCartStore = create((set) => ({
count: 0,
increment: () => set((state) => ({ count: state.count + 1 })),
}));
const count = useCartStore((state) => state.count);
Dieses Selektormodell ist der praktische Unterschied. Komponenten können sich auf einen Teil anstatt auf ein breites Kontextobjekt abonnieren.
Bessere Entscheidungsregel
Fragen Sie nicht: „Welches ist schneller?“ Fragen Sie:
- Ist dieser Wert global oder umgebend?
- Wie oft ändert er sich?
- Wie viele Komponenten interessieren sich für jedes Feld?
- Brauchen wir Store-Semantik außerhalb des Baumes?
Wenn die Antwort hauptsächlich umgebende Konfiguration ist, reicht der Kontext aus. Wenn die Antwort ein gemeinsamer Anwendungszustand mit selektiven Abonnements ist, ist Zustand in der Regel die sauberere Lösung.
Weiterführende Literatur