React має високий поріг входу чи його можна опанувати за декілька тижнів? Це застаріла технологія, яку скоро змінить щось нове, чи найстабільніший інструмент, на якому завʼязані BigTech проєкти? Анастасія Гордєєва, Front-end Team Lead у Wix, поділилася найпоширенішими упередженнями про React та його концепції, помилками при ререндері компонентів, які призводять до складних багів, а також розповіла, чому суперечки «бібліотека це чи фреймворк» — лише снобізм.
Для людей, які тільки починають розвиватися у фронтенд-розробці, є два міфи про React, що суперечать один одному. Перший — що React має високий поріг входу через JSX, декларативний підхід або нову концепцію хуків. З іншого боку React часто називають простим. Зокрема це продається на сумнівних курсах, які обіцяють, що за декілька тижнів можна повністю опанувати цей інструмент.
Обидва твердження здаються мені абсолютним міфом. Будь-який інструмент — React, Vue, Angular або будь-що інше, потребує певних зусиль для засвоєння нових знань та навичок. Не існує альтернативного інструменту, у якому вже на другий день можна стати Pro. Як сильно заглиблюватися в технологію, залежить від задач на проєкті. Наприклад, навчитися робити counter, намалювати кнопочку чи зробити форму — дійсно легко. Щоби продебажити застосунок та розібратися, чому він погано перформить, або додати новий стейт, не зламавши всі інші, потрібні глибокі знання React.
Часто JSX вважають фактором, що ускладнює роботу з React. На початку кар'єри я також читала про цей «недолік», проте пізніше зрозуміла, що це скоріше перевага.
JSX — це не якась нова мова програмування. Це синтаксис, схожий на HTML, з декількома нюансами. Щоби зрозуміти їх, достатньо один раз почитати відповідний розділ у документації, а потім попрактикуватися. Вважаю, що JSX покращує читабельність коду. Коли в ньому є правильний розділ на компоненти, одразу видно, які теги використовуються, яку логіку вони в собі інкапсулюють.
Що важливіше знати — JS чи React? Одні вважають, що краще заглиблюватися у класичний JavaScript, а фреймворки — досить мінливі. Інші — достатньо знати базу JavaScript, а заглиблюватися вже в React. Моя думка: навіщо обирати щось одне?
Теоретично на маленькому проєкті, який команда не буде підтримувати надалі, можна викрутитися без глибоких знань, — завжди є GPT, Stack Overflow тощо. Проте, якщо це великий продукт, і наші рішення будуть «стріляти нам в ногу» за три роки, то однозначно потрібні глибокі знання як JavaScript, так і React.
«Що таке React?» — одне з найбільш популярних запитань на співбесідах. І якщо ви назвете його фреймворком, вас обовʼязково виправлять: «Ні, це бібліотека». На мій погляд, ці суперечки — скоріше снобізм. Можливо, десь в інтернеті є чіткі критерії та визначення фреймворку та бібліотеки, але навряд ці знання допомагають у житті фронтенд-розробника. Хіба що «підіграти» інтервʼюеру та отримати додаткові бали на співбесіді.
Важливіше розуміти, що дає React «з коробки», а чого не дає порівняно з Vue, Angular та іншими фреймворками, в чому різниця між цими UI-підходами, та чому ми обираємо саме React.
Непорозуміння щодо природи Virtual DOM і DOM браузера частіше трапляється серед новачків, які плутають ці два поняття. Насправді ж вони суттєво відрізняються. DOM (Document Object Model) — це стандартна структура, яку використовує браузер для відображення вебсторінки. Кожен елемент сторінки — текст, зображення, кнопки — є частиною DOM. Virtual DOM — це внутрішня структура React, не пов'язана напряму з браузером. Вона допомагає визначати мінімальні зміни, які потрібно зробити в реальному DOM, для покращення продуктивності. Щоби уникнути плутанини, у React-ком'юніті почали обговорювати зміну назви та ту, яка краще відображатиме справжню природу цієї структури.
З ререндером компонентів у React повʼязано чимало упереджень. Наведу найпоширеніші з них.
Компоненти ререндеряться, коли змінюються їхні props.
Ця тема також часто піднімається на співбесідах: інтервʼюери люблять питати, як це працює насправді. Є чотири правила ререндеру компонента:
Initial Render — коли відбувається перший рендер усіх функціональних компонентів.
Коли змінюється State у компоненті.
Коли змінюється Context, на який підписаний компонент.
Ререндер усіх дочірніх компонентів після ререндеру батьківського.
Останній пункт часто плутають із ререндером під час зміни props. Насправді ж незалежно від того, чи змінюються вони чи ні, якщо батьківський компонент ререндерився, те саме роблять і дочірні. Це потрібно для оптимізації процесів в React: замість того, щоби відстежувати зміни властивостей у кожному компоненті, він просто перерендерить всіх.
Ререндер після кожного виклику UpdateState функції
Часто розробники очікують, що після кожного виклику setState відбувається повторний рендер компонента. Насправді це не зовсім так. У React є механізм оптимізації, який називається State Update Batching. Цей механізм дозволяє об'єднувати декілька викликів setState в межах одного колбеку, наприклад, під час обробки onclick-івентів або в таймерах, у один ререндер.
Отже, навіть якщо ви декілька разів викличете setState у межах одного блоку, React об'єднає ці виклики і виконає лише один ререндер компонента. Це допомагає оптимізувати роботу і запобігає надмірним рендерам. Цю деталь важливо розуміти, щоби уникнути складних для визначення помилок.
Ререндер після зміни значення контексту
Часто виникає помилкова думка, що всі дочірні компоненти провайдера контексту в React ререндеряться щоразу, коли змінюється значення контексту. Насправді це не так. Якби це було правдою, не було б сенсу у використанні Context API, оскільки не було б ніякої оптимізації. Ререндер відбувається тільки для компонентів, які є консюмерами контексту (використовують контекст через useContext або інший механізм споживання). Інші компоненти, що не споживають значення контексту, залишаються незмінними.
На мій погляд, подібні меседжі можна зустріти про кожну технологію, і це наслідок агресивного маркетингу. Розробники фреймворків так само змагаються за своїх споживачів, як виробники Coca-Cola та Pepsi.
React завжди був одним із найстабільніших фреймворків. Кожна нова версія React залишається backward compatible, порівняно з іншими фреймворками, де великі оновлення змушували переписувати код. Запущений Facebook, на ньому був написаний Instagram та величезна кількість інших великих проєктів. Крім того, на ньому постійно запускаються нові проєкти та не обходиться, наприклад, Next.js. Крім того, ринок переповнений вакансіями для React-розробників, що свідчить про актуальність цієї технології.
Comentarios