Співбесіда React змішує специфіку фреймворку — хуки, рендеринг, стан — з основами JavaScript, за якими видно, чи розумієте ви, що React робить під капотом. Нижче — найчастіші питання з еталонними відповідями. Middle: глибше розуміння, оптимізацію та реальні робочі ситуації.
Допомагає, коли обчислення справді дороге або коли значення слугує залежністю іншого хука чи мемоїзованого нащадка — там нове посилання на кожен рендер убиває мемоїзацію. Шумом стає навколо дешевих операцій, бо саме порівняння і зберігання значення теж коштують. Загорнути в useMemo усе підряд — зробити код нечитабельним без вимірної вигоди.
Відкрити Profiler, записати взаємодію і подивитися «why did this render» — пропси, стан чи батько. Звичайні причини: обʼєкт або стрілкова функція, створені інлайн у батька, контекст, значення якого перестворюється щорендера, і стан, піднятий вище, ніж потрібно. Лагодити треба причину, а не накривати React.memo, який її лише ховає.
Context позбавляє протягування значення крізь компоненти, яким воно байдуже — тема, локаль, поточний користувач. Хибним він стає для часто змінюваного стану: при зміні значення перемальовуються всі споживачі, і немає селектора, щоб підписатися на частину. З цього моменту потрібна бібліотека стану з підписками, а не один контекст, у якому лежить усе.
Бо в наївній версії немає всього, що робить серверні дані складними: кешу, дедуплікації однакових запитів, повторного завантаження при поверненні фокуса, ретраїв і захисту від запису в розмонтований компонент. Переписування цього на кожному екрані — місце, де живуть баги. Зміна мислення в тому, що серверні дані це кеш, який ви синхронізуєте, а не стан, яким володієте.
useEffect виконується після відмальовування браузером, тому користувач може на мить побачити стан до ефекту. useLayoutEffect виконується синхронно після змін DOM, але до відмальовування, що прибирає мигання ціною блокування. useLayoutEffect беруть лише коли ви вимірюєте DOM і одразу змінюєте щось за результатом вимірювання — позиція тултипа, поправка скролу.
Її ловить error boundary і показує запасний інтерфейс замість білої сторінки, бо непіймана помилка рендера розмонтовує все дерево. Межі не ловлять помилки в обробниках подій і в асинхронному коді — це саме те, що пропускають, там потрібен звичайний try/catch. Ставити межі варто навколо осмислених секцій, щоб один зламаний віджет не забирав екран.
Спершу на рівні маршрутів, бо користувач, що зайшов на один екран, не має завантажувати весь застосунок. Потім навколо справді важких і рідко використовуваних компонентів — бібліотека графіків, редактор тексту, модалка, яку більшість не відкриває. Дрібніше подрібнення додає накладні витрати на запити і стани завантаження в обмін на кілобайти.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Middle React Frontend →