Podnoszenie stanu w React: wspólny stan komponentów

Podnoszenie stanu oznacza przeniesienie stanu z komponentów, które muszą go współdzielić, do ich najbliższego wspólnego rodzica. Rodzic trzyma wartość, przekazuje ją w dół jako prop i przekazuje funkcję, którą dzieci wywołują, żeby ją zmienić, więc każde dziecko renderuje się z jednej kopii stanu.

import { useState } from 'react';

function Panel({ title, isOpen, onOpen, children }) {
    return (
        <section style={{ borderBottom: '1px solid #ddd', padding: '8px 0' }}>
            <h3 style={{ margin: 0 }}>{title}</h3>
            {isOpen ? <p>{children}</p> : <button onClick={onOpen}>Show</button>}
        </section>
    );
}

export default function App() {
    const [openIndex, setOpenIndex] = useState(0);

    return (
        <div>
            <Panel title="Shipping" isOpen={openIndex === 0} onOpen={() => setOpenIndex(0)}>
                Orders ship within two days.
            </Panel>
            <Panel title="Returns" isOpen={openIndex === 1} onOpen={() => setOpenIndex(1)}>
                Return anything within 30 days.
            </Panel>
            <Panel title="Warranty" isOpen={openIndex === 2} onOpen={() => setOpenIndex(2)}>
                Two years on every product.
            </Panel>
        </div>
    );
}

Kliknij "Show" na dowolnym panelu: otwiera się, a ten, który był otwarty, się zamyka. Naraz może być otwarty tylko jeden panel, bo panele nie decydują o tym same. App trzyma openIndex, a każdy Panel dostaje tylko isOpen i funkcję onOpen.

Problem: stan, który powinien się zgadzać

Zacznij od oczywistej wersji, w której każdy panel ma własny stan isOpen. Każdy panel działa, ale panele nic o sobie nie wiedzą, więc nic nie powstrzymuje dwóch z nich przed jednoczesnym otwarciem.

import { useState } from 'react';

function Panel({ title, children }) {
    const [isOpen, setIsOpen] = useState(false);

    return (
        <section style={{ borderBottom: '1px solid #ddd', padding: '8px 0' }}>
            <h3 style={{ margin: 0 }}>{title}</h3>
            {isOpen ? <p>{children}</p> : <button onClick={() => setIsOpen(true)}>Show</button>}
        </section>
    );
}

export default function App() {
    return (
        <div>
            <Panel title="Shipping">Orders ship within two days.</Panel>
            <Panel title="Returns">Return anything within 30 days.</Panel>
        </div>
    );
}

Otwórz oba panele: zostają otwarte razem. Stan w React jest prywatny dla komponentu, który go deklaruje, więc komponent rodzeństwa nie może go odczytać ani zresetować. Gdy dwa komponenty muszą się zgadzać, stan musi żyć nad nimi oboma.

Podnoszenie stanu w trzech krokach

Przerobienie drugiego przykładu na pierwszy wymaga trzech zmian.

1. Usuń stan z dziecka. Usuń useState w Panel i zamiast tego odczytuj isOpen z propsów. Dziecko już nie decyduje, czy jest otwarte.
2. Przekaż z rodzica wartość i sposób jej zmiany. Panel dostaje isOpen i callback onOpen. Dziecko wywołuje onOpen() po kliknięciu przycisku; nie wie, co rodzic z tym zrobi.
3. Dodaj stan do wspólnego rodzica. App deklaruje openIndex i zamienia go w propsy dla każdego panelu: isOpen={openIndex === 1} i onOpen={() => setOpenIndex(1)}.

Najbliższy wspólny rodzic to najniższy komponent, który renderuje wszystkie komponenty potrzebujące stanu. Tutaj to App. Gdyby panele znajdowały się w komponencie Faq, stan trafiłby do Faq, a nie wyżej.

Po podniesieniu stanu Panel jest kontrolowany przez rodzica w tym samym sensie co pole kontrolowane: pokazuje to, co mówią propsy, i zgłasza zmiany przez callback. Strona o komponentach kontrolowanych i niekontrolowanych omawia ten sam pomysł dla elementów formularzy.

Jedno źródło prawdy

Gdy dwie części ekranu pokazują ten sam fakt, zapisz go raz, a wszystko inne z niego wyliczaj. Klasycznym przypadkiem jest przelicznik temperatury: pola Celsjusza i Fahrenheita zawsze muszą się zgadzać, więc nie mogą trzymać każde własnej liczby.

import { useState } from 'react';

const round = (n) => Math.round(n * 10) / 10;
const toF = (c) => round((c * 9) / 5 + 32);
const toC = (f) => round(((f - 32) * 5) / 9);

function TemperatureInput({ label, value, onChange }) {
    return (
        <label style={{ display: 'block', marginBottom: 8 }}>
            {label}{' '}
            <input
                type="number"
                value={value}
                onChange={(e) => onChange(e.target.value)}
                style={{ width: 80 }}
            />
        </label>
    );
}

export default function App() {
    const [temp, setTemp] = useState({ value: '20', scale: 'c' });

    const number = Number(temp.value);
    const empty = temp.value === '';
    const celsius = temp.scale === 'c' || empty ? temp.value : toC(number);
    const fahrenheit = temp.scale === 'f' || empty ? temp.value : toF(number);

    return (
        <div>
            <TemperatureInput
                label="Celsius"
                value={celsius}
                onChange={(value) => setTemp({ value, scale: 'c' })}
            />
            <TemperatureInput
                label="Fahrenheit"
                value={fahrenheit}
                onChange={(value) => setTemp({ value, scale: 'f' })}
            />
            <p>{Number(celsius) >= 100 ? 'Water boils.' : 'Water does not boil.'}</p>
        </div>
    );
}

Pisz w którymkolwiek polu, a drugie za nim podąża. Stan to jeden fakt: liczba, którą użytkownik wpisał ostatnio, i skala, w której była. Drugie pole jest z niego wyliczane podczas renderowania, więc pole, w którym piszesz, zawsze zachowuje dokładnie to, co wpisałeś. Zmień stan początkowy na { value: '212', scale: 'f' }, a komunikat pod polami zmieni się na "Water boils."

Trzymanie liczby w stopniach Celsjusza i liczby w stopniach Fahrenheita w dwóch kawałkach stanu oznaczałoby, że każdy handler musi aktualizować obie, a gdy pierwszy handler o tym zapomni, pola przestaną się zgadzać. Jedna zapisana wartość nie może nie zgadzać się sama ze sobą.

Przekazywanie settera w dół

Dziecko może zmienić stan rodzica tylko przez funkcję, którą rodzic mu daje. Możesz przekazać sam setter (onSelect={setColor}) albo funkcję, która robi więcej (onOpen={() => setOpenIndex(1)}). Nadanie propsowi nazwy w stylu zdarzenia, takiej jak onSelect czy onChange, a nie setSelected, sprawia, że dziecko nie wie, jak rodzic przechowuje wartość, więc rodzic może to później zmienić bez ruszania dziecka.

import { useState } from 'react';

function ColorPicker({ colors, selected, onSelect }) {
    return (
        <div>
            {colors.map((c) => (
                <button
                    key={c}
                    onClick={() => onSelect(c)}
                    style={{ background: c, color: 'white', border: selected === c ? '3px solid black' : 'none', marginInlineEnd: 4 }}
                >
                    {c}
                </button>
            ))}
        </div>
    );
}

function Preview({ color }) {
    return <p style={{ color, fontSize: 24, fontWeight: 700 }}>Hello in {color}</p>;
}

export default function App() {
    const [color, setColor] = useState('teal');

    function handleSelect(c) {
        console.log('App sets color to', c);
        setColor(c);
    }

    return (
        <div>
            <ColorPicker colors={['teal', 'tomato', 'slateblue']} selected={color} onSelect={handleSelect} />
            <Preview color={color} />
        </div>
    );
}

ColorPicker i Preview nigdy ze sobą nie rozmawiają. Picker zgłasza wybór w górę, App go zapisuje, a nowa wartość płynie w dół do obu.

Kiedy nie podnosić stanu

Podnoszenie ma swój koszt. Gdy stan żyje w rodzicu, każda zmiana renderuje rodzica i domyślnie wszystkie jego dzieci, także te, które stanu nie używają. Podnoś stan tylko do najbliższego wspólnego rodzica, a stan używany przez jeden komponent zostaw w tym komponencie.

import { useState } from 'react';

function SearchBox() {
    const [query, setQuery] = useState('');
    console.log('render SearchBox');
    return <input value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Type here" />;
}

function ProductList() {
    console.log('render ProductList');
    return (
        <ul>
            <li>Keyboard</li>
            <li>Mouse</li>
        </ul>
    );
}

export default function App() {
    return (
        <div>
            <SearchBox />
            <ProductList />
        </div>
    );
}

Pisz w polu i obserwuj konsolę: przy każdym naciśnięciu klawisza renderuje się tylko SearchBox. Teraz przenieś query do App i przekaż je do SearchBox jako propsy. Każde naciśnięcie klawisza wypisuje wtedy też ProductList, choć lista nie używa zapytania. Gdyby lista filtrowała po zapytaniu, podniesienie byłoby właściwą decyzją, bo oba komponenty zależałyby wtedy od tej samej wartości.

Pytanie, które warto zadać, brzmi „kto musi odczytać tę wartość?". Jeśli odpowiedź to jeden komponent, stan zostaje w nim. Jeśli kilka, trafia do ich najbliższego wspólnego rodzica.

Gdy podnoszenie idzie za daleko

Czasem najbliższy wspólny rodzic jest wysoko w drzewie, a wartość trzeba przekazać przez kilka komponentów, które tylko podają ją dalej. To jest prop drilling. Kilka warstw propsów jest w porządku i łatwo je prześledzić. Gdy ta sama wartość wędruje przez wiele warstw albo potrzebuje jej prawie każdy komponent (zalogowany użytkownik, motyw, język), odczytuj ją przez useContext, zamiast przekazywać ręcznie. Kontekst zmienia sposób, w jaki wartość dociera do dzieci; sam stan nadal żyje w jednym rodzicu, więc nadal jest podniesiony.