Життєвий цикл реактивних ефектів

Життєвий цикл ефекту

Кожен React-компонент проходить один і той самий життєвий цикл:

• Компонент монтується коли його додано на екран.
• Компонент оновлює , коли отримує нові пропси або стан, зазвичай у відповідь на взаємодію.
• Компонент демонтується коли його вилучено з екрана.

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

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

const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  // ...
}

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

// ...
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
    // ...

Функція очищення, яку повертає ваш ефект, визначає, як зупинити синхронізацію:

// ...
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
    // ...

Інтуїтивно ви можете подумати, що React почне синхронізацію, коли ваш компонент монтується, і припинить синхронізацію, коли ваш компонент демонтується. Однак, це ще не кінець історії! Іноді може знадобитися запустити і зупинити синхронізацію декілька разів, поки компонент залишається змонтованим.

Розглянемо, навіщо це потрібно, коли це відбувається, і як можна керувати цією поведінкою.

Чому синхронізація може відбуватися більше одного разу

Уявіть, що цей ChatRoom компонент отримує проп roomId, який користувач вибирає у випадаючому списку. Скажімо, спочатку користувач обирає кімнату "general" як roomId. Ваша програма відображає кімнату чату "general":

const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId /* "general" */ }) {
  // ...
  return <h1>Welcome to the {roomId} room!</h1>;
}

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

function ChatRoom({ roomId /* "general" */ }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Connects to the "general" room
    connection.connect();
    return () => {
      connection.disconnect(); // Disconnects from the "general" room
    };
  }, [roomId]);
  // ...

Поки що все добре.

Пізніше користувач вибирає іншу кімнату у випадаючому списку (наприклад, "travel"). Спочатку React оновить інтерфейс користувача:

function ChatRoom({ roomId /* "travel" */ }) {
  // ...
  return <h1>Welcome to the {roomId} room!</h1>;
}

Подумайте, що має відбутися далі. Користувач бачить, що "travel" є вибраною кімнатою чату у інтерфейсі. Однак ефект, який було запущено минулого разу, все ще пов'язаний з кімнатою "general". Проп roomId змінився, тому те, що ваш ефект зробив тоді (підключення до кімнати "general"), більше не відповідає інтерфейсу користувача.

На цьому етапі ви хочете, щоб React робив дві речі:

1. Припинити синхронізацію зі старим roomId (від'єднатися від кімнати "general")
2. Почати синхронізацію з новим roomId (підключитися до кімнати "travel")

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

Як React ресинхронізує ваш ефект

Нагадаємо, що ваш компонент ChatRoom отримав нове значення для свого пропу roomId. Раніше це було "general", а тепер це "travel". React має повторно синхронізувати ваш ефект, щоб перепідключити вас до іншої кімнати.

Щоб зупинити синхронізацію, React викличе функцію очищення, яку ваш ефект повернув після підключення до кімнати "general". Оскільки roomId був "general", функція очищення від'єднається від кімнати "general":

function ChatRoom({ roomId /* "general" */ }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Connects to the "general" room
    connection.connect();
    return () => {
      connection.disconnect(); // Disconnects from the "general" room
    };
    // ...

Тоді React запустить ефект, який ви надали під час цього рендерингу. Цього разу roomId є "travel", тому він почне синхронізацію з чатом "travel" (доки не буде викликано його функцію очищення):

function ChatRoom({ roomId /* "travel" */ }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Connects to the "travel" room
    connection.connect();
    // ...

Завдяки цьому ви тепер підключені до тієї ж кімнати, яку користувач вибрав у інтерфейсі. Катастрофу попереджено!

Щоразу після того, як ваш компонент перезавантажиться з іншим roomId, ваш ефект буде повторно синхронізуватися. Наприклад, скажімо, користувач змінює roomId з "travel" на "music". React знову припинить синхронізацію вашого ефекту, викликавши свою функцію очищення (від'єднавши вас від кімнати "travel"). Потім він знову почне синхронізацію, запустивши своє тіло з новим пропсом roomId (підключивши вас до кімнати "music").

Нарешті, коли користувач переходить на інший екран, ChatRoom демонтується. Тепер взагалі не потрібно залишатися на зв'язку. React востаннє зупинить синхронізацію вашого ефекту і від'єднає вас від чату "music".

Мислення з точки зору ефекту

Давайте підсумуємо все, що відбулося з точки зору компонента ChatRoom:

1. ChatRoom змонтовано з roomId, встановленим на "general"
2. ChatRoom оновлено з roomId, встановленим як "travel"
3. ChatRoom оновлено з roomId, встановленим як "music"
4. ChatRoom демонтовано

Протягом кожного з цих етапів життєвого циклу компонента ваш ефект робив різні речі:

1. Ваш ефект підключено до кімнати "general"
2. Ваш ефект від'єднано від кімнати "general" та підключено до кімнати "travel"
.
3. Ваш ефект від'єднано від кімнати "travel" та підключено до кімнати "music"
4. Ваш ефект від'єднано від "music" кімнати

Тепер давайте подумаємо про те, що сталося з точки зору самого ефекту:

useEffect(() => {
    // Your Effect connected to the room specified with roomId...
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      // ...until it disconnected
      connection.disconnect();
    };
  }, [roomId]);

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

1. Ваш ефект підключено до кімнати "general" (поки її не відключили)
2. Ваш ефект було підключено до кімнати "travel" (до моменту її відключення)
3. Ваш ефект, підключений до кімнати "music" (поки його не відключили)

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

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

Це може нагадати вам, як ви не думаєте про те, чи монтується або оновлюється компонент, коли пишете логіку рендерингу, яка створює JSX. Ви описуєте, що має бути на екрані, а React робить все інше.

Зверніть увагу, що коли компонент монтується вперше, ви бачите три журнали:

1. ✅ Connecting to "general" room at https://localhost:1234... (лише для розробки)
2. ❌ Disconnected from "general" room at https://localhost:1234. (development-only)
3. ✅ Connecting to "general" room at https://localhost:1234...

Перші два логи призначені лише для розробки. Під час розробки React завжди повторно монтує кожен компонент один раз.

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

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

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

Як React дізнається, що потрібно пересинхронізувати ефект

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

function ChatRoom({ roomId }) { // The roomId prop may change over time
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // This Effect reads roomId 
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]); // So you tell React that this Effect "depends on" roomId
  // ...

Ось як це працює:

1. Ви знали, що roomId - це проп, а це означає, що він може змінюватися з часом.
2. Ви знали, що ваш ефект читається як roomId (тобто його логіка залежить від значення, яке може змінитися пізніше).
3. Саме тому ви вказали його як залежність ефекту (щоб він пересинхронізувався при зміні roomId).

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

Наприклад, якщо ви передали ["general"] під час початкового рендерингу, а потім передали ["travel"] під час наступного рендерингу, React порівняє "general" та "travel". Це різні значення (порівняно з Object.is), тому React пересинхронізує ваш ефект. З іншого боку, якщо ваш компонент відрендериться повторно, але roomId не зміниться, ваш ефект залишиться підключеним до тієї ж кімнати.

Кожен ефект являє собою окремий процес синхронізації

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

function ChatRoom({ roomId }) {
  useEffect(() => {
    logVisit(roomId);
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  // ...
}

Але уявіть, що пізніше ви додасте до цього ефекту іншу залежність, яка потребує повторного встановлення з'єднання. Якщо цей ефект повторно синхронізується, він також викличе logVisit(roomId) для тієї самої кімнати, чого ви не планували. Реєстрація візиту є окремим процесом від встановлення з'єднання. Запишіть їх як два окремі ефекти:

function ChatRoom({ roomId }) {
  useEffect(() => {
    logVisit(roomId);
  }, [roomId]);

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    // ...
  }, [roomId]);
  // ...
}

Кожен ефект у вашому коді повинен представляти окремий і незалежний процес синхронізації.

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

Ефекти "реагують" на реактивні значення

Ваш ефект зчитує дві змінні (serverUrl та roomId), але ви вказали лише roomId як залежну:

const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  // ...
}

Чому serverUrl не потрібно встановлювати залежність?

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

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

Якби serverUrl була змінною стану, вона була б реактивною. Реактивні значення мають бути включені у залежності:

function ChatRoom({ roomId }) { // Props change over time
  const [serverUrl, setServerUrl] = useState('https://localhost:1234'); // State may change over time

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Your Effect reads props and state
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId, serverUrl]); // So you tell React that this Effect "depends on" on props and state
  // ...
}

Додавши serverUrl як залежність, ви забезпечите повторну синхронізацію ефекту після його зміни.

Спробуйте змінити обрану кімнату чату або відредагувати URL-адресу сервера в цій пісочниці:

Щоразу, коли ви змінюєте реактивне значення на кшталт roomId або serverUrl, ефект перепідключається до сервера чату.

Що означає ефект з порожніми залежностями

Що станеться, якщо перемістити обидва serverUrl та roomId за межі компонента?

const serverUrl = 'https://localhost:1234';
const roomId = 'general';

function ChatRoom() {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, []); // ✅ All dependencies declared
  // ...
}

Тепер код ефекту не використовує ніяких реактивних значень, тому його залежності можуть бути порожніми ([]).

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

Втім, якщо ви думаєте з точки зору ефекту, вам взагалі не потрібно думати про монтування та демонтування. Важливо те, що ви визначили, як саме ваш ефект має запускати та зупиняти синхронізацію. Сьогодні він не має реактивних залежностей. Але якщо ви захочете, щоб користувач з часом змінив roomId або serverUrl (і вони стануть реактивними), код вашого ефекту не зміниться. Вам потрібно буде лише додати їх до залежностей.

Усі змінні, оголошені у тілі компонента, є реактивними

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

Скажімо, користувач може вибрати сервер чату у випадаючому списку, але він також може налаштувати сервер за замовчуванням у налаштуваннях. Припустимо, ви вже помістили стан налаштувань у контекст, тому ви читаєте налаштування з цього контексту. Тепер ви обчислюєте serverUrl на основі вибраного сервера з пропсів і сервера за замовчуванням:

function ChatRoom({ roomId, selectedServerUrl }) { // roomId is reactive
  const settings = useContext(SettingsContext); // settings is reactive
  const serverUrl = selectedServerUrl ?? settings.defaultServerUrl; // serverUrl is reactive
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Your Effect reads roomId and serverUrl
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId, serverUrl]); // So it needs to re-synchronize when either of them changes!
  // ...
}

У цьому прикладі serverUrl не є пропсом або змінною стану. Це звичайна змінна, яку ви обчислюєте під час рендерингу. Але вона обчислюється під час рендерингу, тому може змінитися внаслідок повторного рендерингу. Ось чому вона є реактивною.

Усі значення всередині компонента (включаючи пропси, стан та змінні у тілі вашого компонента) є реактивними. Будь-яке реактивне значення може змінитися при повторному рендерингу, тому вам потрібно включити реактивні значення як залежності ефекту.

Іншими словами, ефекти "реагують" на всі значення з тіла компонента.

React перевіряє, що ви вказали кожне реактивне значення як залежність

Якщо ваш лінтер налаштовано на React, він перевірятиме, чи кожне реактивне значення, що використовується кодом вашого ефекту, оголошено як його залежність. Наприклад, це помилка ворсу, оскільки і roomId, і serverUrl є реактивними:

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

Щоб виправити проблему, скористайтеся порадою лінтера і вкажіть roomId та serverUrl як залежності вашого ефекту:

function ChatRoom({ roomId }) { // roomId is reactive
  const [serverUrl, setServerUrl] = useState('https://localhost:1234'); // serverUrl is reactive
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [serverUrl, roomId]); // ✅ All dependencies declared
  // ...
}

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

Що робити, коли ви не хочете повторно синхронізувати

У попередньому прикладі ви виправили помилку lint, додавши roomId та serverUrl як залежності.

Втім, ви можете замість цього "довести" лінтеру, що ці значення не є реактивними, тобто, що вони не можуть змінитися внаслідок перерендерингу. Наприклад, якщо serverUrl і roomId не залежать від рендерингу і завжди мають однакові значення, ви можете винести їх за межі компонента. Тепер їм не потрібно бути залежними:

const serverUrl = 'https://localhost:1234'; // serverUrl is not reactive
const roomId = 'general'; // roomId is not reactive

function ChatRoom() {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, []); // ✅ All dependencies declared
  // ...
}

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

function ChatRoom() {
  useEffect(() => {
    const serverUrl = 'https://localhost:1234'; // serverUrl is not reactive
    const roomId = 'general'; // roomId is not reactive
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, []); // ✅ All dependencies declared
  // ...
}

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

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

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

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

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

useEffect(() => {
  // ...
  // 🔴 Avoid suppressing the linter like this:
  // eslint-ignore-next-line react-hooks/exhaustive-deps
}, []);