Zum Inhalt
wannacode

Gemeinsamer Zustand

Kurz gesagt: Gemeinsamer Zustand kommt in React von einem Provider weit oben im Baum mit Context und useReducer, und die Komponenten lesen ihn direkt, ohne Props durch jede Ebene.

Problem

Der Zähler zeigt wieder 0

Der Warenkorb ist nach App hochgereicht, wie in der Lektion über das Hochreichen des Zustands. Von dort geht er als Props nach unten: zu Header und von dort zu CartBadge, zu Catalog, von dort zu ProductList und von dort zu jeder ProductCard. Jemand hat Header umgeschrieben, und der Zähler ist stehen geblieben.

React

Leg Weißbrot, Frischmilch und noch einmal Weißbrot hinein. Die Karten zählen, und im Kopfbereich steht „Warenkorb (0)“. App gibt count an Header, aber das neue Header gibt es nicht an CartBadge weiter. Header nutzt den Warenkorb nicht. Es sollte ihn nur weiterreichen, und genau das hat es vergessen.

Die Idee

Ein Provider oben, Konsumenten unten

Daten durch Komponenten zu reichen, die sie nicht nutzen, heißt Prop Drilling. Bei zwei Ebenen ist das normal. Bei fünf hängt jede Komponente auf dem Weg vom Warenkorb ab, und eine vergessene Prop reißt die Kette.

Beide Bibliotheken haben einen Weg, Daten an entfernte Nachkommen zu geben, ohne die Komponenten dazwischen:

  1. Der Provider ist die Komponente, der die Daten gehören. Er sagt: „Alles unter mir darf das lesen.“
  2. Der Konsument ist die Komponente, die sie nutzt. Sie nimmt sie direkt, egal wie viele Ebenen dazwischen liegen.

In React heißt das Context:

cart.js
export const CartContext = createContext(null);


// App.jsx
<CartContext value={{ items, count, add }}>
  <Header />
  <main><Catalog /></main>
</CartContext>


// CartBadge.jsx
const { count } = useContext(CartContext);

createContext(null) erzeugt den „Kanal“. null ist der Wert, wenn über der Komponente kein Provider steht. <CartContext value={…}> ist der Provider. useContext(CartContext) liest den Wert des nächsten Providers im Baum nach oben. Ändert sich der Wert, zeichnet sich jede Komponente neu, die ihn liest.

Die Daten haben weiterhin einen Besitzer, und die Änderungen laufen weiter über ihn: add ist die Funktion des Providers. Nur der Weg hat sich geändert.

Sieh es dir an

Sieh dir die beiden Wege an

Zuerst geht der Warenkorb Ebene für Ebene nach unten, und die Kette reißt in der Mitte. Dann wird App zum Provider, und beide Konsumenten lesen direkt.

const CartContext = createContext(null);


function App() {
  const [items, setItems] = useState([]);
  const count = items.reduce((s, i) => s + i.qty, 0);
  function add(product) { /* … */ }
  return (
    <CartContext value={{ items, count, add }}>
      <Header />
      <Catalog />
    </CartContext>
  );
}


function Header() {
  return <header><CartBadge /></header>;
}


function CartBadge() {
  const { count } = useContext(CartContext);
  return <a href="/cart">Warenkorb ({count})</a>;
}


function ProductCard({ product }) {
  const { add } = useContext(CartContext);
  return <button onClick={() => add(product)}>Hinzufügen</button>;
}
Schritt für Schritt, in Worten
  1. Der Warenkorb lebt in App. Zwei Komponenten weit unten brauchen ihn: CartBadge im Kopfbereich und ProductCard im Katalog.
  2. Nur mit Props wandert der Warenkorb Ebene für Ebene nach unten. Header, Catalog und ProductList nutzen ihn nicht. Sie reichen ihn nur weiter.
  3. Jemand schreibt Header um und vergisst count. Die Kette reißt in der Mitte, und der Zähler zeigt 0. Das ist Prop Drilling.
  4. Stattdessen: App umschließt den Baum mit <CartContext value={…}>. Alles darunter kann den Warenkorb lesen.
  5. CartBadge und ProductCard lesen ihn mit useContext(CartContext). Die Komponenten dazwischen wissen nichts vom Warenkorb.
  6. Ein Klick auf „Hinzufügen“ ruft add(product) auf. Die Funktion kommt vom Provider, deshalb passiert die Änderung in App.
  7. Der Warenkorb in App ändert sich, und jede Komponente, die ihn liest, wird neu gezeichnet: Der Zähler zeigt 1, die Karte zeigt 1.
  8. Die Daten haben weiterhin einen Besitzer, App. Nur der Weg hat sich geändert: nicht durch jede Ebene, sondern direkt vom Provider.

Die Komponenten in der Mitte wissen jetzt nichts mehr vom Warenkorb. Das neue Header kannst du so oft umschreiben, wie du willst.

Probier es aus

Entferne das Drilling

Der Warenkorb geht als Props durch Header und Catalog nach unten, und Header lässt count fallen. Gib den Warenkorb von oben. Header, Catalog und ProductList bekommen nichts über den Warenkorb, und CartBadge und ProductCard lesen ihn direkt. Die Prüfung legt Weißbrot, Frischmilch und noch einmal Weißbrot hinein und schaut sich die Karten und den Zähler an.

React

Die Idee

Ein Store für den Warenkorb

Der Warenkorb wächst: hinzufügen, entfernen, die Anzahl ändern, leeren. Ist jede Aktion eine Funktion in App, füllt sich App mit Logik, die nicht seine Aufgabe ist. Deshalb zieht der gemeinsame Zustand in eine eigene Datei um, einen Store: die Daten und alles, was sie ändert, an einem Ort.

React hat dafür den eingebauten Hook useReducer. Statt setItems(…) schicken die Komponenten eine Aktion (dispatch({ type: 'add', product })), und eine einzige Funktion, der Reducer, entscheidet, was mit dem Warenkorb passiert:

function cartReducer(items, action) {
  switch (action.type) {
    case 'add': /* ein neues Array mit dem Produkt */
    default:
      return items;
  }
}


export function CartProvider({ children }) {
  const [items, dispatch] = useReducer(cartReducer, []);
  const add = (product) => dispatch({ type: 'add', product });
  return <CartContext value={{ items, count, add }}>{children}</CartContext>;
}

CartProvider ist der Provider, und App setzt ihn nur um den Baum. Die Konsumenten ändern sich nicht: Sie lesen weiter useContext(CartContext). Der Reducer ist eine gewöhnliche Funktion: Der alte Warenkorb und eine Aktion gehen hinein, ein neuer Warenkorb kommt heraus. Sie berührt nichts anderes, deshalb lässt sie sich leicht testen.

Context und useReducer sind in React eingebaut. Es gibt auch Bibliotheken für Stores, zum Beispiel Zustand und Redux Toolkit. Sie sind nicht in der Sandbox, und hier erwähnen wir sie nur: Die Idee ist dieselbe, eine Quelle und Aktionen, die sie ändern.

React
Öffne cart.jsx: Dort steht die ganze Logik des Warenkorbs. CartBadge und ProductCard sind dieselben wie in der Aufgabe.

Probier es aus

Finde den Fehler

Die Seite stürzt ab, sobald sie sich öffnet: TypeError: Cannot destructure property 'count' of … as it is null. Welche Zeile ist schuld?

Wähle die Zeile mit dem Fehler.

Die Idee

Wann geteilt und wann nicht

Gemeinsamer Zustand ist praktisch, und deshalb ist es verlockend, alles dorthin zu legen. Aber alles darin kann von überall gelesen und geändert werden, und das macht Fehler schwerer auffindbar. Die Regel aus der Lektion über das Hochreichen gilt: so hoch wie nötig, und nicht höher.

  • Geteilt: was entfernte Teile des Baums brauchen und was lebt, solange der Nutzer auf der Seite ist. Der Warenkorb, der angemeldete Nutzer, die Sprache, das Design.
  • In der Komponente: die Felder eines Formulars, ob das Menü offen ist, welcher Tab gewählt ist, der Text im Suchfeld. Eine Komponente (oder ihr Elternteil) braucht sie, und sie verschwinden mit ihr.
  • Die Daten des Servers sind kein gemeinsamer Zustand. Die Produktliste und die Bestellungen haben einen Besitzer, und der Besitzer ist der Server. In einem Store sind sie eine Kopie, die aufgefrischt werden muss. Die Komponente, die sie zeigt, lädt sie, wie in der Lektion über Daten aus einer API.

Gemeinsamer Zustand ändert die Richtung nicht: Die Daten gehen von einem Besitzer aus, und die Änderungen laufen über seine Funktionen.

Probier es aus

Ergänze die Lücke

Wie liest CartBadge die Anzahl vom Provider?
import { useContext } from 'react';
import { CartContext } from './cart.js';

export default function CartBadge() {
  const { count } = (CartContext);
  return <a href="/cart">Warenkorb ({count})</a>;
}
Genauer, für Neugierige

<CartContext.Provider>. Vor React 19 wurde der Provider als <CartContext.Provider value={…}> geschrieben. Diese Form funktioniert weiterhin, und <CartContext value={…}> ist die neue, kürzere.

Dein eigener Hook. Neben einem Context steht oft eine kleine Funktion export function useCart() { return useContext(CartContext); }. Sie kann auch einen klaren Fehler auslösen, wenn es keinen Provider gibt, statt eines TypeError über null.

Wer zeichnet neu. Jede Komponente, die den Context liest, zeichnet sich neu, wenn sich sein Wert ändert. value={{ items, count, add }} ist bei jedem Zeichnen des Providers ein neues Objekt. In einer großen Anwendung sichert man das mit useMemo oder mit mehreren kleineren Contexts ab. In der Lektion über Geschwindigkeit siehst du, wie man das misst.

Klassenkomponenten lesen einen Context mit static contextType oder mit <CartContext.Consumer>. Du begegnest ihnen in altem Code.

Der Store lebt, solange die Seite offen ist. Beim Neuladen ist er weg. Ein Warenkorb, der überleben soll, wird in localStorage oder auf dem Server gespeichert.

Die Prüfungen sehen das Verhalten. Die Aufgaben hier sehen nicht, ob der Warenkorb aus Props, aus einem Context oder aus einem Store kommt. Sie prüfen, dass der Zähler und die Karten dasselbe zeigen.

Übung

Die Warenkorbseite

Im Hauptteil steht CartSummary: eine Überschrift Der Warenkorb, Zeilen Weißbrot × 2 mit einem Button Entfernen, Gesamt: 4,00 €, und Der Warenkorb ist leer, wenn er leer ist. Jetzt hat es einen eigenen Warenkorb, den niemand füllt. Füge dem Store das Entfernen und eine Summe hinzu und lass CartSummary den Warenkorb von dort lesen. Die Prüfung legt drei Produkte hinein, entfernt sie und schaut sich den Zähler, die Karten und die Summe an.

React

Test

Teste dich

1. Der Warenkorb geht von App über Catalog und ProductList bis zu ProductCard nach unten. Catalog und ProductList nutzen ihn nicht. Was ist das Problem?
2. CartBadge ruft useContext(CartContext) auf, steht aber außerhalb von <CartContext value={…}>. Was bekommt es?
3. Warum gibt cartReducer ein neues Array zurück, statt items.push(…) zu machen?
4. Was davon gehört in den gemeinsamen Zustand?
5. Die Produktliste kommt von /api/products. Soll sie in den gemeinsamen Store?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·