{"componentChunkName":"component---src-templates-docs-js","path":"/docs/thinking-in-react.html","result":{"data":{"markdownRemark":{"html":"

З нашої точки зору, React — це відмінний спосіб писати великі і швидкі JavaScript-додатки. Він дуже добре масштабувався для нас у Facebook та Instagram.

\n

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

\n

Почнемо з макета

\n

Уявіть, що у нас вже є JSON API і макет дизайну сайту. Він виглядає так:

\n

\n \n \n \n \n \n

\n

Наш JSON API повертає дані, які виглядають наступним чином:

\n
[\n  {category: "Sporting Goods", price: "$49.99", stocked: true, name: "Football"},\n  {category: "Sporting Goods", price: "$9.99", stocked: true, name: "Baseball"},\n  {category: "Sporting Goods", price: "$29.99", stocked: false, name: "Basketball"},\n  {category: "Electronics", price: "$99.99", stocked: true, name: "iPod Touch"},\n  {category: "Electronics", price: "$399.99", stocked: false, name: "iPhone 5"},\n  {category: "Electronics", price: "$199.99", stocked: true, name: "Nexus 7"}\n];
\n

Крок 1: Розіб’ємо інтерфейс на компоненти

\n

Перше, що треба зробити – це уявити кордони кожного компонента (і підкомпонента) в макеті та дати їм імена. Якщо ви працюєте з дизайнерами, цілком можливо, що вони вже якось називають компоненти – вам варто поспілкуватися! Наприклад, шари Photoshop часто підказують імена для React-компонентів.

\n

Але як вибрати, що є компонентом, а що ні? Це схоже на те, як ви вирішуєте, чи треба оголосити функцію або об’єкт. Можна застосувати принцип єдиного обов’язку: кожний компонент в ідеалі повинен займатися якимось одним завданням. Якщо функціонал компонента збільшується з плином часу, його слід розбити на більш дрібні підкомпоненти.

\n

Багато інтерфейсів показують модель даних JSON. Тому добре побудована модель, як правило, вже відображає призначений для користувача інтерфейс (а значить, і структуру компонентів). Інтерфейс і моделі даних часто мають схожу інформаційну архітектуру, тому розділити інтерфейс на частини не складає труднощів. Розбийте інтерфейс користувача на компоненти, кожен з яких відображає частину моделі даних.

\n

\n \n \n \n \n \n

\n

Ви побачите, що ми маємо п’ять компонентів у нашому додатку. Дані, які представляє кожен компонент, виділено курсивом.

\n
    \n
  1. FilterableProductTable (помаранчевий): містить весь приклад
    2. \n
  2. SearchBar (синій): приймає всі вхідні дані користувача
    3. \n
  3. ProductTable (зелений): відображає та фільтрує збір даних на основі вхідних даних користувача
    4. \n
  4. ProductCategoryRow (бірюзовий): відображає заголовок для кожної категорії
    5. \n
  5. ProductRow (червоний): відображає рядок для кожного продукту
    6. \n
\n

Зверніть увагу, що заголовок таблиці всередині ProductTable не є окремим компонентом. Відокремлювати його чи ні — це питання особистих уподобань. У цьому прикладі ми залишили його як частину ProductTable, оскільки він є малою частиною загального збору даних. Проте, якщо в майбутньому заголовок поповниться новими функціями (наприклад, можливістю сортувати товар), є сенс витягти його в самостійний компонент ProductTableHeader.

\n

Тепер, коли ми визначили компоненти в нашому макеті, давайте розташуємо їх в порядку підпорядкованості. Компоненти, які є частиною інших компонентів, в ієрархії відображаються як дочірні:

\n\n

Крок 2: Побудуємо статичну версію в React

\n

Приклад коду Філософія React: Крок 2 на CodePen.

\n\n

Тепер, коли всі компоненти розташовані в ієрархічному порядку, прийшов час реалізувати наш додаток. Найлегший спосіб – створити версію, яка використовує модель даних і рендерить інтерфейс, але не передбачає ніякої інтерактивності. Корисно розділяти ці процеси, тому що написання статичної версії вимагає багато друкування і зовсім небагато мислення. З іншого боку, створення інтерактивності в додатку передбачає більш глибокий розумовий процес і лише частку рутинного друку. Ми розберемося, чому так виходить.

\n

Щоб побудувати статичну версію додатка, яка буде показувати модель даних, нам потрібно створити компоненти, які використовують інші компоненти і передають дані через пропси. Пропси — це спосіб передачі даних від батьків до дочірних елементів. Якщо ви знайомі з поняттям стану, то для статичної версії це якраз те, що вам використовувати не потрібно. Стан передбачає собою дані, які змінюються з часом – інтерактивність. Так як ми працюємо над статичною версією додатка, то нам це не потрібно.

\n

Написання коду можна почати як зверху вниз (з великого FilterableProductTable), так і знизу до верху (з маленького ProductRow). Простіші додатки зручніше починати з компонентів, що знаходяться вище за ієрархією. У більш складних додатках зручніше в першу чергу створювати і тестувати підкомпоненти.

\n

Наприкінці цього кроку ви матимете бібліотеку компонентів, які можуть бути використані повторно. Так як це статична версія, то компоненти матимуть тільки методи render(). Компонент вище за ієрархією (FilterableProductTable) буде передавати модель даних через пропси. Якщо ви внесете зміни в базову модель даних і знову викличите ReactDOM.render(), то побачите зміни в інтерфейсі. Немає нічого складного у відстеженні змін та оновленні інтерфейсу. Завдяки односторонньому потоку даних (або односторонній прив’язці) код працює швидко, але залишається зрозумілим.

\n

Якщо у вас залишилися запитання щодо виконання цього кроку, зверніться до документації React.

\n

Невеликий відступ: як пропси відрізняються від стану

\n

Існує два типи “моделі” даних у React: пропси та стан. Важливо, щоб ви розуміли різницю між ними, в іншому випадку зверніться до офіційної документації React. Також див. FAQ: У чому полягає різниця між state та props?

\n

Крок 3: Визначимо мінімальне (але повноцінне) відображення стану інтерфейсу

\n

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

\n

Щоб правильно побудувати додаток, спочатку потрібно подумати про мінімальний набір змінних станів, які потрібні вашому додатку. Головне тут дотримуватися принципу розробки DRY: Don’t Repeat Yourself (укр. не повторюй себе). Визначте мінімальну кількість необхідного стану, який потрібен вашому додатку, все інше обчислюйте за необхідності. Наприклад, якщо ви створюєте список справ, тримайте масив пунктів списку під рукою – але не варто зберігати окремий стан для кількості справ у списку. Якщо треба відобразити кількість елементів, просто використовуйте довжину існуючого масиву.

\n

Давайте перелічимо всі дані у нашому додатку. Ми маємо:

\n\n

Давайте розглянемо кожну частину даних і визначимо, яка з них є станом. Задайте собі наступні три питання:

\n
    \n
  1. Передається вона від батька через пропси? Якщо так, тоді, напевно, це не стан.
    2. \n
  2. Залишається вона незмінною з часом? Якщо так, тоді, напевно, це не стан.
    3. \n
  3. Чи можете ви обчислити її на основі будь-якої іншої частини стану або пропсів у своєму компоненті? Якщо так, тоді, напевно, це не стан.
    4. \n
\n

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

\n

У підсумку, наш стан виглядатиме наступним чином:

\n\n

Крок 4: Визначимо, де має перебувати наш стан

\n

Приклад коду Філософія React: Крок 4 на CodePen.

\n

Отже, ми визначили мінімальний набір станів додатку. Далі нам потрібно з’ясувати, який з компонентів володіє станом або змінює його.

\n

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

\n

Для кожної частини стану в додатку:

\n\n

Давайте застосуємо цю стратегію на прикладі нашого додатку:

\n\n

Отже, ми вирішили розташувати наш стан у FilterableProductTable. Перше, що потрібно зробити - додати властивість this.state = {filterText: '', inStockOnly: false} до конструктора FilterableProductTable, щоб відобразити початковий стан додатку. Після цього, передайте filterText та inStockOnly до ProductTable і SearchBar через пропси. Нарешті, використайте пропси для фільтрації рядків у ProductTable і визначення значень полів форми SearchBar.

\n

Ви помітите зміни у поведінці вашого додатку: задайте значення "ball" для filterText та оновіть сторінку. Ви побачите відповідні зміни в таблиці даних.

\n

Крок 5: Додамо зворотний потік даних

\n

Приклад коду Філософія React: Крок 5 на CodePen.

\n

Поки що наш додаток рендериться в залежності від пропсів і стану, що передаються вниз по ієрархії. Тепер ми забезпечимо потік даних у зворотний бік: наше завдання зробити так, щоб компоненти форми у самому низу ієрархії оновлювали стан у FilterableProductTable.

\n

Потік даних у React - односторонній. Це допомагає зрозуміти, як працює додаток, але нам потрібно трохи більше коду, ніж в традиційній двосторонній прив’язці даних.

\n

Якщо ви спробуєте ввести текст у поле пошуку або встановити прапорець в даній версії прикладу, то побачите, що React ігнорує будь-яке введення. Це навмисне, так як раніше ми прирівняли значення пропа value в input до state в FilterableProductTable.

\n

Давайте поміркуємо, як ми хочемо змінити поведінку. Нам потрібно, щоб при змінах пошукової форми змінювався стан введення. Так як компоненти повинні оновлювати тільки той стан, що належить їм, FilterableProductTable передасть функцію зворотнього виклику у SearchBar. У свою чергу, SearchBar викликатиме цю функцію зворотнього виклику кожен раз, коли треба оновити стан. Щоб отримувати повідомлення про зміни елементів форми, ми можемо використовувати подію onChange. Функції зворотнього виклику, передані з FilterableProductTable викличуть setState(), і додаток оновиться.

\n

Бодай звучить складно, але це займає всього кілька рядків коду. А головне, потік даних через додаток залишається прямим і зрозумілим.

\n

От і все

\n

Сподіваємося, що цей приклад допоможе вам отримати краще уявлення про те, як підійти до створення компонентів і додатків у React. Хоча цей процес і використовує трохи більше коду, пам’ятайте: код читають частіше, ніж пишуть. А такий модульний та прямий код, як в нашому додатку, читається не так складно. Коли ви почнете створювати великі бібліотеки компонентів, ви зможете по-справжньому оцінити прямолінійність і зв’язаність React, а повторно використовувані компоненти зроблять ваш код набагато коротшим. :)

","frontmatter":{"title":"Філософія React","next":null,"prev":"composition-vs-inheritance.html"},"fields":{"path":"content/docs/thinking-in-react.md","slug":"docs/thinking-in-react.html"}}},"pageContext":{"slug":"docs/thinking-in-react.html"}},"staticQueryHashes":[]}