ReactJS для дурних людей

Намагаючись розібратися з бібліотекою від Facebook ReactJS і просуває тією ж компанією архітектурою «Flux», натрапив на просторах інтернету на дві цікаві статті: «ReactJS For Stupid People» і «Flux For Stupid People». Вирішив поділиться з хабровчанами перекладом першої (а трохи пізніше і другий) статті. Отже, поїхали.

ReactJS для дурних людей
TL;DR протягом довгого часу я намагався зрозуміти, що таке React і як він вписується в структуру програми. Це стаття, якої мені свого часу не вистачало.

Що таке React?
Чим відрізняється React від Angular, Ember, Backbone та інших? Як керувати даними? Як взаємодіяти з сервером? Що, чорт візьми, такий JSX? Що таке «component»?

СТОП.

Зупиніться прямо зараз.

React — це ТІЛЬКИ РІВЕНЬ ПОДАННЯ.

React часто згадують в одному ряду з іншими javascript фреймворками, але суперечки «React vs Angular» не мають сенсу, тому що це не співмірні речі. Angular — це повноцінний фреймворк (що включає і рівень подання). React — ні. Ось чому React викликає стільки нерозуміння у світі, що розвивається повноцінних фреймворків — це лише уявлення.

React дає вам мову шаблонів і деякі callback-функції для відтворення HTML. Весь результат роботи React — це HTML. Ваші зв'язки HTML/JavaScript, що називаються компонентами, займаються тим, що зберігають свій внутрішній стан в пам'яті (наприклад: яка закладки), але в підсумку вам просто спльовують HTML.

Зрозуміло, ви не можете побудувати повно функціонує динамічне додаток тільки з React. Чому, ми розглянемо пізніше.

Плюси
Після роботи з React, я побачив три дуже важливих переваги.

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

Скажімо, вам потрібно змінити заголовок вашого сайту на ім'я користувача після реєстрації. Якщо ви не використовуєте який-небудь MVC фреймворк, ви можете зробити щось на зразок:

<header> 
<div class="name"></div>
</header> 


$.post('/login', credentials, function( user ) {
// Modify the DOM here
$('header .name').show().text( user.name );
});


З досвіду можу сказати, що цей код зіпсує життя вам і вашим колегам. Як виробляти налагодження? Хто змінює заголовок? Хто має доступ до заголовка? Хто визначає видимість? Маніпуляція з DOM так само погана, як оператор GOTO в логіці вашої програми.

Ось як ви могли б зробити це з React:

render: function() { 
return <header>
{ this.state.name ? <div>this.state.name</div> : null }
</header>;
}


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

2. Зв'язування JavaScript і HTML в JSX робить компоненти простими для розуміння.
Дивне поєднання HTML/JavaScript може вас збентежити. Нас вчили не вставляти JavaScript в DOM (наприклад: обробники OnClick), ще в той час, коли ми були маленькими» розробниками (ор: since we were wee developers). Але ви можете мені вірити, рабоать з JSX компонентами це насправді чудово.

Зазвичай ви поділяєте подання HTML і функціональність (JavsScript). Це призводить до монолітного JavaScript файлу, який містить всю функціональність для однієї сторінки, і ви повинні стежити за складним потоком JS->HTML>JS->неприємна ситуація.

Зв'язування функціональності безпосередньо з розміткою і упаковка цього в портативний, автономний «компонент», зробить вас щасливішим, а ваш код у цілому краще. Ваш Javasacript «добре знайомий» з вашим HTML, так що змішувати їх має сенс.

3. Ви можете рендери React на сервері.
Якщо ви розробляє публічний сайт або додаток, і ви рендерите все на клієнті, то ви вибрали неправильний шлях. Клієнтський рендеринг — це причина, чому SoundCloud працює повільно, і чому Stack Overflow (використовуючи тільки серверний рендеринг) працює так швидко. Ви можете рендери React на сервері, і ви повинні цього робити.

Angular та інші заохочують використання PhantomJS для рендеринга сторінок і надання її пошуковим движка (грунтуючись на user-агента) або використання платних сервісів. ТЬХУ!

Мінуси
Не забувайте, що React — це лише уявлення.

1. Ви не отримаєте наступне:
  1. Систему подій (відмінну від нативних DOM подій);
  2. Роботу з AJAX;
  3. Якийсь шар даних;
  4. Promises;
  5. Фреймворк на всі випадки життя;
  6. Якісь думки про те, як реалізувати все вищевказане.


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

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

image

Тут три окремих, конкуруючі туториала для початківців. Це дивує. Бічна панель нижче, немов з моїх нічних кошмарів, з розділами, які точно не повинні бути тут, такі як «More About Refs» і «PureRenderMixin» (прим. перекладача: плагін для React).

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

image

35 KB gzipped
Це без бібліотеки reacat-with-addons, яка вам потрібна для розробки реального додатка!
Це без бібліотеки ES5-shim, необхідної для підтримки IE8!
Це без будь-якої іншої бібліотеки!

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

Годі говорити «FLUX»
Мабуть, сама дражлива частина при розробці на React — це «Flux». Заплутуючий ще більше, ніж React. Роздуте поняття «Flux» сильно заважає розумінню. Немає такої речі, як Flux. Flux — це концепція, але не бібліотека. Окей, є Flux бібліотека з чимось на зразок:
Flux швидше патерн, ніж фреймворк


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

Концепція Flux проста: ваше уявлення викликає подія (наприклад: користувач вводить ім'я в текстове поле), подія змінює модель, потім модель викликає подія, подання реагує на подію моделі і оновлюється з новими даними. От і все.

Односпрямований потік даних і шаблон проектування «спостерігач» гарантує, що ваші сховища/моделі, завжди знаходиться в актуальному стані. Це корисно.

Поганий стороною Flux є те, що кожен заново винаходить його. Так і немає домовленості про бібліотеки подій, шарі моделі, AJAX шарі і іншого, є багато різних реалізацій «Flux» і всі вони конкурують між собою.

чи Повинен я використовувати React?
Коротка відповідь: так.

Розгорнутий відповідь: на жаль, для багатьох речей.

Чому ви повинні використовувати React:
  • Відмінно підходить для командної розробки, суворе дотримання UI, і шаблону робочого процесу;
  • UI код читабельний і простий у супроводі;
  • Розробка UI на основі окремих компонентів — це майбутнє web-розробки і ви повинні почати робити це вже зараз.


Чому ви повинні двічі подумати перед вибором:
  • На початковому етапі React уповільнює роботу. Зрозуміти, як працюють props, state і як взаємодіють компоненти непросто, а документація — це «лабіринт з інформації». В теорії це може бути вирішено швидко, якщо над цим працюватиме ціла команда;
  • React не підтримує браузери від IE8 і молодше, і ніколи не буде;
  • Якщо ваш додаток/веб-сайт не насичені великою кількістю динамічних сторінок, вам доведеться писати дуже багато коду, вирішуючи маленькі завдання;
  • Ви будете заново винаходити велосипеди. React молодий, тому немає вироблених практик. Вашій додатком потрібен дропдаун, ресайз вікна або лайтбокс? Вам доведеться писати все це з нуля.


Підсумок:

Читайте наступний пост: «Flux For Stupid People».

Я сподіваюся, ця стаття допоможе таким же дурним людям, як і я, краще зрозуміти React. Якщо цей пост зробив ваше життя простіше, можете підписатися на мене в Твітері.

Джерело: Хабрахабр

0 коментарів

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