Що вміє React і де його застосовують
React відповідає лише за одне — як показати дані на екрані і як реагувати на дії користувача. Саме тому він такий поширений: його можна вбудувати в будь-який проєкт, від одного інтерактивного блоку на сайті до великого онлайн-сервісу.
Найчастіше на React роблять:
- особисті кабінети клієнтів, партнерів і співробітників;
- адмін-панелі, CRM-подібні системи, дашборди з графіками;
- онлайн-сервіси, де користувач щось налаштовує, бронює чи розраховує;
- інтерфейси маркетплейсів і каталогів з великою кількістю фільтрів;
- вбудовані віджети: калькулятор, конфігуратор товару, карту об’єктів.
Переваги React
- Компоненти повторно використовуються. Один раз зроблена таблиця чи форма працює на десятках екранів, а виправлення в ній з’являється всюди одночасно.
- Величезна екосистема. Для таблиць, графіків, форм, анімації, карт є готові перевірені бібліотеки.
- Багато розробників на ринку. Проєкт не стане заручником однієї команди: знайти людей, які розуміють React, простіше, ніж для інших бібліотек.
- Шлях у мобільні застосунки. Підходи й частину логіки можна перенести в React Native для застосунків під iOS і Android.
- Гнучкість. React не нав’язує структуру, тож його легко підлаштувати під наявний бекенд і процеси команди.
Недоліки й обмеження
- Це бібліотека, а не повний фреймворк. Маршрутизацію, роботу з даними, форми обирають окремо. Без досвіду легко зібрати несумісний набір рішень.
- Проблеми з пошуком у «чистому» вигляді. Застосунок, що збирається в браузері, пошуковики бачать гірше, тому для публічних сторінок потрібен серверний рендеринг — формування сторінок на сервері.
- Екосистема швидко змінюється. Рекомендовані підходи й популярні бібліотеки оновлюються, і проєкти кількарічної давнини часто потребують модернізації.
- Надлишковий для простих сайтів. Для сторінки послуг з формою заявки React додає складність і вагу без реальної користі.
Коли варто обрати інше
- Команда чи проєкт уже на Vue, або потрібен простіший старт для невеликої команди — розумно залишитися на Vue.js.
- Велика корпоративна система, де важливі жорсткі правила й однакова структура для багатьох розробників, — варто розглянути Angular.
- Контентний сайт, якому досить кількох інтерактивних елементів, — краще CMS і трохи JavaScript, ніж застосунок на React.
Дизайн-система і бібліотека компонентів
У великому інтерфейсі найдорожче — непослідовність: десять варіантів кнопок, різні відступи, таблиці, що поводяться по-різному. Ми розв’язуємо це бібліотекою компонентів, яка відповідає дизайну у Figma.
Кожен компонент має описані стани й варіанти, а нові екрани збираються з готових частин. Це пришвидшує розробку нових функцій і спрощує життя дизайнеру: зміна в дизайн-системі один раз переноситься в код, а не правиться на кожному екрані окремо.
Дані та стан інтерфейсу
Більшість проблем у React-проєктах пов’язана не з виглядом, а з даними: звідки вони беруться, де зберігаються і коли оновлюються. Ми дотримуємося простого правила — не тримати в спільному сховищі те, що можна отримати з сервера чи зберегти в самому компоненті.
Для даних із сервера використовуємо бібліотеки з кешуванням і автоматичним оновленням. Спільне сховище на Redux чи Zustand підключаємо лише тоді, коли багато частин інтерфейсу справді мають працювати з одними й тими самими даними. Так код лишається зрозумілим, а інтерфейс не перемальовується без потреби.
Швидкість і доступність інтерфейсу
React-застосунок легко зробити важким: кожна нова бібліотека додає код, який браузер має завантажити й виконати. На офісному комп’ютері це непомітно, а на недорогому смартфоні кабінет відкривається з помітною затримкою. Тому ми:
- ділимо код на частини, щоб розділ завантажувався лише тоді, коли користувач у нього переходить;
- перевіряємо, які бібліотеки займають найбільше місця, і замінюємо важкі там, де вистачає легшої альтернативи;
- показуємо каркас сторінки під час завантаження, а не порожній екран;
- довгі списки й таблиці відображаємо частинами.
Окремо стежимо за доступністю: правильні підписи полів, робота з клавіатури, достатній контраст тексту. Це важливо для людей з порушеннями зору і заодно робить інтерфейс зручнішим для всіх.
Новий інтерфейс чи доопрацювання наявного
Новий проєкт починаємо зі сценаріїв і набору компонентів, а не з вибору модних бібліотек. Одразу закладаємо TypeScript, правила форматування коду і збір помилок із браузерів користувачів.
Наявний проєкт спершу оцінюємо: версії React і бібліотек, розмір коду, що завантажується в браузер, причини повільних екранів, наскільки код покритий тестами. Старі класові компоненти, застарілі бібліотеки чи збирання на непідтримуваних інструментах переводимо поступово, паралельно з розробкою нових функцій.
Що впливає на вартість і терміни
- Кількість екранів і їхніх станів, а не лише кількість сторінок у макеті.
- Готовність бекенду: чи існує задокументований API, чи його потрібно створювати паралельно.
- Складні елементи: редаговані таблиці, графіки, перетягування, робота офлайн, оновлення в реальному часі.
- Дизайн: чи є дизайн-система, чи компоненти доведеться проєктувати разом з розробкою.
- Вимоги до доступності і підтримки старих браузерів.
Після розбору задачі розбиваємо роботу на етапи й пояснюємо, що входить у кожен.
Часті запитання
Чим React відрізняється від Next.js? React — бібліотека для інтерфейсу. Next.js — фреймворк поверх React, який додає сторінки, серверний рендеринг і SEO-можливості. Для кабінету достатньо React, для публічного сайту частіше потрібен Next.js.
Чи можна додати React у наявний сайт на CMS? Так. Окремий інтерактивний блок — калькулятор, конфігуратор, фільтр — можна зробити на React і вбудувати в сторінку, не переписуючи сайт.
Чи підійде React для інтерфейсу з тисячами рядків даних? Так, якщо правильно організувати відображення: показувати лише видиму частину таблиці, завантажувати дані порціями, не перемальовувати весь список при зміні одного рядка.
Чи можна поступово переписати старий інтерфейс на React? Так. Нові розділи робимо на React і вбудовуємо в наявну систему, а старі переносимо в міру того, як їх однаково потрібно змінювати. Так не доводиться зупиняти розвиток продукту на час переписування.
Ми отримаємо код, який зможе підтримувати інша команда? Так. Ми пишемо на TypeScript, дотримуємося поширених підходів і документуємо компоненти, тож проєкт можна передати іншим розробникам.
Чому Promodex
Promodex працює на ринку з 2015 року, у його доробку 750+ проєктів. У портфоліо — METEC і Supermarket Krasy, а також Komoot та OpenSea, у розробці яких ми брали участь. Дизайнери й розробники працюють в одній команді з 30+ людей і не залучають аутсорс, тому макети у Figma і компоненти в коді не розходяться. Вибір бібліотек ми обґрунтовуємо, а не нав’язуємо, і після запуску продовжуємо вдосконалювати інтерфейс.
