Про бравого React'е замовте слово

Здрастуйте, шановні читачі!

Поспішаємо вас порадувати — ми вже щосили переводимо книгу відомого Стояна Стефанова про бібліотеку React



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



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

Два основних заперечення в пику React такі:

  1. Його неповнота — React не є «полностековым» фреймворском на відміну від Meteor або Angular. У ньому немає маршрутизатора, системи моделей і багатьох інших можливостей, які належить мати фреймворку. Кажуть, що він реалізує лише «V» з MVC, але це далеко не так, про що я і збираюся поговорити.
  2. синтаксис — тут змішані HTML і Javascript. Програміст дивиться на JSX і запитує: «але… навіщо?». А деякі навіть виступають за підмішування CSS.


Я постараюся висвітлити обидві ці проблеми, а також загострю увагу на певних сильних сторонах React. Отже, поїхали!

Отже, що ж таке React?

React – це javascript-бібліотека для створення компонентів. Кожен компонент має «зовнішнім виглядом», який задається методом render і деякими станами, обумовленими в
getInitialState
. Зовнішній вигляд залежить від поточного стану. Ось, власне, і все. І ось чому буває так важко пояснити React – у багатьох він викликає саме таке відчуття «неповноти».

Приклад:

Counter = React.createClass
getInitialState: ->
count: 0

increment: ->
@setState(count: @state.count + 1)

render: ->
<div>
{ @state.count }
<button onClick={ @increment }>+</button>
</div>


У цьому прикладі у нас є кнопка, при натисканні на яку викликається метод инкремента. Метод
increment
викликає setState, таким чином, задається нове число, на одиницю більше від поточного.

Метод
setState
знову відображає компонент. Це робиться настільки оригінально, що саме в цьому React і його клони відрізняються від аналогічних інструментів. В сутності, React зберігає в пам'яті об'єктну модель документа, іменовану «віртуальної DOM» («тіньова DOM — трохи інший феномен), а потім обчислює різницю між цією DOM і тієї, що відображена у браузері. На підставі цієї різниці складається список змін, які необхідно внести – уявіть собі
createElement
– а потім ці зміни застосовуються.
Зрозуміло, в React доведеться познайомитися і з багатьма іншими концепціями —наприклад, властивості (props), різні атрибути тегів – але найбільш важлива саме DOM.

У чому дорікають React

Неповнота. Погано чи добре?

Коли з'явилися Rails, в них особливо рекламувалася їх «полностечность» (сподіваюся, є таке слово). З тих пір жодна з альтернатив не вийшла настільки ж самодостатньою – адже в Rails є і рівень абстрагування бази даних, і система маршрутизації, і шаблонизатор, і т. д.

Наскільки мені відомо, першою з альтернатив став Camping від Why – микрофреймворк, що складався з кількох рядків коду. За ним пішли Sinatra, CherryPy, Flask, Express та багато інших. Але справа в тому, що всі вони продовжують емулювати концепцію фреймворку, просто виходять трохи тонше, а також написані менш упереджено. А ці інструменти продаються завдяки тому, що з ними не так багато метушні і, відповідно, вони більш зручні для розробки порівняно дрібних додатків.

Та неповнота, якою відрізняється React, принципово інша. React – не просто полегшений Angular, а щось принципово інше. Він дуже добре справляється з конкретним завданням: працює з веб-компонентами. Отже, неправильно міркувати про те, якого розміру має бути наш проект. До речі, React робився з упором на продуктивність, саме на ньому працює система коментарів у Facebook – отже, він поза всяких сумнівів здатний працювати в колосальних масштабах.

Ось про що варто задуматися: чи потрібний вам повноцінний фреймворк і, крім того, ви зможете організувати всі необхідні компоненти на базі React. По-перше, слід зазначити, що розмір машинного інтерфейсу, в сутності, не важливий. Якщо вам доводиться завантажувати фреймворк розміром 1ГБ, але на виході виходить гнучке і швидке додаток, то це не проблема. З іншого боку, розмір фронтенда дуже важливий. Будь-яка додаткова навантаження від вашого фреймворку відразу вплине на кінцевий результат.

Є в React та інші чудові можливості, завдяки яким він сприймається як повноцінний фреймворк. Мені відомо багато прикладів підмішування моделей Backbone в React. Є і відмінні бібліотеки для додавання маршрутизації. Але одне з основних досягнень співтовариства React – це, звичайно, Flux, хоча це і не стільки набір інструментів, скільки підхід до архітектури програми.

чи Правда, що React – всього лише V з абревіатури MVC?

Як зазначає Андре Медейрос у своїй чудовій презентації, можливості React далеко не обмежуються V. Справа в тому, що у компонентів React є стан, тому такий компонент – в деякому сенсі Модель. Він забезпечує відображення введення на зміну стану, тому, в той же час, має риси Контролера, або навіть Уявлення, підкреслює Медейрос. Компонент також обмінюється інформацією з іншими компонентами і залежить від них. Отже, вам не доведеться шукати відповідні бібліотеки для моделі і контролера – подібну думку просто помилково.

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

Медейрос пропонує вирішувати ці проблеми, взявши на озброєння принцип MVI — Модель-Вид-Намір — тобто, пропагує досить своєрідний підхід до веб-розробці. Одна з реалізацій цього підходу називається Цикл.

Навіщо змішувати HTML JS?… Що? І CSS теж???

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

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

Все це може викликати відторгнення, яке, на мій погляд, пояснюється найчистішими необґрунтованими забобонами. Всього через кілька годин звикаєш. Всі думки про React, які я знайшов в Інтернеті, по суті, однакові. Раптом позбавляєшся від необхідності тримати два відкритих файлу в сусідніх вкладках — і продуктивність праці різко зростає.
Деякі навіть виступають за те, щоб повністю перенести CSS в область компонента. Перш, ніж таврувати мене, подивіться цікаву презентацию на цю тему від Крістофера Чедау.

Аргументи в захист React

Тут є екосистема

Я пишу цю статтю, а React тільки що обійшов Ember за рейтингом на GitHub. Він поступається Backbone і, природно, Angular, але росте набагато швидше «конкурентів».

React – це проект Facebook, саме на ньому реалізована система коментування в Facebook і більшість проектів цієї компанії. Крім того, React широко застосовується в Pinterest, AirBnB, Khan Academy та масі інших стартапів. На основі React збудований редактор Atom, більше того, і Microsoft підтримує React.

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

Простіше судити про коді

Один з основних аргументів на користь React пов'язаний з його логічністю. Це гранично вірне твердження, і не можна недооцінювати його вагомість і важливість.

Судити про коді, на мій погляд — це не просто вміти виокремлювати в ньому слабо і сильно пов'язані ділянки. Це значить, логічно випливати від усвідомлення проблеми до розуміння того, де і що відбувається (події, потоки даних...), швидко оцінювати ці елементи і, нарешті, усувати проблему.

Цікава річ: замислюючись про якість програми, потрібно звертати увагу не тільки на кількість багів – у нас в Agile взагалі проповідується ідея, що «ніяких багів бути не повинно», — але й на те, скільки часу буде потрібно на виправлення бага. Засвоївши цю ідею, я згадав баг, який вдалося зжити тільки через рік. Він учинял жахливі витоку пам'яті і значно гальмував всю програму, особливо при пікових навантаженнях. Якщо виходити лише з кількості багів, то, цілком можливо, у вас буде всього лише жменька таких вад, але саме рішення при цьому все одно виявиться дуже поганим.

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

// html
<section>
<div class="toggled">HERE I AM</div>
<button class="toggler">Toggle!</button>
</section>

// coffescript
$('.toggler').on 'click', ->
$('.toggled').toggle()


На перший погляд, все просто. Але ось у чому заковика: а як ви дізнаєтеся, відобразилося div? Так, можна сказати: «Якщо натиснути на кнопку button будь-яке парне кількість разів, то він з'явиться, а якщо ні – не відобразиться».

Toggler = React.createClass
getInitialState: ->
visible: true

toggle: ->
@setState(visible: !@state.visible)

render: ->
<section>
{ @state.visible && <div>HERE I AM</div> }
<button onClick={ @toggle }>Toggle!</button>
</section>


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

Переиспользование

Це чарівне слово. У світі бекенду переиспользование фрагментів коду – реальність. Мова може йти, наприклад, про самоцветах або яйцях. Але в клієнтській частині може здатися, що для кожного нового проекту все доводиться перезбирати заново. Дійсно, такі речі, як інструмент обходу DOM або URL-парсер переиспользовать легко, але коли справа доходить до контенту як такого, кожен проект починає виглядати по-своєму, а кожен елемент макета – сама оригінальність, яка не лізе «під одну гребінку».

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

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

Вирощування проекту

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

От і все. Власне, тут я майже не зачепила тему Flux, але це вже матеріал для зовсім іншої статті.


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

0 коментарів

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