React ErrorBoundary: Ізоляція помилок та стратегії відновлення

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

Розуміння потреби в межах помилок (Error Boundaries)

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

Межі помилок надають спосіб перехоплювати помилки JavaScript у будь-якому місці в дереві дочірніх компонентів, логувати ці помилки та відображати запасний інтерфейс користувача (fallback UI) замість того, щоб руйнувати дерево компонентів. Вони дозволяють ізолювати несправні компоненти та запобігати впливу помилок в одній частині вашого додатку на інші, забезпечуючи більш стабільний та надійний користувацький досвід у всьому світі.

Що таке React ErrorBoundary?

ErrorBoundary — це компонент React, який перехоплює помилки JavaScript у будь-якому місці в дереві дочірніх компонентів, логує ці помилки та відображає запасний інтерфейс користувача. Це класовий компонент, який реалізує один або обидва з наступних методів життєвого циклу:

• static getDerivedStateFromError(error): Цей метод життєвого циклу викликається після того, як помилку було викинуто дочірнім компонентом. Він отримує викинуту помилку як аргумент і повинен повернути значення для оновлення стану компонента.
• componentDidCatch(error, info): Цей метод життєвого циклу викликається після того, як помилку було викинуто дочірнім компонентом. Він отримує два аргументи: викинуту помилку та об'єкт info, що містить інформацію про те, який компонент викинув помилку. Ви можете використовувати цей метод для логування інформації про помилку або виконання інших побічних ефектів.

Створення базового компонента ErrorBoundary

Давайте створимо базовий компонент ErrorBoundary, щоб проілюструвати основні принципи.

Приклад коду

Ось код простого компонента ErrorBoundary:

class ErrorBoundary extends React.Component {
 constructor(props) {
 super(props);
 this.state = {
 hasError: false,
 error: null,
 errorInfo: null,
 };
 }

 static getDerivedStateFromError(error) {
 // Оновлюємо стан, щоб наступний рендер показав запасний UI.
 return {
 hasError: true,
 };
 }

 componentDidCatch(error, info) {
 // Приклад "componentStack":
 // in ComponentThatThrows (created by App)
 // in App
 console.error("Перехоплено помилку:", error);
 console.error("Інформація про помилку:", info.componentStack);
 this.setState({ error: error, errorInfo: info });
 // Ви також можете логувати помилку в сервіс звітування про помилки
 // logErrorToMyService(error, info.componentStack);
 }

 render() {
 if (this.state.hasError) {
 // Ви можете відрендерити будь-який власний запасний UI
 return (
 

 
Щось пішло не так.
 
Помилка: {this.state.error && this.state.error.toString()}
 

 {this.state.errorInfo && this.state.errorInfo.componentStack}
 
 
 );
 }

 return this.props.children;
 }
}

export default ErrorBoundary;

Пояснення

• Конструктор: Конструктор ініціалізує стан компонента, встановлюючи hasError в false. Ми також зберігаємо помилку та інформацію про неї для цілей налагодження.
• getDerivedStateFromError(error): Цей статичний метод викликається, коли дочірній компонент викидає помилку. Він оновлює стан, щоб вказати, що сталася помилка.
• componentDidCatch(error, info): Цей метод викликається після викидання помилки. Він отримує помилку та об'єкт info, що містить інформацію про стек компонентів. Тут ми логуємо помилку в консоль (замініть на бажаний механізм логування, такий як Sentry, Bugsnag або власне рішення). Ми також встановлюємо error та errorInfo у стані.
• render(): Метод рендерингу перевіряє стан hasError. Якщо він true, він рендерить запасний UI; в іншому випадку він рендерить дочірні компоненти. Запасний UI повинен бути інформативним та дружнім до користувача. Включення деталей помилки та стека компонентів, хоча й корисне для розробників, повинно рендеритися умовно або бути видаленим у виробничому середовищі з міркувань безпеки.

Використання компонента ErrorBoundary

Щоб використовувати компонент ErrorBoundary, просто оберніть будь-який компонент, який може викинути помилку, всередині нього.

Приклад коду

import ErrorBoundary from './ErrorBoundary';

function MyComponent() {
 return (
 

 {/* Компоненти, які можуть викликати помилку */}
 
 
 );
}

function App() {
 return (
 
 
 
 );
}

export default App;

Пояснення

У цьому прикладі MyComponent обгорнутий в ErrorBoundary. Якщо будь-яка помилка виникне всередині MyComponent або його дочірніх компонентів, ErrorBoundary перехопить її та відрендерить запасний UI.

Просунуті стратегії ErrorBoundary

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

1. Гранулярні межі помилок

Замість того, щоб обгортати весь додаток одним ErrorBoundary, розгляньте можливість використання гранулярних меж помилок. Це передбачає розміщення компонентів ErrorBoundary навколо конкретних частин вашого додатку, які більш схильні до помилок або де збій матиме обмежений вплив. Наприклад, ви можете обернути окремі віджети або компоненти, які залежать від зовнішніх джерел даних.

Приклад

function ProductList() {
 return (
 

 {/* Список продуктів */}
 
 );
}

function RecommendationWidget() {
 return (
 
 {/* Рушій рекомендацій */}
 
 );
}

function App() {
 return (
 

 
 
 
 );
}

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

2. Логування та звітування про помилки

Логування помилок є вирішальним для налагодження та виявлення повторюваних проблем. Метод життєвого циклу componentDidCatch є ідеальним місцем для інтеграції з сервісами логування помилок, такими як Sentry, Bugsnag або Rollbar. Ці сервіси надають детальні звіти про помилки, включаючи стеки викликів, контекст користувача та інформацію про середовище, що дозволяє швидко діагностувати та вирішувати проблеми. Розгляньте можливість анонімізації або редагування конфіденційних даних користувачів перед надсиланням логів помилок для забезпечення відповідності правилам конфіденційності, таким як GDPR.

Приклад

import * as Sentry from "@sentry/react";

class ErrorBoundary extends React.Component {
 constructor(props) {
 super(props);
 this.state = {
 hasError: false,
 };
 }

 static getDerivedStateFromError(error) {
 // Оновлюємо стан, щоб наступний рендер показав запасний UI.
 return {
 hasError: true,
 };
 }

 componentDidCatch(error, info) {
 // Логуємо помилку в Sentry
 Sentry.captureException(error, { extra: info });
 // Ви також можете логувати помилку в сервіс звітування про помилки
 console.error("Перехоплено помилку:", error);
 }

 render() {
 if (this.state.hasError) {
 // Ви можете відрендерити будь-який власний запасний UI
 return (
 

 
Щось пішло не так.
 
 );
 }

 return this.props.children;
 }
}

export default ErrorBoundary;

У цьому прикладі метод componentDidCatch використовує Sentry.captureException для звітування про помилку в Sentry. Ви можете налаштувати Sentry для надсилання сповіщень вашій команді, що дозволить швидко реагувати на критичні помилки.

3. Кастомний запасний UI

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

Приклад

class ErrorBoundary extends React.Component {
 constructor(props) {
 super(props);
 this.state = {
 hasError: false,
 error: null,
 };
 }

 static getDerivedStateFromError(error) {
 // Оновлюємо стан, щоб наступний рендер показав запасний UI.
 return {
 hasError: true,
 error: error,
 };
 }

 componentDidCatch(error, info) {
 console.error("Перехоплено помилку:", error);
 // Ви також можете логувати помилку в сервіс звітування про помилки
 // logErrorToMyService(error, info.componentStack);
 }

 render() {
 if (this.state.hasError) {
 // Ви можете відрендерити будь-який власний запасний UI
 if (this.state.error instanceof NetworkError) {
 return (
 

 
Помилка мережі
 
Будь ласка, перевірте ваше інтернет-з'єднання та спробуйте ще раз.
 
 );
 } else {
 return (
 

 
Щось пішло не так.
 
Будь ласка, спробуйте оновити сторінку або зв'яжіться з підтримкою.
 
 );
 }
 }

 return this.props.children;
 }
}

export default ErrorBoundary;

У цьому прикладі запасний UI перевіряє, чи є помилка NetworkError. Якщо так, він відображає конкретне повідомлення, що інструктує користувача перевірити інтернет-з'єднання. В іншому випадку, він відображає загальне повідомлення про помилку. Надання конкретних, дієвих вказівок може значно покращити користувацький досвід.

4. Механізми повторних спроб

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

Приклад

import React, { useState, useEffect } from 'react';

function DataFetchingComponent() {
 const [data, setData] = useState(null);
 const [error, setError] = useState(null);
 const [isLoading, setIsLoading] = useState(true);
 const [retryCount, setRetryCount] = useState(0);

 useEffect(() => {
 const fetchData = async () => {
 setIsLoading(true);
 try {
 const response = await fetch('https://api.example.com/data');
 if (!response.ok) {
 throw new Error(`HTTP помилка! статус: ${response.status}`);
 }
 const result = await response.json();
 setData(result);
 setError(null);
 } catch (e) {
 setError(e);
 setRetryCount(prevCount => prevCount + 1);
 } finally {
 setIsLoading(false);
 }
 };

 if (error && retryCount < 3) {
 const retryDelay = Math.pow(2, retryCount) * 1000; // Експоненційна затримка
 console.log(`Повторна спроба через ${retryDelay / 1000} секунд...`);
 const timer = setTimeout(fetchData, retryDelay);
 return () => clearTimeout(timer); // Очищення таймера при розмонтуванні або повторному рендері
 }

 if (!data) {
 fetchData();
 }

 }, [error, retryCount, data]);

 if (isLoading) {
 return 
Завантаження даних...
;
 }

 if (error) {
 return 
Помилка: {error.message} - Повторних спроб: {retryCount}.
;
 }

 return 
Дані: {JSON.stringify(data)}
;
}

function App() {
 return (
 
 
 
 );
}

export default App;

У цьому прикладі DataFetchingComponent намагається отримати дані з API. Якщо виникає помилка, він збільшує retryCount і повторює операцію після експоненційно зростаючої затримки. ErrorBoundary перехоплює будь-які необроблені винятки та відображає повідомлення про помилку, включаючи кількість спроб повторення.

5. Error Boundaries та рендеринг на стороні сервера (SSR)

При використанні рендерингу на стороні сервера (SSR) обробка помилок стає ще більш критичною. Помилки, що виникають під час процесу рендерингу на стороні сервера, можуть призвести до збою всього сервера, що призведе до простою та поганого користувацького досвіду. Вам потрібно переконатися, що ваші межі помилок правильно налаштовані для перехоплення помилок як на сервері, так і на клієнті. Часто SSR-фреймворки, такі як Next.js та Remix, мають власні вбудовані механізми обробки помилок, які доповнюють React Error Boundaries.

6. Тестування Error Boundaries

Тестування меж помилок є важливим для забезпечення їх правильної роботи та надання очікуваного запасного UI. Використовуйте бібліотеки для тестування, такі як Jest та React Testing Library, для симуляції умов помилок та перевірки того, що ваші межі помилок перехоплюють помилки та рендерять відповідний запасний UI. Розгляньте можливість тестування різних типів помилок та крайніх випадків, щоб переконатися, що ваші межі помилок є надійними та обробляють широкий спектр сценаріїв.

Приклад

import { render, screen } from '@testing-library/react';
import ErrorBoundary from './ErrorBoundary';

function ComponentThatThrows() {
 throw new Error('Цей компонент викидає помилку');
 return 
Це не повинно рендеритися
;
}

test('рендерить запасний UI, коли викидається помилка', () => {
 render(
 
 
 
 );

 const errorMessage = screen.getByText(/Щось пішло не так/i);
 expect(errorMessage).toBeInTheDocument();
});

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

7. Плавна деградація (Graceful Degradation)

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

Поширені помилки, яких слід уникати

Хоча ErrorBoundary є потужним інструментом, є деякі поширені помилки, яких слід уникати:

• Не обгортати асинхронний код: ErrorBoundary перехоплює помилки лише під час рендерингу, в методах життєвого циклу та в конструкторах. Помилки в асинхронному коді (наприклад, setTimeout, Promises) потрібно перехоплювати за допомогою блоків try...catch та обробляти належним чином всередині асинхронної функції.
• Надмірне використання Error Boundaries: Уникайте обгортання великих частин вашого додатку в один ErrorBoundary. Це може ускладнити ізоляцію джерела помилок і призвести до занадто частого відображення загального запасного UI. Використовуйте гранулярні межі помилок для ізоляції конкретних компонентів або функцій.
• Ігнорування інформації про помилку: Не просто перехоплюйте помилки та відображайте запасний UI. Переконайтеся, що ви логуєте інформацію про помилку (включаючи стек компонентів) до сервісу звітування про помилки або вашої консолі. Це допоможе вам діагностувати та виправити основні проблеми.
• Відображення конфіденційної інформації у виробничому середовищі: Уникайте відображення детальної інформації про помилку (наприклад, стеків викликів) у виробничому середовищі. Це може розкрити конфіденційну інформацію користувачам і становити ризик для безпеки. Замість цього відображайте дружнє до користувача повідомлення про помилку та логуйте детальну інформацію до сервісу звітування про помилки.

Error Boundaries з функціональними компонентами та хуками

Хоча Error Boundaries реалізовані як класові компоненти, ви все ще можете ефективно використовувати їх для обробки помилок у функціональних компонентах, що використовують хуки. Типовий підхід полягає в обгортанні функціонального компонента компонентом ErrorBoundary, як було показано раніше. Логіка обробки помилок знаходиться всередині ErrorBoundary, ефективно ізолюючи помилки, які можуть виникнути під час рендерингу функціонального компонента або виконання хуків.

Зокрема, будь-які помилки, викинуті під час рендерингу функціонального компонента або в тілі хука useEffect, будуть перехоплені ErrorBoundary. Однак важливо зазначити, що ErrorBoundaries не перехоплюють помилки, що виникають в обробниках подій (наприклад, onClick, onChange), прикріплених до DOM-елементів у функціональному компоненті. Для обробників подій слід продовжувати використовувати традиційні блоки try...catch для обробки помилок.

Інтернаціоналізація та локалізація повідомлень про помилки

При розробці додатків для глобальної аудиторії важливо інтернаціоналізувати та локалізувати ваші повідомлення про помилки. Повідомлення про помилки, що відображаються в запасному UI ErrorBoundary, повинні бути перекладені на бажану мову користувача, щоб забезпечити кращий користувацький досвід. Ви можете використовувати бібліотеки, такі як i18next або React Intl, для управління вашими перекладами та динамічного відображення відповідного повідомлення про помилку залежно від локалі користувача.

Приклад з використанням i18next

import i18next from 'i18next';
import { useTranslation } from 'react-i18next';

i18next.init({
  resources: {
    en: {
      translation: {
        'error.generic': 'Something went wrong. Please try again later.',
        'error.network': 'Network error. Please check your internet connection.',
      },
    },
    uk: {
      translation: {
        'error.generic': 'Щось пішло не так. Будь ласка, спробуйте пізніше.',
        'error.network': 'Помилка мережі. Будь ласка, перевірте ваше інтернет-з\'єднання.',
      },
    },
  },
  lng: 'uk',
  fallbackLng: 'en',
  interpolation: {
    escapeValue: false, // не потрібно для react, оскільки він екранує за замовчуванням
  },
});

function ErrorFallback({ error }) {
  const { t } = useTranslation();

  let errorMessageKey = 'error.generic';
  if (error instanceof NetworkError) {
    errorMessageKey = 'error.network';
  }

  return (
    

      
{t('error.generic')}
      
{t(errorMessageKey)}
    
  );
}

function ErrorBoundary({ children }) {
  const [hasError, setHasError] = useState(false);
  const [error, setError] = useState(null);

  static getDerivedStateFromError = (error) => {
    // Оновлюємо стан, щоб наступний рендер показав запасний UI
    // return { hasError: true }; // це не працює з хуками в такому вигляді
    setHasError(true);
    setError(error);
  }

  if (hasError) {
    // Ви можете відрендерити будь-який власний запасний UI
    return ;
  }

  return children;
}

export default ErrorBoundary;

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

Висновок

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