Якщо ви новачок у React (чи у фронтенді в цілому) екосистема може здатися вам заплутаною. І цьому є кілька причин.
- Історично React був орієнтований на ентузіастів та експертів
- Facebook віддає у опенсорс тільки те, що сам використовує, і таким чином не приділяє уваги інструментам для проектів за розмірами менше, ніж у Facebook
- Чимало поганенького маркетингу, замаскованого під путівники по React
У цьому документі я вважатиму, що ви створювали веб-сторінку, використовуючи HTML, CSS та JavaScript.
Навколо купа порад щодо React, що суперечать одна одній. Навіщо слухати мене?
Я працював у команді Facebook, що створила та опублікувала React. Я залишив Facebook, зараз працюю у невеликому стартапі, тож маю змогу порівняти.
Все програмне забезпечення створюється із набору технологій, так що вам потрібно розуміти достатню частину цього набору, щоб створити власний застосунок. Набір інструментів для React здається незрозумілим, бо пояснюється у неправильному порядку.
Вивчайте в такому порядку, не забігаючи наперед і не поєднуючи пункти:
Вам не потрібно все це вивчити, щоб продуктивно використовувати React. Переходьте до наступного пункту, тільки якщо в цьому виникає потреба.
Також у React-суспільстві часто обговорюють всілякі новинки. Нижче подано список цікавих, але важких у розумінні, новинок, значно менш популярних, ніж інструменти, зазначені у попередньому списку, без яких можна обійтись при створенні більшості застосунків.
Це поширена помилка, що вам необхідно витратити багато часу на налагодження інструментів, щоб почати вивчати React. В офіціальній документації ви знайдете "скопіюй-і-встав" HTML-шаблон, який ви можете зберегти у .html файл і почати працювати з ним. На цьому етапі не потрібно ніяких інструментів і не починайте їх вивчати, поки не освоїтесь із основами React.
Я й досі впевнений, що найлегший шлях до вивчення React - це офіціальний посібник.
npm - це менеджер пакетів Node.js і найпопулярніший спосіб поширення JavaScript коду, яким користуються фронтенд-розробники і дизайнери. До нього включено систему модулів CommonJS, за допомогою якої можна встановлювати інструменти командного рядка, написані на JavaScript. Прочитайте цю статтю, щоб зрозуміти для чого потрібен CommonJS браузерам, чи CommonJS Spec Wiki для подальшого знайомства із CommonJS API.
Більшість багаторазових компонентів, бібліотек та інструментів у екосистемі React доступні, як CommonJS модулі і встановлюються з допомогою npm.
CommonJS модулі (тобто все з npm) не можуть бути безпосередньо використані у браузері через ряд хороших причин технічного характеру. Вам потрібен JavaScript-пакувальник, щоб "спакувати" ці модулі в .js файли, які можна включити до веб-сторінки з допомогою <script> тегу.
Для прикладу, такими JavaScript-пакувальниками є webpack та browserify. Не прогадаєте, вибравши будь-який з них, але я надаю перевагу webpack, в який закладено купу можливостей, що полегшують розробку великих застосунків. Оскільки його документація може спантеличити, я створив готовий до використання шаблон і написав путівник по webpack для складніших випадків використання.
Варто пам'ятати, що CommonJS використовує функцію require() для імпорту модулів, через що багато людей помилково вважає, що він якось пов'язаний із проектом require.js. Я б не рекомендував require.js, зважаючи на ряд технічних причин. Він не такий вже й популярний у екосистемі React.
Окрім JSX (який ви вивчили з посібника по React), у прикладах з React вам могли трапитися чудернацькі синтаксичні конструкції. Їх називають ES6. Це найновіша версія JavaScript, яку ви можливо ще не вивчили. Оскільки вона така нова, браузери поки що не підтримують її, але правильно сконфігурований пакувальник може транслювати такий код у зрозумілий браузерам.
Для використання React вивчення ES6 не обов'язкове і його можна відкласти на потім, або спробувати освоїти між іншим.
Можливо ви чули, що React-компоненти переважно створюють, використовуючи ES6 класи. Це неправда. Більшість людей (у Facebook також) використовують React.createClass().
Зараз у моді "односторінкові застосунки". Такі веб-сторінки завантажуються один раз, а коли користувач клацає посилання чи кнопку, JavaScript, запущений на сторінці, оновлює адресний рядок, повністю не оновлюючи сторінку. За зміни у адресному рядку відповідає роутер.
Найпопулярніший роутер у екосистемі React - react-router. Якщо ви створюєте односторінкові застосунки, використовуйте саме його, якщо немає вагомих причин не робити цього.
Не використовуйте роутер, якщо ви не створюєте односторінкові застосунки. В будь-якому випадку, більшість проектів все одно починається з невеличких компонентів усередині існуючого великого застосунку.
Можливо ви чули про Flux. Навколо сила силенна дезінформації про нього.
Величезна кількість людей, сідаючи розробляти застосунок, бажають описати модель данних і думають, що Flux саме те, що їм потрібно. Це неправильний підхід до вибору Flux. Додавайте його тільки тоді, коли вже написано багато компонентів.
React-компоненти організовані в ієрархію. У більшості випадків ваша модель теж так організована. В такому разі від Flux небагато користі. Бувають випадки, коли ваша модель організована інакше. Вам варто глянути в бік Flux, коли ваші React-компоненти починають отримувати явно сторонні властивості (props) чи невелика кількість компонентів перетворюється у щось дуже складне.
Ви зрозумієте, коли вам знадобиться Flux. Якщо ви не впевнені, чи потрібен він вам, то скоріше за все непотрібен.
Якщо ви вирішили використовувати Flux, Redux - найпопулярніша Flux бібліотека з хорошою документацією. Навколо неймовірна кількість інших варіантів і багато з них ви забажаєте спробувати, але я раджу вам користуватися найпопулярнішою бібліотекою.
До появи React багато людей повторно використовували CSS-стилі зі складними таблицями стилів, створеними препроцесорами на кшталт SASS. Оскільки React спростив написання багаторазових компонентів, ваші стилі можуть бути не такими складними. Багато хто з суспільства (я також) пробують взагалі відмовитися від стилів.
Це досить безумна ідея з ряду причин. Ускладнюються медіа-запити (media queries) і цілком можливо, що використання цієї техніки обмежується швидкодією. Беручись за React, використовуйте стилі, як звикли.
Ознайомившись з тим, як працює React, можете спробувати інші техніки. Одна з популярних - БЕМ. Я рекомендую потрохи відмовлятися від CSS препроцесора, адже React пропонує повторно використовувати стилі у більш гнучкий спосіб (через повторне використання компонентів) і ваш JavaScript пакувальник зможе згенерувати для вас ефективніші таблиці стилів (я розповідав про це на OSCON). З урахуванням сказаного, React, як і будь-яка інша JavaScript-бібліотека, буде достатньо хорошо працювати у поєднанні з CSS препроцесором.
Як варіант, можете спробувати CSS Modules, точніше кажучи react-css-modules. Із CSS Modules ви, як і раніше, будете писати CSS (або SASS/LESS/Stylus), але ви зможете організувати CSS файли так, ніби це вбудовані стилі в React. Вам ні до чого перейматись іменуванням класів, як у БЕМ, - це зробить за вас система модулів.
Рендер на боці сервера часто називають "універсальним" чи "ізоморфним" JS. Це значить, що ви можете взяти ваші React-компоненти і відрендерити їх у статичний HTML на боці сервера. Це позитивно вплине на сприйняття швидкодії сайту при завантаженні, оскільки користувачу не доведеться чекати завантаження JS, щоб побачити початковий UI, а React може використати вже відрендерений на боці сервера HTML і не генерувати його на боці кліента.
Вам потрібно рендерити на сервері, якщо ви помітили, що початковий рендер надто повільний чи ви хочете покращити ранжування сайту пошуковою системою. Хоч це і правда, що Google індексує вміст, відрендерений на клієнті, станом на січень 2016 року усі виміри показали негативний вплив такого рендерингу на ранжування, можливо через його повільність.
Для того щоб правильно організувати рендер на боці сервера також потрібно чимало інструментарію. Так як React-компоненти, написані без гадки про серверний рендеринг, підтримуються в цілому прозоро, рекомендується спочатку написати застосунок, а потім приділити увагу рендеру на боці сервера. Вам не доведеться переписувати всі ваші компоненти, якщо ви вирішите рендерити їх на сервері.
Immutable.js надає набір структур данних, з допомогою яких можна вирішити певні проблеми швидкодії застосунку, розробленого з використанням React. Це відмінна бібліотека і ви скоріше за все будете застосовувати її не раз по мірі розростання ваших застосунків, але вона зовсім непотрібна, поки заміри швидкодії не переконають вас у протилежному.
З допомогою цих технологій ви скоротите кількість AJAX запитів. Вони все ще незрілі, так що за відсутності проблеми із кількістю AJAX запитів, Relay чи Falcor вам не потрібні.