Десять прихованих проблем компонентів React, які уповільнюють роботу додатків у епоху React 19

Компоненти React здаються простими, поки невеликі помилки не накопичуються, створюючи проблеми з доступністю, уповільнюючи відображення та спричиняючи помилки, які важко виявити. React 19, React Compiler та Server Components змінили спосіб створення додатків, і це робить такі промахи ще більш дорогими, а не дешевшими. Ось десять помилок на рівні компонентів, які тихо шкодять додатку, разом із способами їх виправлення.

1. Використання <div> скрізь замість семантичного HTML

Помилка: Використання універсального <div> для кожного елемента інтерфейсу. Навігація стає <div>. Кнопка перетворюється на <div onClick={...}>. Стаття обгортається в <div>. Навіть позначка форми отримує таку саму обробку.

// ❌ Bad: Div soup
function Navbar() {
  return (
    <div className="navbar">
      <div className="logo" onClick={() => router.push('/')}>Logo</div>
      <div className="nav-links">
        <div className="nav-item" onClick={() => setPage('home')}>Home</div>
        <div className="nav-item" onClick={() => setPage('about')}>About</div>
      </div>
    </div>
  );
}

Чому це пошкоджує ваш додаток:

• Проблеми з доступністю: технології допомоги не можуть розпізнати орієнтири навігації, інтерактивні елементи керування чи заголовки. Людина, яка використовує програвач екрана, чує щось на кшталт „можна натиснути, текст: Головна“, замість „навігація, посилання, Головна“.
• Неправильний доступ через клавіатуру: теги <div> за замовчуванням не піддаються фокусуванню, тому користувачі, які навігують за допомогою клавіатури, не можуть перейти до вашого меню навігації.
• Гірша SEO: пошукові системи покладаються на семантичну маркування, таке як <nav>, <main> та <article>, щоб розібрати структуру сторінки. Сторінка, побудована виключно з тегів <div>, сприймається пошуковими роботами як контент низької якості.

Компоненти сервера в React 19: оскільки SSR та стрімінг означають, що початковий HTML-пакет — це те, що бачать як користувачі, так і боти ще до початку процесу гідратації, семантична структура стає ще важливішою.

Рішення:

// ✅ Good: Semantic HTML
function Navbar() {
  return (
    <nav className="navbar" aria-label="Main navigation">
      <a href="/" className="logo">Logo</a>
      <ul className="nav-links">
        <li><a href="/">Home</a></li>
        <li><a href="/about">About</a></li>
      </ul>
    </nav>
  );
}

Найкраща практика 2026 року: скористайтеся новим API use у React 19 разом із метаданими доступності та пройдіть перевірку своїх компонентів за допомогою інструментів на кшталт axe-core чи розширення браузера WAVE. Використовуйте <button> для всього, що можна натиснути, <nav> для блоків навігації, а <section> у поєднанні з aria-labelledby для позначення регіонів сторінки.

2. Вбудовані стилі в JSX (погіршення продуктивності)

Помилка: визначення об’єктів стилів вбудовано в JSX, що призводить до створення абсолютно нового посилання на об’єкт під час кожної переробки.

// ❌ Bad: New object every render
function Badge({ color, children }) {
  return (
    <span style={{ backgroundColor: color, padding: '4px 8px', borderRadius: '4px' }}>
      {children}
    </span>
  );
}

Чому це пошкоджує ваш додаток:

• Додаткова робота з узгодженням: оскільки під час кожного відображення створюється новий об’єкт стилю, логіка порівняння React виявляє „змінену“ властивість та впливає на вузол DOM, хоча насправді нічого не змінилося.
• Повільніша реалізація CSS-in-JS: бібліотеки, які парсують оголошення вбудованих стилів, неодноразово несуть ці витрати, що погіршує ситуацію.
• „Сліпі“ місця компілятора: компілятор React 19 здатний мемоізувати компоненти, але не має засобів для самостійної стабілізації посилань на вбудовані об’єкти. Як тільки він виявляє новостворений об’єкт, він пропускає оптимізацію цієї частини.
• Пропущені можливості кешування: браузери не можуть кешувати оголошення вбудованих стилів так, як кешують таблиці стилів. CSS-клас парсується лише один раз, тоді як вбудовані стилі перепарсуються щоразу під час завантаження компонента.

Рішення:

// ✅ Good: CSS classes with dynamic data attributes
function Badge({ color, children }) {
  return (
    <span
      className="badge"
      data-color={color}
      style={{ '--badge-color': color }}
    >
      {children}
    </span>
  );
}
// CSS
// .badge { background-color: var(--badge-color); padding: 4px 8px; border-radius: 4px; }

Як альтернатива, інструменти Tailwind CSS добре працюють, якщо обережно використовувати їх із довільними значеннями:

// Acceptable: Tailwind utility classes
function Badge({ color, children }) {
  return (
    <span className="px-2 py-1 rounded" style={{ backgroundColor: color }}>
      {children}
    </span>
  );
}

Найкраща практика 2026 року: переміщуйте статичні стилі у CSS-модулі, класи Tailwind або підхід CSS-in-JS без додаткового часу виконання. Зберігайте вбудовані стилі лише для справді динамічних значень, таких як ширина панелі прогресу, і навіть у цьому випадку, коли це можливо, використовуйте власні властивості CSS.

3. Неправильне використання властивості key у списках

Помилка: використання індексу масиву як ключа, повне ігнорування властивості key або генерація випадкового ключа під час кожного оновлення.

// ❌ Bad: Index as key
function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo, index) => (
        <li key={index}>{todo.text}</li>
      ))}
    </ul>
  );
}
// ❌ Worse: Random key
function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <li key={Math.random()}>{todo.text}</li>
      ))}
    </ul>
  );
}

Чому це пошкоджує ваш додаток:

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

Рішення:

// ✅ Good: Stable, unique identifier
function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

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

// At data creation, not in the component
const todos = items.map(item => ({
  ...item,
  id: crypto.randomUUID(), // or your backend's ID
}));

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

4. Пряма зміна пропсів

Помилка: сприймати пропси як змінні локальні змінні та змінювати їх усередині дочірнього компонента.

// ❌ Bad: Mutating props directly
function SortButton({ items }) {
  const handleSort = () => {
    items.sort((a, b) => a.price - b.price); // MUTATES the prop!
    onSort(items);
  };

  return <button onClick={handleSort}>Sort by Price</button>;
}

Чому це пошкоджує ваш додаток:

• Тихе пошкодження батьківського елемента: стан батьківського елемента змінюється, а ви навіть не дізнаєтесь про це. Механізм виявлення змін у React ґрунтується на порівнянні посилань, тому такі зміни залишаються абсолютно непоміченими.
• Проблеми з перерендерингом застарілих даних: оскільки items все ще вказує на той самий масив у пам’яті, батьківський елемент ніколи не перерендерується, через що інтерфейс відображає застарілі дані.
• Плутанина у компіляторі React: компілятор припускає, що пропси передаються через дерево компонентів без змін. Пряме змінення пропсів скасовує його автоматичну логіку мемоізації.
• Втрата прогнозованості: будь-який інший компонент, який посилається на той самий масив, раптово побачить змінену, відсортовану версію даних без попередження.

Рішення:

// ✅ Good: Immutable update
function SortButton({ items, onSort }) {
  const handleSort = () => {
    const sorted = [...items].sort((a, b) => a.price - b.price);
    onSort(sorted);
  };

  return <button onClick={handleSort}>Sort by Price</button>;
}

Найкраща практика 2026 року: використовуйте Immer, коли вкладені мутації здаються неминучими, а також налаштуйте правило ESLint на кшталт prefer-readonly-props, якщо ви працюєте з TypeScript. Вважайте, що кожен проп є readonly, якщо не доведено інше.

5. Занадто багато пропів (замість композиції)

Помилка: створення величезних „богоподібних компонентів“, які приймають десятки пропів лише для контролю кожної можливої внутрішньої варіації.

// ❌ Bad: Prop explosion
function Card({
  title,
  subtitle,
  imageUrl,
  imageAlt,
  showImage,
  imagePosition,
  actions,
  showActions,
  actionAlignment,
  badge,
  badgeColor,
  onBadgeClick,
  footer,
  showFooter,
  footerContent,
  borderRadius,
  shadow,
  padding,
  variant,
}) {
  return (
    <div className={`card card--${variant}`} style={{ borderRadius, padding, boxShadow: shadow }}>
      {showImage && (
        <div className={`card__image card__image--${imagePosition}`}>
          <img src={imageUrl} alt={imageAlt} />
        </div>
      )}
      <div className="card__content">
        <h2>{title}</h2>
        {subtitle && <p>{subtitle}</p>}
      </div>
      {/* ... more conditional rendering ... */}
    </div>
  );
}

Чому це пошкоджує ваш додаток:

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

Рішення:

// ✅ Good: Composition
function Card({ children, className }) {
  return (
    <div className={clsx('card', className)}>
      {children}
    </div>
  );
}
function CardImage({ src, alt, position = 'top' }) {
  return (
    <div className={`card__image card__image--${position}`}>
      <img src={src} alt={alt} loading="lazy" />
    </div>
  );
}
function CardContent({ title, subtitle }) {
  return (
    <div className="card__content">
      <h2>{title}</h2>
      {subtitle && <p>{subtitle}</p>}
    </div>
  );
}
function CardActions({ children, align = 'end' }) {
  return (
    <div className={`card__actions card__actions--${align}`}>
      {children}
    </div>
  );
}
// Usage
<Card>
  <CardImage src="/photo.jpg" alt="Product" />
  <CardContent title="Headphones" subtitle="Noise cancelling" />
  <CardActions>
    <button>Add to Cart</button>
  </CardActions>
</Card>

Найкраща практика 2026 року: краще використовувати паттерн компонентів з композицією або композицію на основі слотів. Нехай користувач компонента вирішує щодо структури та змісту, а сам компонент має лише надавати контейнер.

6. Невикористання React.Fragment (непотрібні Div-и)

Помилка: обгортання елементів-братів у звичайний <div> лише для дотримання правила JSX про те, що компонент має повертати один кореневий вузол.

// ❌ Bad: Wrapper div for layout that breaks semantics
function TableCell({ label, value }) {
  return (
    <div> {/* This div breaks the <table> structure! */}
      <td>{label}</td>
      <td>{value}</td>
    </div>
  );
}// ❌ Bad: Extra div in a list
function ListItems({ items }) {
  return (
    <ul>
      {items.map(item => (
        <div key={item.id}> {/* Invalid HTML: div inside ul */}
          <li>{item.name}</li>
          <li>{item.description}</li>
        </div>
      ))}
    </ul>
  );
}

Чому це ламає ваш додаток:

• Недійсний маркап: <div> не є допустимим дочірнім елементом таких елементів, як <table>, <ul>, <select> чи <dl>. Браузери мовчки перепишуть DOM, щоб виправити це, що призводить до неузгоджень під час гідратації під час серверного рендерингу.
• Перешкоди у лейауті: Додаткові елементи-обгортки порушують роботу CSS Grid, Flexbox та властивість gap.
• Помилки гідратації в React: Враховуючи те, наскільки поширеними зараз є стріминговий SSR та серверні компоненти, такий недійсний вкладення може спричинити фатальні неузгодження під час гідратації, що призводить до зупинки роботи додатку на клієнті.

Рішення:

// ✅ Good: React.Fragment
function TableCell({ label, value }) {
  return (
    <>
      <td>{label}</td>
      <td>{value}</td>
    </>
  );
}
// ✅ Good: Fragment with key (required in lists)
function ListItems({ items }) {
  return (
    <ul>
      {items.map(item => (
        <React.Fragment key={item.id}>
          <li>{item.name}</li>
          <li>{item.description}</li>
        </React.Fragment>
      ))}
    </ul>
  );
}

Найкраща практика 2026 року: використовуйте скорочення <> </>, коли ключ не потрібен, а для відображення масивів фрагментів, які його вимагають, вдавайтеся до <React.Fragment key={...}>. Регулярно перевіряйте дерево компонентів у React DevTools, щоб виявити та видалити зайві обгорткові divи.

7. Відображення хибних чисел за допомогою && (приховані помилки)

Помилка: покладання на && для умовного відображення чогось, не враховуючи випадки, коли лівий операнд дорівнює 0, NaN або порожньому рядку.

// ❌ Bad: Shows "0" on screen when items.length is 0
function Cart({ items }) {
  return (
    <div>
      <h1>Shopping Cart</h1>
      {items.length && (
        <ul>
          {items.map(item => <li key={item.id}>{item.name}</li>)}
        </ul>
      )}
    </div>
  );
}
// ❌ Bad: accountBalance could be 0
function AccountSummary({ account }) {
  return (
    <div>
      {account.balance && <p>Balance: ${account.balance}</p>}
    </div>
  );
}

Чому це пошкоджує ваш додаток:

• React насправді відображає 0: написання {0 && <Component />} не призводить до відсутності відображення, а друкує саме число 0 у вигляді тексту.
• Невидимі дефекти інтерфейсу: користувачі змушені дивитися на випадкове „0“ на сторінці, що виглядає некоректно та може порушити компонування додатку.
• Значення нуля у реальному світі: такі показники, як баланс рахунку, кількість елементів чи оцінки, часто дорівнюють нулю у закономірний та очікуваний спосіб. Якщо розглядати 0 як хибне значення за допомогою &&, це означає, що ви або не відображаєте нічого там, де це не потрібно, або відображаєте саме це число там, де цього не бажаєте.

Рішення:

// ✅ Good: Explicit boolean check
function Cart({ items }) {
  return (
    <div>
      <h1>Shopping Cart</h1>
      {items.length > 0 && (
        <ul>
          {items.map(item => <li key={item.id}>{item.name}</li>)}
        </ul>
      )}
    </div>
  );
}
// ✅ Good: Nullish coalescing for defaults, ternary for conditionals
function AccountSummary({ account }) {
  return (
    <div>
      {account.balance != null ? (
        <p>Balance: ${account.balance}</p>
      ) : (
        <p>Loading balance...</p>
      )}
    </div>
  );
}

Найкраща практика 2026 року: повністю уникайте використання && для умовного відображення. Краще використовувати тернарний оператор (condition ? : null) або явно вказати булеве значення за допомогою чогось на кшталт Boolean(count) && .... Додайте до вашого проекту правило ESLint, яке виявлятиме ризиковані варіанти використання && у JSX.

8. Пропуск мемоізації для дорогих елементів JSX

Помилка: дозволяти дорогому піддереву перероблятися при кожній зміні батьківського елемента, навіть якщо відповідні пропси насправді не змінилися.

// ❌ Bad: HeavyChart re-renders every time Parent re-renders
function Dashboard({ data, filter }) {
  const [hoveredItem, setHoveredItem] = useState(null);

  return (
    <div>
      <Sidebar onHover={setHoveredItem} />
      <HeavyChart data={data} filter={filter} /> {/* Re-renders on every hover! */}
      <Tooltip item={hoveredItem} />
    </div>
  );
}
function HeavyChart({ data, filter }) {
  // Expensive SVG rendering, D3 calculations, etc.
  return <svg>{/* thousands of nodes */}</svg>;
}

Чому це пошкоджує ваш додаток:

• Марна обробка даних: HeavyChart знову виконує свою логіку відображення навіть тоді, коли data та filter залишаються незмінними.
• Падіння частоти кадрів: якщо відображення HeavyChart займає близько 50 мс, проста подія наведення курсору на бічній панелі може знизити частоту кадрів до приблизно 20 fps.
• Обмеження компілятора React: автоматична мемоізація з боку компілятора працює всередині компонента, але не може оптимізувати роботу між компонентами, якщо батьківський компонент постійно передає нові посилання на функції-колбеки.

Рішення:

// ✅ Good: Memoize the expensive component
const HeavyChart = memo(function HeavyChart({ data, filter }) {
  // Expensive rendering
  return <svg>{/* thousands of nodes */}</svg>;
});
function Dashboard({ data, filter }) {
  const [hoveredItem, setHoveredItem] = useState(null);

  // Stabilize the callback if passed to children
  const handleHover = useCallback((item) => setHoveredItem(item), []);

  return (
    <div>
      <Sidebar onHover={handleHover} />
      <HeavyChart data={data} filter={filter} />
      <Tooltip item={hoveredItem} />
    </div>
  );
}

Найкраща практика 2026 року: компілятор React 19 зменшує потребу у ручній мемоізації у простих випадках, але для справді великих піддерев все ще варто використовувати memo. Використовуйте профілер React DevTools, щоб визначити справжні вузькі місця, перш ніж вдаватися до мемоізації.

9. Поєднання презентаційної та бізнес-логіки

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

// ❌ Bad: God component
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [isEditing, setIsEditing] = useState(false);
  const [formData, setFormData] = useState({});

  useEffect(() => {
    fetchUser(userId).then(data => {
      setUser(data);
      setFormData(data);
      setLoading(false);
    });
  }, [userId]);

  const handleSubmit = async () => {
    await updateUser(userId, formData);
    setIsEditing(false);
  };

  if (loading) return <Spinner />;

  return (
    <div>
      <h1>{user.name}</h1>
      {isEditing ? (
        <form onSubmit={handleSubmit}>
          <input
            value={formData.name}
            onChange={e => setFormData({...formData, name: e.target.value})}
          />
        </form>
      ) : (
        <button onClick={() => setIsEditing(true)}>Edit</button>
      )}
    </div>
  );
}

Чому це пошкоджує ваш додаток:

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

Рішення:

// ✅ Good: Separated concerns
// Container / Logic Hook
function useUserProfile(userId) {
  const { data: user, isLoading } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetchUser(userId),
  });

  const updateMutation = useMutation({
    mutationFn: updateUser,
    onSuccess: () => queryClient.invalidateQueries({ queryKey: ['user', userId] }),
  });

  return { user, isLoading, updateUser: updateMutation.mutate };
}
// UI Component
function UserProfile({ userId }) {
  const { user, isLoading, updateUser } = useUserProfile(userId);
  const [isEditing, setIsEditing] = useState(false);

  if (isLoading) return <Spinner />;

  return (
    <div>
      <h1>{user.name}</h1>
      {isEditing ? (
        <UserProfileForm
          initialData={user}
          onSubmit={(data) => {
            updateUser({ userId, ...data });
            setIsEditing(false);
          }}
          onCancel={() => setIsEditing(false)}
        />
      ) : (
        <button onClick={() => setIsEditing(true)}>Edit</button>
      )}
    </div>
  );
}
// Reusable Form Component
function UserProfileForm({ initialData, onSubmit, onCancel }) {
  const [formData, setFormData] = useState(initialData);

  return (
    <form onSubmit={(e) => { e.preventDefault(); onSubmit(formData); }}>
      <input
        value={formData.name}
        onChange={e => setFormData(prev => ({...prev, name: e.target.value}))}
      />
      <button type="submit">Save</button>
      <button type="button" onClick={onCancel}>Cancel</button>
    </form>
  );
}

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

10. Невикористання інтерфейсів TypeScript для пропсів

Помилка: покладання на prop-types, розкидані коментарі JSDoc або, у найгіршому випадку, повне ігнорування перевірки типів пропсів.

// ❌ Bad: No types
function Button(props) {
  return <button className={props.variant}>{props.children}</button>;
}
// ❌ Bad: PropTypes at runtime only
import PropTypes from 'prop-types';
function Button(props) {
  return <button className={props.variant}>{props.children}</button>;
}
Button.propTypes = {
  variant: PropTypes.string,
  children: PropTypes.node,
};

Чому це пошкоджує ваш додаток:

• Тихі помилки: опечатки в назвах параметрів, відсутність необхідних значень та неузгоджені типи призводять до збоїв під час виконання, замість того щоб бути виявленими до розгортання.
• Рефакторинг стає складним: зміна назви одного параметра змушує вас вручну шукати його по всьому кодовому базі, тоді як система типів миттєво позначає всі місця використання, які потребують оновлення.
• Гірший досвід розробника: без типів ви втрачаєте автодоповнення, підказки документації та захист від автоматичних змін назв.
• Погана сумісність з React 19: нові можливості React, такі як Server Components, використання use з Promises та передача референсів, розробляються з урахуванням моделі типів TypeScript, тож ігнорування типів означає втрату гарантій часу компіляції, на яких ґрунтуються ці функції.

Рішення:

// ✅ Good: Explicit TypeScript interface
interface ButtonProps {
  variant?: 'primary' | 'secondary' | 'danger';
  size?: 'sm' | 'md' | 'lg';
  disabled?: boolean;
  onClick?: (event: React.MouseEvent<HTMLButtonElement>) => void;
  children: React.ReactNode;
  type?: 'button' | 'submit' | 'reset';
}
function Button({
  variant = 'primary',
  size = 'md',
  disabled = false,
  onClick,
  children,
  type = 'button'
}: ButtonProps) {
  return (
    <button
      type={type}
      className={`btn btn--${variant} btn--${size}`}
      disabled={disabled}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

Рекомендований підхід для 2026 року: увімкніть режим суворості (strict: true у tsconfig.json). Визначайте властивості моделей за допомогою оголошень interface, а не аліасів type, оскільки інтерфейси зазвичай забезпечують більш зрозумілі повідомлення про помилки та їх легше розширювати. Використовуйте React.ComponentProps, коли потрібно отримати типи з кореневих елементів HTML під час створення компонентів-обгорток. У жодному разі не використовуйте any для типів властивостей.

Підсумок: Чек-лист компонентів для 2026 року

Перш ніж об’єднати компонент, перевірте цей чек-лист:

• [ ] Чи обрали ви семантичний HTML замість накопичення загальних елементів <div>?
• [ ] Чи визначені стилі у CSS, а не у об’єктах вбудованих стилів?
• [ ] Чи використовують елементи списку стабільні, унікальні значення key?
• [ ] Чи завжди властивості розглядаються як тільки для читання?
• [ ] Чи можна скласти компонент з інших елементів, замість того щоб використовувати десятки конфігураційних властивостей?
• [ ] Чи замінили ви зайві обгорткові div-и на Fragment?
• [ ] Чи записано умовне відображення у вигляді тернарних виразів або явних перевірок булевих значень замість &&?
• [ ] Чи мемоїзується дорогий JSX там, де це важливо?
• [ ] Чи відокремлена бізнес-логіка від маркуупу, знаходячись у хуках чи функціях-інструментах?
• [ ] Чи всі властивості повністю описані за допомогою інтерфейсів TypeScript?

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