Рік використання ReactJS: підводимо підсумки

React ми Voximplant любимо і цінуємо. Зовсім не з-за хайпи (півтори тисячі твітів про новий SDK просто тому, що це React Native) а тому, що фреймворк дійсно зручний. Просте дроблення інтерфейсу на маленькі ізольовані шматочки – це те, чого так не вистачало і Jade/Pug, Web Components, і навіть Angular. Під катом адаптований переклад статті, в якій розробники JetRuby Agency діляться враженнями про React: що використовували, що не використовували і що ще тільки планують використовувати.


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

Нещодавно ми закінчили проект, який використовував рендеринг на стороні клієнта і API сервер на Rails. Загальне враження – глибоко позитивне.

Що нам сподобалося:

  • Хороші і зрозумілі исходники. Декларативний стиль React дозволяє легко розуміти код і уникати непотрібної складності. Яка так і норовить скупчитися в UI.
  • Явне розмежування на серверний та клієнтський код. Можна легко розділяти завдання між фронтенд і бекенд розробниками, і вони не будуть перетинатися один з одним.
  • Завдяки технології Virtual DOM зміни сторінки відбуваються дуже швидко (за винятком вироджених випадків на кшталт ігор або чогось настільки ж інтерактивного). Але варто зауважити, що останнім часом ми часто зустрічаємо статті (наприклад, ось ця), автори яких стверджують, що React повільний.
  • Якщо ви хочете відкрити API назовні, то розробка SPA додатки для нього буде найкращим з можливих тестів. Причому код, який взаємодіє з бекендом, можна винести в один або кілька окремих модулів: це набагато краще, ніж хардкодить AJAX запити в Flux. Наприклад, модуль для роботи з налаштуваннями може робити різні запити в залежності від того, запущено програму на виявляли у своєму житті таку або на стейдже.
  • Велика кількість різних реалізацій Flux. Добре, якщо ви любите тримати руку на пульсі технологій. Погано, якщо просто хочете швидко щось зробити і не знаєте, що вибрати. Деякі реалізації використовують кілька «сторів», інші – один глобальний об'єкт з FRP або евент для координування компонентів. Завжди можна вибрати те, що більше подобається. Ми вибрали «Fluxxor», але не використовуємо його реалізацію сторів, тільки actions. Для роботи з станом ми вибрали підхід з одним глобальним об'єктом і використовуємо бібліотеку «Baobab». З боку виглядає як переусложнение, але нам в компанії подобається гнучкість.
Природно, в цьому прекрасному новому світі не все так чудово. З низкою проблем ми все ж зіткнулися:

  • Недолік добре підтримуваних, готових до використання компонентів. Звичайно, це питання курки і яйця – їх кількість збільшиться разом із зростанням популярності самого React. Але ми живемо тут і зараз.
  • Форми і валідація. Їх складно робити. Плюс готових високорівневих бібліотек для створення форм не те щоб багато.
  • Для свого програми ми використали кастомний тему з великою кількістю коду jQuery. Виявилося, що її не так просто легко інтегрувати в React додаток! Технічно можливо, але я б не рекомендував займатися цим, якщо у вас є вже готові компонент або ресурси, щоб таке зробити з нуля. У нашому випадку був потрібен date time picker на bootstrap, і ми не знайшли хорошого готового ( не володів усіма потрібними нам функціями). Так що у нас не залишалося вибору, крім як оформити відповідний jQuery плагін у вигляді компонента React. Якщо вам цікава ця тема, то ви можете прочитати більше тут.
Кілька технічних рішень, які нам здаються правильними і які ми хочемо рекомендувати:

  • Використовуйте один стор. І ось чому. По-перше, основна проблема з кількома сторами – їх синхронізація. Якщо вам потрібні дані з одного стора, для яких потрібні дані з іншого стора, вам доведеться прописувати це в явному вигляді за допомогою функції waitFor(). Із зростанням додатки таких зв'язків буде все більше і вам буде все важче керувати ними. Використання одного стора для управління станам вирішує подібні проблеми. Гарним кандидатом для такого стора є реалізація бібліотеці «Baobab». Можете розглядати його як різновид локальної бази даних, яка живе на фронтенде.
  • Використовуйте webpack для складання модулів. Зараз для такої збірки є безліч рішень, наприклад, grunt або gulp спільно з browserify або requirejs, але webpack трохи могутніше. Пряме включення css, зображень і шрифтів в React компоненти дозволяє зробити css більш керованим.
  • Використовуйте курсори, щоб передавати дані React компонентів. Ця потужна абстракція дозволяє не передавати проміжні дані вниз по «ланцюжку» компонентів, що сильно спрощує код. Ми використовували курсори з Baobab, але є багато інших хороших реалізацій. Baobab був обраний з-за його простоти, прямолінійності і готової інтеграції з React, підтримуючої PureRenderMixin
Що ми хочемо спробувати в наступному додатку:

Використовувати Babel

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

Ізоморфні програми

Прямо зараз це тренд. Якщо ще не чули про такий підхід, ось хороший огляд від команди Airbnb. Ідея полягає в тому, щоб отрендерить HTML-сторінку на сервері, передати її на клієнт (з кешування і CDN) щоб вона миттєво відобразилася в браузері, а потім, коли завантажитися JavaScript, ReactJS «подцепится» до вже отрендеренной сторінці та додаток «оживе».

Використовувати Functional Reactive Programming (FRP) для координації (як диспатчер Flux)

Є кілька хороших бібліотек для використання FRP в JavaScript (RxJS, Bacon, Kefir). Основна ідея в тому, щоб представити змінні як послідовність їх змін, і комбінувати ці зміни за допомогою таких функцій, як map, filter, reduce і функцій вищого порядку (функція, яка приймає іншу функцію як аргумент). Для користувацького інтерфейсу такий підхід дає можливість перетворити послідовність евентов в потік евентов і маніпулювати такими потоками як об'єктами.

Один стор для управління станом

Дає всього одна, але величезна перевага. Так як в компонентах React немає локального стану, то можна розглядати UI як одну чисту функцію (термін з функціонального програмування) яка отримує одне стан на вхід у вигляді аргумент і повертає інтерфейс (точніше, його React-подання), що відповідає цьому стану. На практиці такий підхід дає можливість налагодження в реальному часі, undo і redo, time travel. Тут можна подивитися, як це все зроблено:

Такий підхід виводить тестування і налагодження веб додатків на принципово новий рівень. Більше не потрібні скріншоти і довгий список «кроків відтворення». Якщо ви зустріли баг – просто скопіюйте поточний стан програми і віддайте його розробникам.

Иммутабельные структури даних

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

Автор зображення (перед катом) – Stefpet, Сreative Commons 2.0.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.