{"componentChunkName":"component---src-templates-docs-js","path":"/docs/higher-order-components.html","result":{"data":{"markdownRemark":{"html":"

Компонент вищого порядку (КВП) — це просунута технологія для повторного використання логіки компоненту. Сам по собі КВП не є частиною React API, але через композиційну природу компонентів він є розповсюдженним патерном проектування.

\n

Тобто, компонент вищого порядку — це функція, яка приймає компонент та повертає новий компонент.

\n
const EnhancedComponent = higherOrderComponent(WrappedComponent);
\n

Якщо звичайний компонент трасформує пропси у UI, то компонент вищого порядку трасформує один компонент у інший.

\n

КВП поширені у таких сторонніх бібліотеках, як connect у Redux, або createFragmentContainer у Relay.

\n

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

\n

Використання КВП для перехресної функціональності

\n
\n

Примітка

\n

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

\n
\n

Зазвичай компоненти є основною одиницею повторного використання коду у React. Однак ви побачите, що вони не є відповідним рішенням низки проблем.

\n

Наприклад, ви маєте компонент CommentList, який підписується на зовнішнє джерело даних, щоб відобразити список коментарів:

\n
class CommentList extends React.Component {\n  constructor(props) {\n    super(props);\n    this.handleChange = this.handleChange.bind(this);\n    this.state = {\n      // \"DataSource\" є деяким глобальним джерелом даних\n      comments: DataSource.getComments()\n    };\n  }\n\n  componentDidMount() {\n    // Підписка на зміни\n    DataSource.addChangeListener(this.handleChange);\n  }\n\n  componentWillUnmount() {\n    // Відписка\n    DataSource.removeChangeListener(this.handleChange);\n  }\n\n  handleChange() {\n    // Оновлення стану компонента, коли у джерелі даних відбулись зміни\n    this.setState({\n      comments: DataSource.getComments()\n    });\n  }\n\n  render() {\n    return (\n      <div>\n        {this.state.comments.map((comment) => (\n          <Comment comment={comment} key={comment.id} />\n        ))}\n      </div>\n    );\n  }\n}
\n

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

\n
class BlogPost extends React.Component {\n  constructor(props) {\n    super(props);\n    this.handleChange = this.handleChange.bind(this);\n    this.state = {\n      blogPost: DataSource.getBlogPost(props.id)\n    };\n  }\n\n  componentDidMount() {\n    DataSource.addChangeListener(this.handleChange);\n  }\n\n  componentWillUnmount() {\n    DataSource.removeChangeListener(this.handleChange);\n  }\n\n  handleChange() {\n    this.setState({\n      blogPost: DataSource.getBlogPost(this.props.id)\n    });\n  }\n\n  render() {\n    return <TextBlock text={this.state.blogPost} />;\n  }\n}
\n

CommentList та BlogPost не є ідентичними — вони викликають різні методи DataSource та відображають різний інтерфейс. Однак значна частина їх реалізації збігається:

\n\n

Чи можете ви уявити, що у великому додатку ця схема підписки буде виникати знову і знову? Нам потрібна абстракція, яка дозволить описати цю логіку в одному місці та звертатися до неї у багатьох компонентах. Саме тут доречно використати компонент вищого порядку.

\n

Ми можемо написати функцію, що створює компоненти, як CommentList чи BlogPost, які підписуються на DataSource. В якості одного з аргументів функція буде приймати дочірній компонент, який отримає дані з підписки у якості власного prop. Назвемо цю функцію withSubscription:

\n
const CommentListWithSubscription = withSubscription(\n  CommentList,\n  (DataSource) => DataSource.getComments()\n);\n\nconst BlogPostWithSubscription = withSubscription(\n  BlogPost,\n  (DataSource, props) => DataSource.getBlogPost(props.id)\n);
\n

Перший параметр це обгорнутий компонент, а другий — функція, що отримує DataSource та пропси, і вилучає потрібні нам дані.

\n

Коли CommentListWithSubscription і BlogPostWithSubscription відображаються, у CommentList і BlogPost буде переданий параметр data у якості пропа з актуальними даними, отриманими від DataSource:

\n
// Ця функція отримує компонент ...\nfunction withSubscription(WrappedComponent, selectData) {\n  // ... та повертає інший компонент ...\n  return class extends React.Component {\n    constructor(props) {\n      super(props);\n      this.handleChange = this.handleChange.bind(this);\n      this.state = {\n        data: selectData(DataSource, props)\n      };\n    }\n\n    componentDidMount() {\n      // ... тут відбувається підписка ...\n      DataSource.addChangeListener(this.handleChange);\n    }\n\n    componentWillUnmount() {\n      DataSource.removeChangeListener(this.handleChange);\n    }\n\n    handleChange() {\n      this.setState({\n        data: selectData(DataSource, this.props)\n      });\n    }\n\n    render() {\n      // ... та відображується обгорнутий компонент зі свіжими даними!\n      // Зверніть увагу, що ми передаємо усі пропси\n      return <WrappedComponent data={this.state.data} {...this.props} />;\n    }\n  };\n}
\n

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

\n

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

\n

Оскільки withSubscription це звичайна функція, ви можете додати стільки аргументів, скільки забажаєте. Наприклад, ви можете зробити ім’я параметру data конфігуруємим, щоб додатково ізолювати КВП від обгорнутого компонента. Або ви можете прийняти аргумент, що налаштує shouldComponentUpdate чи джерело даних. Це все можливо тому, що КВП має повний контроль над тим, як компонент буде визначений.

\n

Як і між звичайними компонентами, взаємодія між withSubscription і обгорнутим компонентом здійснюється лише за допомогою пропсів. Це дозволяє легко замінити один КВП на інший, якщо вони забезпечують однакові пропси для обгорнутого компонента. Це може бути корисним, наприклад, якщо ви зміните бібліотеки для отримання даних.

\n

Не змінюйте обгорнутий компонент. Використовуйте композицію.

\n

Втримайтеся від бажання змінити прототип компонента (чи мутувати його) всередині КВП.

\n
function logProps(InputComponent) {\n  InputComponent.prototype.componentDidUpdate = function(prevProps) {\n    console.log('Current props: ', this.props);\n    console.log('Previous props: ', prevProps);\n  };\n  // Якщо ми повертаємо лише той самий отриманий компонент - це натяк, що він\n  // був мутований\n  return InputComponent;\n}\n\n// EnhancedComponent буде щоразу друкувати в консоль, коли отримає новий проп\nconst EnhancedComponent = logProps(InputComponent);
\n

З цим пов’язано кілька проблем. Одна полягає у тому, що InputComponent не може бути використаний знову окремо від EnhancedComponent. Більш важливо, якщо ви застосуєте інший КВП до EnhancedComponent, який, наприклад, у свою чергу також мутує componentDidUpdate, функціональність першого КВП буде перезаписана! Цей КВП також не буде працювати з функціональними компонентами, які не мають методів життєвого циклу.

\n

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

\n

Замість мутації, КВП мають реалізовувати композицію, обгортаючи переданий компонент у контейнер:

\n
function logProps(WrappedComponent) {\n  return class extends React.Component {\n    componentDidUpdate(prevProps) {\n      console.log('Current props: ', this.props);\n      console.log('Previous props: ', prevProps);\n    }\n    render() {\n      // Обгорайте переданий компонент у контейнер, не мутуючи його!\n      return <WrappedComponent {...this.props} />;\n    }\n  }\n}
\n

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

\n

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

\n

Конвенція: передавайте сторонні пропси обгорненому компоненту

\n

КВП додає компоненту функціональність. Він не повинен змінювати його початкове призначення. Очікується, що повернений КВП компонент буде мати інтерфейс аналогічний обгорнутому.

\n

КВП повинні передавати ті пропси, що не пов’язані з їх функціональністю, у незмінному стані. Більшість компонентів вищого порядку мають рендер-метод, схожий на цей:

\n
render() {\n  // Відфільтруйте зайві пропси, що характерні для КВП та не мають\n  // потрапити до компонента\n  const { extraProp, ...passThroughProps } = this.props;\n\n  // Створіть ін’єкцію для обгорнутого компонента.\n  // Зазвичай це значення стану або методи екземпляра\n  const injectedProp = someStateOrInstanceMethod;\n\n  // Передайте пропси до обгорнутого компонента\n  return (\n    <WrappedComponent\n      injectedProp={injectedProp}\n      {...passThroughProps}\n    />\n  );\n}
\n

Ця угода допомагає забезпечити максимальну гнучкість та можливість повторного використання КВП.

\n

Конвенція: максимізація композиційності

\n

Не всі КВП виглядають однаково. Іноді вони приймають лише один аргумент — компонент, що буде обгорнений:

\n
const NavbarWithRouter = withRouter(Navbar);
\n

Зазвичай КВП приймає додаткові аргументи. У цьому прикладі з Relay об’єкт конфігурації використовується для визначення залежностей даних компонента:

\n
const CommentWithRelay = Relay.createContainer(Comment, config);
\n

Найбільш поширений спосіб виклику КВП виглядає так:

\n
// Функція `connect` у React та Redux\nconst ConnectedComment = connect(commentSelector, commentActions)(CommentList);
\n

Що?! Якщо розділити це на частини, то легше буде побачити, що відбувається.

\n
// `connect` це функція, що повертає іншу функцію\nconst enhance = connect(commentListSelector, commentListActions);\n// Повернена функція є КВП, який поверне компонент підключенний до Redux стору\nconst ConnectedComment = enhance(CommentList);
\n

Іншими словами, connect - це функція вищого порядку, яка повертає компонент вищого порядку!

\n

Ця форма може здатися заплутаною або непотрібною, але вона має корисну властивість. Одноаргументні КВП, як і той, який повертається функцією connect, мають сигнатуру Component => Component. Функції, з однаковим типом результату та єдиного аргументу, легко поєднуються у композицію.

\n
// Замість цього ...\nconst EnhancedComponent = withRouter(connect(commentSelector)(WrappedComponent))\n\n// ... ви можете використати композиційну функцію\n// compose(f, g, h) теж саме, що (...args) => f(g(h(...args)))\nconst enhance = compose(\n  // Обидва параметра є КВП та приймають лише один аргумент\n  withRouter,\n  connect(commentSelector)\n)\nconst EnhancedComponent = enhance(WrappedComponent)
\n

(Саме ця властивість дозволяє використовувати connect та інші поширюючи функціональність КВП у якості експериментальних JavaScript декораторів.)

\n

Ви можете знайти допоміжну функцію compose у багатьох сторонніх бібліотеках, включаючи lodash (під назвою lodash.flowRight), Redux та Ramda.

\n

Конвенція: повертайте ім’я обгорнутого компонента для легшого дебагу

\n

Створений КВП компонент-контейнер відображається у React Developer Tools, як і будь-який інший компонент. Для того, щоб полегшити процес налагодження, визначте відображуване ім’я, яке повідомляє, що це результат КВП.

\n

Найпоширеніший прийом - обгортати відображуване ім’я загорнутого компонента. Отже, якщо ваш компонент вищого порядку названий withSubscription, а відображене ім’я загорнутого компонента - CommentList, визначте відображуване ім’я як WithSubscription(CommentList):

\n
function withSubscription(WrappedComponent) {\n  class WithSubscription extends React.Component {/* ... */}\n  WithSubscription.displayName = `WithSubscription(${getDisplayName(WrappedComponent)})`;\n  return WithSubscription;\n}\n\nfunction getDisplayName(WrappedComponent) {\n  return WrappedComponent.displayName || WrappedComponent.name || 'Component';\n}
\n

Застереження

\n

Якщо ви лише починаєте використовувати React, то варто зазначити, що компоненти вищого порядку можуть стати причиною неочевидних проблем.

\n

Не використовуйте КВП у середині рендер-методів

\n

Алгоритм порівняння React, що відомий як reconciliation (або узгодження), використовує перевірку на тотожність компонента, щоб визначити, чи слід оновити існуюче піддерево компонентів або слід знищити його та змонтувати нове. Якщо компонент, що був повернений рендер-методом, ідентичний (===) попередньому результату, React рекурсивно оновлює піддерева, порівнюючи його з новим. Якщо вони не тотожні, то попереднє піддерево буде повністю розмонтовано.

\n

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

\n
render() {\n  // Під час кожного виклику рендер-методу створюється новий екземпляр EnhancedComponent\n  // EnhancedComponent1 !== EnhancedComponent2\n  const EnhancedComponent = enhance(MyComponent);\n  // Це призводить до того, що все піддерево щоразу монтується/демонтується!\n  return <EnhancedComponent />;\n}
\n

Проблема тут полягає не лише в продуктивності — повторне перерахування компонента втрачає стан цього компонента та всіх його потомків.

\n

Замість цього застосовуйте КВП за межами визначення компонента, щоб отриманий компонент був створений лише один раз. У цьому випадку React буде порівнювати один і той же компонент при повторному виклику рендер-метода.

\n

У тих рідкісних випадках, коли вам потрібно динамічно застосовувати КВП, ви можете зробити це в методах життєвого циклу компонента або в його конструкторі.

\n

Копіюйте статичні методи

\n

Іноді корисно визначити статичні методи компонента. Наприклад, статичний метод getFragment у бібліотеці Relay дає можливість визначити композицію з фрагментів даних GraphQL.

\n

Якщо ви застосовуєте КВП, то обгортаєте оригінальний компонент контейнером. Це означає, що новий компонент не матиме статичних методів оригінального компонента.

\n
// Визначте статичний метод\nWrappedComponent.staticMethod = function() {/*...*/}\n// Тепер застосуйте КВП\nconst EnhancedComponent = enhance(WrappedComponent);\n\n// EnhancedComponent не має статичного методу\ntypeof EnhancedComponent.staticMethod === 'undefined' // true
\n

Вам необхідно скопіювати методи до того, як повернути новий компонент, щоб вирішити цю проблему:

\n
function enhance(WrappedComponent) {\n  class Enhance extends React.Component {/*...*/}\n  // Потрібно точно знати, який метод(и) скопіювати :(\n  Enhance.staticMethod = WrappedComponent.staticMethod;\n  return Enhance;\n}
\n

На жаль для цього необхідно точно знати, які методи потрібно скопіювати. Для автоматичного копіювання всіх статичних методів ви можете використати hoist-non-react-statics:

\n
import hoistNonReactStatic from 'hoist-non-react-statics';\nfunction enhance(WrappedComponent) {\n  class Enhance extends React.Component {/*...*/}\n  hoistNonReactStatic(Enhance, WrappedComponent);\n  return Enhance;\n}
\n

Ще одне можливе рішення — експортувати статичні методи окремо від компонента.

\n
// Замість цього ...\nMyComponent.someFunction = someFunction;\nexport default MyComponent;\n\n// ... експортуйте метод окремо ...\nexport { someFunction };\n\n// ... в модулі-споживачі ми можемо імпортувати обидва\nimport MyComponent, { someFunction } from './MyComponent.js';
\n

Рефи не передаються

\n

Попри те, що попередня конвенція наполягає на тому, щоб передавати всі пропси до обгорнутого компонента, це не стосується рефів. Річ у тому, що ref насправді не є пропом, як, наприклад, key, а тому інакше оброблюється React. Якщо ви додасте ref до компонента, що був повернений КВП, він буде вказувати на екземпляр зовнішнього контейнера, а не на обгорнутий компонент.

\n

Розв’язання цієї проблеми є використання API React.forwardRef (введений з React 16.3). Дізнайтеся більше про це в розділі Переадресація рефів.

","frontmatter":{"title":"Компоненти вищого порядку","next":null,"prev":null},"fields":{"path":"content/docs/higher-order-components.md","slug":"docs/higher-order-components.html"}}},"pageContext":{"slug":"docs/higher-order-components.html"}},"staticQueryHashes":[]}