Вам може не знадобитися ефект

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Good: This logic runs because the component was displayed
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  function handleSubmit(e) {
    e.preventDefault();
    // ✅ Good: Event-specific logic is in the event handler
    post('/api/register', { firstName, lastName });
  }
  // ...
}

Коли ви обираєте, чи помістити певну логіку в обробник події або ефект, головне питання, на яке вам слід відповісти, це те, що це за логіка з точки зору користувача. Якщо ця логіка спричинена певною взаємодією, залиште її в обробнику події. Якщо вона спричинена тим, що користувач бачить компонент на екрані, залиште її у ефекті.

Ланцюжки обчислень

Іноді ви можете відчути спокусу створити ланцюжок ефектів, кожен з яких коригує частину стану на основі іншого стану:

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);
  const [isGameOver, setIsGameOver] = useState(false);

  // 🔴 Avoid: Chains of Effects that adjust the state solely to trigger each other
  useEffect(() => {
    if (card !== null && card.gold) {
      setGoldCardCount(c => c + 1);
    }
  }, [card]);

  useEffect(() => {
    if (goldCardCount > 3) {
      setRound(r => r + 1)
      setGoldCardCount(0);
    }
  }, [goldCardCount]);

  useEffect(() => {
    if (round > 5) {
      setIsGameOver(true);
    }
  }, [round]);

  useEffect(() => {
    alert('Good game!');
  }, [isGameOver]);

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    } else {
      setCard(nextCard);
    }
  }

  // ...

У цьому коді є дві проблеми.

Єдина проблема полягає у тому, що це дуже неефективно: компонент (і його дочірні елементи) доводиться перемальовувати між кожним викликом set у ланцюжку. У наведеному вище прикладі, у найгіршому випадку (setCard → render → setGoldCardCount → render → setRound → render → setIsGameOver → render) відбувається три непотрібних перерендери дерева нижче.

Навіть якби він не був повільним, з розвитком вашого коду ви зіткнетеся з випадками, коли написаний вами "ланцюжок" не відповідатиме новим вимогам. Уявіть, що ви додаєте можливість переглядати історію ігрових ходів. Ви б зробили це, оновивши кожну змінну стану до значення з минулого. Однак встановлення стану карти у значення з минулого призведе до повторного запуску ланцюжка ефектів і зміни даних, які ви показуєте. Такий код часто є жорстким і крихким.

У цьому випадку краще вирахувати все, що можна, під час рендерингу, і відкоригувати стан в обробнику події:

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);

  // ✅ Calculate what you can during rendering
  const isGameOver = round > 5;

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    }

    // ✅ Calculate all the next state in the event handler
    setCard(nextCard);
    if (nextCard.gold) {
      if (goldCardCount <= 3) {
        setGoldCardCount(goldCardCount + 1);
      } else {
        setGoldCardCount(0);
        setRound(round + 1);
        if (round === 5) {
          alert('Good game!');
        }
      }
    }
  }

  // ...

Це набагато ефективніше. Крім того, якщо ви реалізуєте спосіб перегляду історії гри, тепер ви зможете встановити кожну змінну стану на хід з минулого, не запускаючи ланцюжок ефектів, який коригує кожне інше значення. Якщо вам потрібно повторно використати логіку між кількома обробниками подій, ви можете витягти функцію і викликати її з цих обробників.

Пам'ятайте, що всередині обробників подій стан поводиться як знімок. Наприклад, навіть після виклику setRound(round + 1) змінна round відображатиме значення на момент натискання кнопки користувачем. Якщо вам потрібно використати для обчислень наступне значення, визначте його вручну як const nextRound = round + 1.

У деяких випадках ви не можете обчислити наступний стан безпосередньо в обробнику події. Наприклад, уявіть собі форму з кількома випадаючими списками, де параметри наступного списку залежать від обраного значення попереднього. Тоді ланцюжок ефектів буде доречним, оскільки ви синхронізуєтеся з мережею.

Ініціалізація програми

Деяка логіка повинна виконуватися лише один раз під час завантаження застосунку.

У вас може виникнути спокуса помістити його в ефект у компоненті верхнього рівня:

function App() {
  // 🔴 Avoid: Effects with logic that should only ever run once
  useEffect(() => {
    loadDataFromLocalStorage();
    checkAuthToken();
  }, []);
  // ...
}

Однак, ви швидко виявите, що вона запускається двічі під час розробки. Це може спричинити проблеми - наприклад, може зробити недійсним маркер автентифікації, оскільки функція не призначена для подвійного виклику. Загалом, ваші компоненти мають бути стійкими до перезбірки. Це стосується і вашого компонента верхнього рівня App.

Хоча на практиці це може ніколи не бути змонтовано у виробництві, дотримання однакових обмежень у всіх компонентах полегшує переміщення та повторне використання коду. Якщо деяка логіка має виконуватися один раз на завантаження програми, а не один раз на монтування компонента, додайте змінну верхнього рівня для відстеження того, чи вона вже виконалася:

let didInit = false;

function App() {
  useEffect(() => {
    if (!didInit) {
      didInit = true;
      // ✅ Only runs once per app load
      loadDataFromLocalStorage();
      checkAuthToken();
    }
  }, []);
  // ...
}

Ви також можете запустити його під час ініціалізації модуля та перед рендерингом програми:

if (typeof window !== 'undefined') { // Check if we're running in the browser.
   // ✅ Only runs once per app load
  checkAuthToken();
  loadDataFromLocalStorage();
}

function App() {
  // ...
}

Код на верхньому рівні виконується один раз, коли ваш компонент імпортується - навіть якщо він не рендериться. Щоб уникнути уповільнення або несподіваної поведінки при імпорті довільних компонентів, не зловживайте цим шаблоном. Тримайте логіку ініціалізації програми у кореневих модулях компонентів, таких як App.js, або у точці входу вашої програми.

Сповіщення батьківських компонентів про зміни стану

Припустимо, ви пишете компонент Toggle з внутрішнім станом isOn, який може бути або true або false. Існує декілька різних способів перемикання (клацання або перетягування). Якщо ви хочете повідомити батьківський компонент про зміну внутрішнього стану Toggle, ви можете створити подію onChange і викликати її з ефекту:

function Toggle({ onChange }) {
  const [isOn, setIsOn] = useState(false);

  // 🔴 Avoid: The onChange handler runs too late
  useEffect(() => {
    onChange(isOn);
  }, [isOn, onChange])

  function handleClick() {
    setIsOn(!isOn);
  }

  function handleDragEnd(e) {
    if (isCloserToRightEdge(e)) {
      setIsOn(true);
    } else {
      setIsOn(false);
    }
  }

  // ...
}

Як і раніше, це не ідеально. Toggle спочатку оновлює свій стан, і React оновлює екран. Потім React запускає ефект, який викликає функцію onChange, передану з батьківського компонента. Тепер батьківський компонент оновить свій власний стан, почавши ще один прохід рендерингу. Було б краще зробити все за один прохід.

Видалити ефект і натомість оновити стан обох компонентів у тому самому обробнику події:

function Toggle({ onChange }) {
  const [isOn, setIsOn] = useState(false);

  function updateToggle(nextIsOn) {
    // ✅ Good: Perform all updates during the event that caused them
    setIsOn(nextIsOn);
    onChange(nextIsOn);
  }

  function handleClick() {
    updateToggle(!isOn);
  }

  function handleDragEnd(e) {
    if (isCloserToRightEdge(e)) {
      updateToggle(true);
    } else {
      updateToggle(false);
    }
  }

  // ...
}

За такого підходу і компонент Toggle, і його батьківський компонент оновлюють свій стан під час події. React пакує оновлення з різних компонентів разом, тому буде лише одна передача рендеру.

Ви також можете повністю вилучити стан, і натомість отримати isOn від батьківського компонента:

// ✅ Also good: the component is fully controlled by its parent
function Toggle({ isOn, onChange }) {
  function handleClick() {
    onChange(!isOn);
  }

  function handleDragEnd(e) {
    if (isCloserToRightEdge(e)) {
      onChange(true);
    } else {
      onChange(false);
    }
  }

  // ...
}

"Підняття стану вгору" дозволяє батьківському компоненту повністю контролювати Toggle, перемикаючи його власний стан. Це означає, що батьківському компоненту доведеться містити більше логіки, але в цілому буде менше станів, про які варто турбуватися. Щоразу, коли ви намагаєтеся синхронізувати дві різні змінні стану, спробуйте замість цього підняти стан вгору!

Передача даних до батька

Цей компонент Child отримує деякі дані, а потім передає їх компоненту Parent в ефекті:

function Parent() {
  const [data, setData] = useState(null);
  // ...
  return <Child onFetched={setData} />;
}

function Child({ onFetched }) {
  const data = useSomeAPI();
  // 🔴 Avoid: Passing data to the parent in an Effect
  useEffect(() => {
    if (data) {
      onFetched(data);
    }
  }, [onFetched, data]);
  // ...
}

У React дані передаються від батьківських компонентів до дочірніх. Коли ви бачите щось не так на екрані, ви можете відстежити, звідки надходить інформація, піднімаючись вгору по ланцюжку компонентів, поки не знайдете, який компонент передає невірний проп або має невірний стан. Коли дочірні компоненти оновлюють стан своїх батьківських компонентів в Ефектах, потік даних стає дуже важко відстежити. Оскільки і дочірньому, і батьківському компонентам потрібні ті самі дані, дозвольте батьківському компоненту отримати ці дані і передати їх вниз дочірньому натомість:

function Parent() {
  const data = useSomeAPI();
  // ...
  // ✅ Good: Passing data down to the child
  return <Child data={data} />;
}

function Child({ data }) {
  // ...
}

Цей спосіб простіший і робить потік даних передбачуваним: дані стікають від батьківського об'єкта до дочірнього.

Підписка на зовнішнє сховище

Іноді вашим компонентам може знадобитися підписатися на деякі дані поза межами стану React. Ці дані можуть бути зі сторонньої бібліотеки або вбудованого API браузера. Оскільки ці дані можуть змінюватися без відома React, вам потрібно вручну підписувати на них ваші компоненти. Часто це робиться за допомогою ефекту, наприклад:

function useOnlineStatus() {
  // Not ideal: Manual store subscription in an Effect
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    function updateState() {
      setIsOnline(navigator.onLine);
    }

    updateState();

    window.addEventListener('online', updateState);
    window.addEventListener('offline', updateState);
    return () => {
      window.removeEventListener('online', updateState);
      window.removeEventListener('offline', updateState);
    };
  }, []);
  return isOnline;
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

Тут компонент підписується на зовнішнє сховище даних (у цьому випадку на API браузера navigator.onLine). Оскільки цього API не існує на сервері (тому його не можна використовувати для початкового HTML), спочатку стан встановлюється у true. Щоразу, коли значення цього сховища даних змінюється у браузері, компонент оновлює свій стан.

Хоча зазвичай для цього використовують ефекти, у React є спеціальний хук для підписки на зовнішній магазин, якому надається перевага. Видаліть ефект і замініть його викликом useSyncExternalStore:

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

function useOnlineStatus() {
  // ✅ Good: Subscribing to an external store with a built-in Hook
  return useSyncExternalStore(
    subscribe, // React won't resubscribe for as long as you pass the same function
    () => navigator.onLine, // How to get the value on the client
    () => true // How to get the value on the server
  );
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

Цей підхід менш схильний до помилок, ніж ручна синхронізація змінних даних до стану React з ефектом. Зазвичай ви пишете кастомний хук на кшталт useOnlineStatus() вище, щоб не повторювати цей код в окремих компонентах. Детальніше про підписку на зовнішні магазини з React-компонентів.

Отримання даних

Багато програм використовують ефекти для запуску збору даних. Досить поширеним є написання ефекту збору даних на кшталт:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1);

  useEffect(() => {
    // 🔴 Avoid: Fetching without cleanup logic
    fetchResults(query, page).then(json => {
      setResults(json);
    });
  }, [query, page]);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

Вам не потрібно переносити цю вибірку до обробника подій.

Це може здатися протиріччям з попередніми прикладами, де логіку потрібно було вкладати в обробники подій! Однак, врахуйте, що не подія введення є основною причиною для вибірки. Пошукові дані часто попередньо заповнюються з URL-адреси, і користувач може переміщатися вперед і назад, не торкаючись введення.

Не має значення, звідки походять сторінка і запит. Поки цей компонент є видимим, ви хочете, щоб результати було синхронізовано з даними з мережі для поточних сторінки та запиту. Ось чому це ефект.

Однак у наведеному вище коді є помилка. Уявіть, що ви швидко вводите "hello". Тоді запит зміниться з "h" на "he", "hel", "hell" і "hello". Це запустить окремі вибірки, але немає жодних гарантій щодо того, у якому порядку будуть отримані відповіді. Наприклад, відповідь "hell" може надійти після відповіді "hello". Оскільки setResults() буде викликано останнім, ви отримаєте неправильні результати пошуку. Це називається "стан гонитви": два різні запити "змагалися" один з одним і прийшли в іншому порядку, ніж ви очікували.

Щоб виправити стан гонитви, потрібно додати функцію очищення для ігнорування застарілих відповідей:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1);
  useEffect(() => {
    let ignore = false;
    fetchResults(query, page).then(json => {
      if (!ignore) {
        setResults(json);
      }
    });
    return () => {
      ignore = true;
    };
  }, [query, page]);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

Це гарантує, що коли ваш ефект отримає дані, усі відповіді, окрім останньої, буде проігноровано.

Обробка станів гонитви - не єдина складність у реалізації зчитування даних. Вам також варто подумати про кешування відповідей (щоб користувач міг миттєво натиснути кнопку "Назад" і побачити попередній екран), про те, як отримувати дані на сервері (щоб початковий HTML, який відображається на сервері, містив отриманий вміст, а не спінер), а також про те, як уникнути мережевих водоспадів (щоб дочірня програма могла отримувати дані, не чекаючи на кожного з батьків).

Ці проблеми стосуються будь-якої бібліотеки інтерфейсу користувача, не тільки React. Вирішення їх не є тривіальним, саме тому сучасні фреймворки надають більш ефективні вбудовані механізми отримання даних, ніж отримання даних в ефектах.

Якщо ви не використовуєте фреймворк (і не хочете створювати власний), але хочете зробити вибірку даних з ефектів більш ергономічною, розгляньте можливість винесення логіки вибірки у спеціальний хук, як у цьому прикладі:

function SearchResults({ query }) {
  const [page, setPage] = useState(1);
  const params = new URLSearchParams({ query, page });
  const results = useData(`/api/search?${params}`);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

function useData(url) {
  const [data, setData] = useState(null);
  useEffect(() => {
    let ignore = false;
    fetch(url)
      .then(response => response.json())
      .then(json => {
        if (!ignore) {
          setData(json);
        }
      });
    return () => {
      ignore = true;
    };
  }, [url]);
  return data;
}

Ймовірно, ви також захочете додати деяку логіку для обробки помилок і відстеження завантаження вмісту. Ви можете створити такий хук самостійно або скористатися одним з багатьох рішень, вже доступних в екосистемі React. Хоча сам по собі цей спосіб не буде настільки ефективним, як використання вбудованого механізму збору даних у фреймворку, переміщення логіки збору даних у власний хук полегшить подальшу адаптацію ефективної стратегії збору даних.

Взагалі, коли вам доводиться вдаватися до написання ефектів, слідкуйте за тим, коли ви можете витягнути частину функціональності у власний хук з більш декларативним і спеціально створеним API, як useData вище. Чим менше необроблених викликів useEffect у ваших компонентах, тим легше вам буде підтримувати вашу програму.