Початок роботи

These docs are old and won’t be updated. Go to react.dev for the new React docs.

The new Quick Start teaches modern React and includes live examples.

В даному розділі ми оглянемо документацію React та пов’язані з ним ресурси.

React — це JavaScript-бібліотека для створення інтерфейсів користувача. Відвідайте нашу головну сторінку або вступ, аби скласти перше враження про React.

З самого початку React був спроектований так, щоб його можна було впроваджувати поступово. Тобто ви можете додавати так мало або так багато React-у, як вам потрібно. Скористайтеся інформацією та посиланнями цього розділу, якщо просто бажаєте відчути React на смак або додаєте трохи “інтерактивності” до простої HTML-сторінки, чи, навіть, якщо стартуєте складний React-проект.

Хочете погратися з React? Скористайтеся онлайн-пісочницями. Спробуйте початковий шаблон на CodePen, CodeSandbox, Glitch або Stackblitz.

Віддаєте перевагу вашому улюбленому редактору коду? Тоді ви можете завантажити даний HTML-файл, відредагувати та відкрити його у вашому браузері. Даний шаблон трансформує JSX у JavaScript під час запуску . Однак, доволі повільно, тому ми рекомендуємо використовувати даний файл тільки для простих демонстраційних прикладів.

Ви можете додати React до HTML-сторінки лише за хвилину. За бажанням, ви зможете потім поступово поширювати React на сайті або залишити в декількох динамічних віджетах.

Створюємо новий React-додаток

Коли стартуєте React-проект, проста HTML-сторінка з script-тегами , можливо, є найкращим варіантом. Її створення займе лише одну хвилину!

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

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

• Полюбляєте навчання на практиці? Скористайтесь навчальним посібником.
• Вважаєте за потрібне спершу ознайомитись з теоретичною частиною? Почніть з головних концептів React.

Як і все нове, вивчення React потребує зусиль. Але, доклавши трохи праці і терпіння, ви обов’язково опануєте його.

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

Якщо документація надто “швидка” для вашого рівня і ви відчуваєте дискомфорт, погляньте на цей огляд від Тані Раша (Tania Rascia). Вона описала найважливіші концепти React більш деталізовано і легко для початківців. Потім повертайтеся і пробуйте знову!

Займаєтесь дизайном і хочете вивчити React? Даний ресурс є досить гарним стартовим майданчиком.

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

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

Підказка

При будь-яких ускладненнях з JavaScript, пошукайте відподвідь на цих ресурсах: MDN та javascript.info. Також ми маємо форум нашої спільноти, куди можна звернутися за допомогою.

Якщо ви віддаєте перевагу навчанню через практику, почніть з нашого практичного посібника. У ньому описано процес розробки гри в хрестики-нулики (tic-tac-toe). У вас, можливо, з’явиться спокуса пропустити цей розділ, бо ви не плануєте розробку ігор, але зачекайте. Прийоми, які ви опануєте — фундамент для розробки будь-якого додатка на React. Завдяки посібнику, ви отримаєте більш глибоке розуміння React.

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

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

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

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

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

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

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

Ви також можете підписатись на профіль @reactjs у Twitter, однак ви не пропустите нічого важливого, якщо будете слідкувати тільки за блогом.

У блозі ми пишемо не про всі релізи React, але завжди є можливість переглянути повний список змін у файлі CHANGELOG.md у репозиторії React, а також на сторінці Релізи.

Документація старих версій React

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

Якщо в документації чогось не вистачає, ви знайшли помилку, чи вважаєте деякі частини заплутаними, ви можете створити issue в репозиторії документації із зазначенням способу вирішення проблеми або просто напишіть нам в Twitter @reactjs. Ми завжди раді вас чути!

Навіщо і як вивчати React.js

Універсальність, розвинена спільнота та популярність.

Бібліотека для побудови інтерфейсів користувача (UI) React.js популярна серед frontend-розробників. Це підтверджують дані StackOverFlow Developer Survey 2021: 40% девелоперів вибирають React.js

За даними djinni — сервісу пошуку роботи в IT, для React-розробників відкрито понад 1 тис. вакансій із зарплатами $2500 — 4500 (станом на жовтень 2021 року).

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

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

На ці запитання відповідають Станіслав Сапранков, Software Developer Engineer в Amazon Web Services, Юрій Ковальчук, Web developer у Symphony Solutions та Дмитро Селін, Software Engineer у Facebook. Вони допоможуть розібратися, чи варто опановувати бібліотеку.

Особливості React

React універсальний. ЕЙого використовують для створення веб- та мобільних додатків. Для останніх є кросплатформовий фреймворк React Native.

Серед особливостей React — односпрямованість потоку даних, компонентний підхід, віртуальний DOM, модульність та декларативність.

Станіслав: «‎Компонент — ізольована частина інтерфейсу (меню, бічна панель, логотип, футер). Кожен з елементів інтерфейсу складається з різних компонентів. Зміна стану компонента впливає лише на його дочірні елементи, не чіпаючи інші частини інтерфейсу.

Односпрямованість потоку даних дає більше контролю за ними, отже — зменшує кількість помилок і полегшує налагодження.

Віртуальний DOM дозволяє оновлювати лише необхідні елементи сторінки.

DOM (document object model) — це об’єктна модель документа в браузері для відтворення розмітки. Це деревоподібне представлення сторінки, починаючи з тегу , яке зберігається в пам’яті браузера й показує те, що користувач бачить на сторінці. Якщо реальний DOM змінюється, браузер перемальовує й перекомпоновує частини сторінки або її повністю. Це ресурсовитратна операція.

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

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

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

Дмитро: «‎З трьох популярних інструментів — React, Angular і Vue — React найближче до ідей функціонального програмування. Одна з його особливостей — це декларативність, яка передбачає простіший у розумінні, підтримці та тестуванні код.

Говорячи про недоліки, розпочинати новий проєкт на React довше, ніж на тому ж Vue. CreateReactApp, де-факто стандарт для генерації проєкту та управління ним, має безліч обмежень у виборі та налаштуванні різноманітних плагінів. Будь-який великий проєкт рано чи пізно вимагатиме різних кастомізацій, і доведеться або робити eject і кастомізувати вручну, або впиратися в обмеження CRA.

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

Юрій: «React гнучкий та легкий для вивчення. На відміну від Angular, у ньому немає чітких патернів — як вигадав, так і буде. У цьому сенсі компаніям вигідно його використовувати: можна відносно швидко навчити джуніорів. З іншого боку, саме ця гнучкість може заплутати початківців. Саме тому на проєкті важливо створити чіткі домовленості та правила роботи з React.

Великий плюс бібліотеки — можливість зв’язатися з її розробниками — обговорити баг чи запропонувати покращення. Мені вдавалося поговорити навіть із Деном Абрамовим, одним із творців React.

Оскільки React — бібліотека для візуалізації, у якій робота з даними не була продумана, для управління станом програми використовували зовнішні бібліотеки. Але згодом у React удосконалили context — інструмент для збереження глобальних даних та передачі до компонентів. Тому, якщо говорити про створення простої програми, можна обійтися лише React без інших інструментів. Ця бібліотека також підійде стартапам або для розробки MVP».

База для вивчення React

Станіслав: «‎Щоб опанувати React, треба знати ази JavaScript: що таке функція, змінна, модулі, як читається програма, а ще краще — розуміти, як функціонують обробники подій, асинхронність, тротлінг. Будуть корисні знання тегів, CSS та сучасних стандартів JS: webpack, класи, стрілочні функції, синтаксис, черга подій, Babel та TypeScript. Формула проста: що краще знаєш JavaScript, то простіше розуміти React.

Рекомендую спершу вивчати лише сам React та необхідні інструменти розробки, не йдучи до вивчення інших бібліотек».

Дмитро: «‎Раджу розібратися у функціональному програмуванні: навіть мінімальне розуміння допоможе в опануванні React. 90 % бібліотеки можна вивчити за кілька місяців. Ще стільки ж потрібно, щоби напрацювати інтуїцію та досвід‎».

Додаткові інструменти для роботи з React

Юрій: «‎Існує багато бібліотек для React: розробник може написати свою та поділитися з колегами, додати її до npm (node ​​package manager — каталог бібліотек та інструмент для управління залежностями, через який можна додати залежності до проєкту). У світі frontend дуже багато залежностей, треба бути обережним із їхнім застосуванням. Був випадок, коли хтось видалив свою бібліотеку, яка використовувалася на багатьох проєктах, і чимало вебзастосунків “упали”‎».

Станіслав: «‎У моїй практиці найчастіше використовують:

• Webpack — збирач модулів JavaScript з відкритим вихідним кодом.
• Babel — бібліотека, яка конвертує код, написаний за сучасними стандартами ECMAScript, у вигляд, зрозумілий для будь-якого браузера.
• TypeScript —це надбудова JavaScript для розв’язання проблеми динамічної типізації. Також TypeScript дає змогу використовувати в проєкті нові інструменти, які ще не затверджені в стандарті».

Де ще почитати про React

Слідкувати за оновленнями, запитати поради чи почитати про рішення можна тут:

• офіційний блог React;
• блог Дена Абрамова, одного з ключових розробників React;
• спільнота React-розробників на Spectrum та Reactiflux;
• корисні статті на DEV — це спільнота для розробників програмного забезпечення, де вони діляться профільними матеріалами.

Вступ в React, якого нам не вистачало

React – це найпопулярніша в світі JavaScript-бібліотека. Але ця бібліотека хороша не тому, що популярна, а тому популярна, що хороша. Більшість існуючих вступних посібників з React починається з прикладів того, як користуватися цією бібліотекою. Але ці керівництва нічого не говорять про те, чому варто вибрати саме React.

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

Цей матеріал написаний для тих, хто хоче знайти відповідь на наступні питання: «Чому React? Чому React працює саме так? З якою метою API React влаштовано так, як влаштовано? ».

Чому React?

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

Коли з’явилася бібліотека React – це на фундаментальному рівні змінило те, як працюють JavaScript-фреймворки і бібліотеки. У той час як інші подібні проєкти просували ідеї MVC, MVVM та інші подібні, в React був обраний інший підхід. А саме, тут рендеринг візуальної складової програми був ізольований від представлення моделі. Завдяки React у фронтенд-екосистемі JavaScript з’явилася абсолютно нова архітектура – Flux.

Чому команда розробників React зробила саме так? Чому такий підхід краще тих, що з’явилися раніше за нього, начебто архітектури MVC і спагетті-коду, який пишуть на jQuery? Якщо ви з тих, кого цікавлять ці питання, можете подивитися цей виступ 2013 року, присвячене розробці JavaScript-застосунків в Facebook.

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

Наприклад, як заздалегідь дізнатися про те, що буде виведено на екрані в ситуації, коли що завгодно, в будь-який час і з будь-якої причини, може звернутися до DOM і внести туди зміни? Як забезпечити правильність побудови того, що побачить користувач?

Використовуючи популярні фронтенд-інструменти, які існували до React, нічого такого не можна було гарантовано забезпечити. У ранніх веб-застосунках «стан гонок» в DOM булв однією з найпоширеніших проблем.

Відсутність детермінізму = паралельні обчислення + стан що змінюється. Мартін Одерски

Головним завданням команди розробки React було рішення цієї проблеми. Вони з нею впоралися, застосувавши два основних інноваційних підходи:

• Односпрямована прив’язка даних з використанням архітектури Flux.
• Незмінність стану компонента. Після того, як стан компонента встановлено, він вже не може бути змінений. Зміни стану не зачіпають візуалізовані компоненти. Замість цього подібні зміни призводять до рендеринга нового представлення, що володіє новим станом.

Найпростіший виявлений нами спосіб структурування і рендеринга компонентів, з концептуальної точки зору, полягав в тому, щоб просто прагнути до повної відсутності мутацій. Том Оччіно, JSConfUS 2013

Бібліотека React змогла серйозно знизити гостроту проблеми неконтрольованих мутацій завдяки використанню архітектури Flux. Замість того щоб приєднувати до довільної кількості довільних об’єктів (моделей) обробники подій, що викликають оновлення DOM, бібліотека React дала розробникам єдиний спосіб управління станом компонента. Це – диспетчеризація дій, що впливають на сховище даних. Коли змінюється стан сховища, система пропонує компоненту повторно візуалізуватись.

Коли мені задають питання про те, чому варто звернути увагу на React, я даю просту відповідь: «Справа в тому, що нам потрібен детермінований рендеринг представлень, а React значно спрощує вирішення цього завдання».

Зверніть увагу на те, що читання даних з DOM заради реалізації якоїсь логіки – це анти-патерн. Той, хто так чинить, йде врозріз з метою використання React. Замість цього дані потрібно читати зі сховища, а рішення, основані на цих даних, потрібно приймати до того, як будуть візуалізовані відповідні компоненти.

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

JSX

JSX – це розширення JavaScript, що дозволяє декларативно створювати компоненти користувальницького інтерфейсу. JSX володіє наступними помітними можливостями:

• Застосування простої декларативною розмітки.
• Код розмітки розташований там же, де і код компонента.
• Реалізація принципу поділу відповідальностей (наприклад – відділення опису інтерфейсу від логіки стану і від побічних ефектів). Причому, реалізація, заснована не на використанні різних технологій (наприклад – HTML, CSS, JavaScript).
• Абстрагування управління змінами DOM.
• Абстрагування від особливостей різних платформ, для яких створюють React-застосунки. Справа в тому, що завдяки використанню React можна створювати застосунки, призначені для безлічі платформ (мова йде, наприклад, про розробку для мобільних пристроїв з використанням React Native, про застосунки для систем віртуальної реальності, про розробку для Netflix Gibbon, про створення Canvas/WebGL, про проект react-html-email ).

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

У наші дні, якщо поглянути на різні фронтенд-інструменти, виявиться, що без спеціального синтаксису, на зразок директиви *ngFor з Angular, теж не обійтися. Але, так як JSX можна назвати надмножиною JavaScript, створюючи JSX-розмітку можна користуватися існуючими можливостями JS.

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

Правда, при роботі з JSX потрібно враховувати деякі особливості, які, спочатку, можуть здатися незвичними.

• Тут використовується підхід до іменування атрибутів елементів, що відрізняється від того, який прийнятий в HTML. Наприклад, class перетворюється в className . Мова йде про застосування стилю іменування camelCase.
• У кожного елемента списку, який потрібно вивести, повинен бути постійний унікальний ідентифікатор, призначений для використання в JSX-атрибуті key . Значення ідентифікатора має залишатися незмінним в ході різних маніпуляцій з елементами списку. На практиці більшість елементів списків в моделях даних мають унікальні id, ці ідентифікатори зазвичай відмінно показують себе в ролі значень для key .

React не нав’язує розробнику єдино правильний спосіб роботи з CSS. Наприклад, компоненту можна передати JavaScript-об’єкт зі стилями, записавши його в властивість style . При такому підході більшість звичних імен стилів буде замінено на їх еквіваленти, записані за правилами camelCase. Але цим можливості по роботі зі стилями не обмежуються. На практиці я одночасно користуюся різними підходами до стилізації React-застосунків. Вибір конкретного підходу залежить від того, що саме потрібно стилізувати. Наприклад, глобальні стилі я застосовую для оформлення тем застосунків і макетів сторінок, а локальні стилі – для налаштування зовнішнього вигляду конкретного компонента.

Ось мої улюблені можливості React, що стосуються роботи зі стилями:

• CSS-файли, які можна завантажувати в головній частині сторінки. Вони можуть використовуватися для налаштування макетів сторінок, шрифтів та інших подібних елементів. Це – надійний, працездатний механізм стилізації.
• CSS-модулі – це CSS-файли область застосування яких обмежена локальною областю видимості. Їх можна імпортувати безпосередньо в JavaScript-файли. Для того щоб застосовувати CSS-модулі, потрібно скористатися правильно налаштованим загрузчиком модулів. У Next.js, наприклад, цей механізм активований за замовчуванням.
• Пакет styled-jsx, який дозволяє оголошувати стилі прямо в коді React-компонентів. Це нагадує використання тега в HTML. Область видимості таких стилів можна назвати «гіперлокальною». Мова йде про те, що стилі впливають тільки на елементи, до яких вони застосовуються, і на їх дочірні елементи. При застосуванні Next.js пакетом styled-jsx можна користуватися без необхідності самостійно щось підключати і налаштовувати.

Синтетичні події

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

1. Вони дозволяють згладити особливості різних платформ, пов’язані з обробкою подій. Це спрощує розробку кросбраузерних застосунків.
2. Вони автоматично вирішують завдання з управління пам’яттю. Якщо ви, наприклад, збираєтеся створити якийсь список з нескінченної прокруткою, користуючись лише чистими JavaScript і HTML, то вам доведеться делегувати події або підключати та відключати обробники подій у міру появи і приховування елементів списку. Все це потрібно буде робити для того щоб уникнути витоків пам’яті. Синтетичні події автоматично делегуються кореневому вузлу, що призводить до того, що React-розробникам не доводиться вирішувати завдання з управління пам’яттю.
3. В їх роботі використовуються пули об’єктів. Механізми підтримки синтетичних подій здатні генерувати тисячі об’єктів в секунду і організовувати високопродуктивну роботу з такими об’єктами. Якщо вирішувати подібні завдання, кожен раз створюючи нові об’єкти, це призведе до частої потреби у виклику збирача сміття. А це, в свою чергу, може привести до уповільнення програми, до видимих ​​затримок в роботі призначеного для користувача інтерфейсу і анімацій. Об’єкти синтетичних подій створюються заздалегідь і поміщаються в пул об’єктів. Коли потреби в події немає, воно повертається назад в пул. В результаті розробник може не турбуватися про те, що збирач сміття заблокує головний потік JavaScript, очищаючи пам’ять від непотрібними об’єктів.

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

Життєвий цикл компонента

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

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

У React, починаючи з версії 0.14, з’явився синтаксис описів компонентів, заснованих на класах, що дозволяє обробляти події життєвого циклу компонентів. В життєвому циклі React-компонентів можна виділити три найважливіші етапи: Mount (монтування), Update (оновлення) і Unmount (Демонтування).

Етап Update можна розділити на три частини: Render (рендеринг), Precommit (підготовка до внесення змін в дерево DOM), Commit (внесення змін до дерево DOM).

Зупинимося на цих етапах життєвого циклу компонента докладніше:

• Render – на цьому етапі життєвого циклу компонента проводиться його рендеринг. Метод компонента render() повинен являти собою детерміновану функцію, яка не має побічних ефектів. Цю функцію варто розглядати як чисту функцію, яка одержує дані з вхідних параметрів компонента і повертає JSX.
• Precommit – на цьому етапі можна прочитати дані з DOM, користуючись методом життєвого циклу компонента getSnapShotBeforeUpdate . Це може виявитися дуже до речі, наприклад, якщо перед повторним рендерингом компонента потрібно дізнатися щось на зразок позиції скролінгу або розмірів визуализированного елемента.
• Commit – на цій фазі життєвого циклу компонента React оновлює DOM. Тут можна скористатися методом componentDidUpdate або хуком useEffect . Саме тут можна виконувати ефекти, планувати оновлення, використовувати DOM і вирішувати інші подібні завдання.

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

Життєвий цикл React-компонентів

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

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

Іншими словами, більшість React-компонентів має сенс представляти собі у вигляді чистих функцій, які отримують вхідні параметри і повертають JSX. Чисті функції мають наступні особливості:

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

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

Хуки React

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

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

Хук useEffect дозволяє ставити побічні ефекти в чергу для їх подальшого виконання. Вони будуть викликатися в слушний час життєвого циклу компонента. Цей час може настати відразу після монтування компонента (наприклад – під час виклику методу життєвого циклу componentDidMount ), під час фази Commit (метод componentDidUpdate ), безпосередньо перед розмонтуванням компонента ( componentWillUnmount ).

Звернули увагу на те, що з одним хуком пов’язано цілих три методу життєвого циклу компонента? Справа тут в тому, що хуки дозволяють об’єднувати пов’язану логіку, а не «розкладати» її, як було до них, за різними методами життєвого циклу компонента.

Багатьом компонентам потрібно виконувати якісь дії під час їх монтування, потрібно щось оновлювати при кожному перемальовуванні компонента, потрібно звільняти ресурси відразу перед розмонтуванням компонента для запобігання витоків пам’яті. Завдяки використанню useEffect всі ці задачі можна вирішити в одній функції, не розділяючи їх рішення на 3 різних способи, не змішуючи їх код з кодом інших завдань, не пов’язаних з ними, але які теж потребують цих методів.

Ось що нам дають хуки React:

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

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

Компоненти-контейнери і презентаційні компоненти

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

• Компоненти-контейнери – це компоненти, які підключені до джерел даних і можуть мати побічні ефекти.
• Презентаційні компоненти – це, здебільшого, чисті компоненти, які, отримуючи на вхід одні і ті ж вхідні параметри і контекст, завжди видають один і той же JSX.

Чисті компоненти не слід ототожнювати з базовим класом React.PureComponent, який названий саме так через те, що його небезпечно використовувати для створення компонентів, які не є чистими.

▍Презентаційні компоненти

Розглянемо особливості презентаційних компонентів:

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

Саме через останній пункту цього списку я, кажучи про презентаційні компоненти, згадав про те, що це, по більшій частині це чисті компоненти. Ці компоненти зчитують свої стани з глобального стану React. Тому хуки, такі як useState та useReducer передають в їх розпорядження неявним чином певні дані (тобто – дані, не описані в сигнатурі функції), що, з технічної точки зору, не дозволяє назвати такі компоненти «чистими». Якщо потрібно, щоб вони були б по-справжньому чистими, можна делегувати всі завдання з управління станом компоненту-контейнеру, але я вважаю, що робити цього не варто, принаймні, до тих пір, поки правильність роботи компонента можна перевірити за допомогою модульних тестів.

▍Компоненти-контейнери

Компоненти-контейнери – це такі компоненти, які відповідають за управління станом, за виконання операцій введення-виведення і за вирішення будь-яких інших завдань, які можна віднести до побічних ефектів. Вони не повинні самостійно рендерити якусь розмітку. Замість цього вони делегують завдання рендеринга презентаційним компонентам, а самі служать обгорткою для таких компонентів. Зазвичай компонент-контейнер в React + Redux-застосунку просто викликає mapStateToProps() і mapDispatchToProps() , після чого передає відповідні дані презентаційним компонентів. Контейнери, крім того, можуть використовуватися для вирішення деяких завдань загального характеру, про які ми поговоримо нижче.

Компоненти вищого порядку

Компонент вищого порядку (Higher Order Component, HOC) – це компонент, який приймає інші компоненти і повертає новий компонент, який реалізує новий функціонал, заснований на вихідних компонентах.

Компоненти вищого порядку функціонують, обертаючи одні компоненти іншими. Компонент-обгортка може реалізовувати якусь логіку і створювати елементи DOM. Він також може передавати додаткові параметри, а може і не передавати.

На відміну від хуков React і від механізму render props, компоненти вищого порядку піддаються композиції з використанням стандартного підходу до композиції функцій. Це дозволяє декларативно описувати результати композиції можливостей, призначених для використання в різних місцях програми. При цьому готові компоненти не повинні знати про існування тих чи інших можливостей. Ось приклад HOC з EricElliottJS.com :

import < compose >from 'lodash/fp'; import withFeatures from './with-features'; import withEnv from './with-env'; import withLoader from './with-loader'; import withCoupon from './with-coupon'; import withLayout from './with-layout'; import withAuth from './with-auth'; import < withRouter >from 'next/router'; import withMagicLink from '../features/ethereum-authentication/with-magic-link'; export default compose( withEnv, withAuth, withLoader, withLayout(< showFooter: true >), withFeatures, withRouter, withCoupon, withMagicLink, );

Тут показана суміш безлічі можливостей, що спільно використовуються всіма сторінками сайту. А саме, withEnv читає налаштування з змінних оточення, withAuth реалізує механізм GitHub-аутентифікації, withLoader показує анімацію під час завантаження даних користувача, withLayout(< showFooter: true >) виводить стандартний макет з «підвалом», withFeature показує налаштування, withRouter завантажує маршрутизатор, withCoupon відповідає за роботу з купонами, а withMagicLing підтримує аутентифікацію користувачів без пароля з використанням Magic.

До речі, з огляду на те, що аутентифікація користувачів за допомогою пароля застаріла, і те, що це – небезпечна практика, в наші дні варто використовувати інші методи аутентифікації користувачів.

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

import LessonPage from '../features/lesson-pages/lesson-page.js'; import pageHOC from '../hocs/page-hoc.js'; export default pageHOC(LessonPage);

У подібних компонентів вищого порядку є альтернатива, але вона являє собою сумнівну конструкцію, звану «pyramid of doom» ( «піраміда смерті») і нею краще не користуватися. Ось як це виглядає:

import FeatureProvider from '../providers/feature-provider'; import EnvProvider from '../providers/env-provider'; import LoaderProvider from '../providers/loader-provider'; import CouponProvider from '../providers/coupon-provider'; import LayoutProvider from '../providers/layout-provider'; import AuthProvider from '../providers/auth-provider'; import RouterProvider from '../providers/RouterProvider'; import MagicLinkProvider from '../providers/magic-link-provider'; import PageComponent from './page-container'; const WrappedComponent = (. props) => ( >  >             );

І це доведеться повторити на кожній сторінці. А якщо треба буде щось в цій конструкції змінити, то зміни в ній доведеться вносити всюди, де вона присутня. Вважаю що недоліки такого підходу абсолютно очевидні.

Використання композиції для вирішення завдань загального характеру – це один з кращих способів зменшення складності коду застосунків. Композиція – це настільки важливо, що я навіть написав про це книгу.

Підсумки

• Чому React? React дає нам детермінований рендеринг візуальних уявлень компонентів, в основі якого лежить однонаправлена ​​прив’язка даних і незмінний стан компонентів.
• JSX дає нам можливість простого декларативного опису інтерфейсів в JavaScript-коді.
• Синтетичні події згладжують крос-платформні відмінності систем обробки подій і полегшують керування пам’яттю.
• Концепція життєвого циклу компонентів спрямована на захист стану компонентів. Життєвий цикл компонента складається з фаз монтування, оновлення і размонтирования. Фаза оновлення складається з фази рендеринга, фази підготовки до внесення змін в DOM і фази внесення змін до DOM.
• Хуки React дозволяють підключатися до методів життєвого циклу компонентів без використання синтаксису, заснованого на класах. Застосування хуків полегшує спільне використання одного і того ж коду в різних компонентах.
• Компоненти-контейнери і презентаційні компоненти дозволяють відокремити завдання формування візуального представлення інтерфейсів від завдань з управління станом застосунку та від побічних ефектів. Це покращує можливості по багаторазовому використанню і тестування компонентів і бізнес-логіки застосунку.
• Компоненти вищого порядку спрощують спільне використання можливостей, що представляють собою композицію інших можливостей. При цьому компонентам не потрібно знати про ці можливості (і не потрібно, щоб компоненти були б тісно пов’язані з ними).

Що далі?

У цьому матеріалі про React ми торкнулися безліч концепцій функціонального програмування. Якщо ви прагнете до глибокого розуміння принципів розробки React-застосунків, вам корисно буде освіжити свої знання про чисті функції, про іммутабельність, про карінг і частковому застосуванні функцій, про композиції функцій. Відповідні матеріали ви можете знайти на EricElliottJS.com.

Я рекомендую використовувати React спільно з Redux, Redux-Saga і RITEway. Redux рекомендується використовувати спільно з Autodux і Immer. Для організації складних схем роботи зі станом можна спробувати скористатися Redux-DSM.

Коли ви розберетеся з основами і будете готові до створення реальних React-застосунків, зверніть увагу на Next.js і Vercel. Ці інструменти допоможуть автоматизувати налаштування системи збирання проекту і CI/CD-конвеєра, з їх допомогою можна підготувати проєкт до оптимізованого розгортання на сервері. Вони дають той же ефект, що і ціла команда DevOps-фахівців, але користуватися ними можна абсолютно безкоштовно.

Які допоміжні інструменти ви застосовуєте при розробці React-застосунків?

javascript react frontend jsx

Помітили помилку? Повідомте автору, для цього достатньо виділити текст з помилкою та натиснути Ctrl+Enter