Ця публікація є коротким ознайомленням зі способом підтримувати ваш код Гутенберга відповідно до поточних стандартів за допомогою хуків React. Ми побачимо, наскільки це вигідно, чому ми повинні це робити та як.
Га, гачки?
Я припускаю, що у вас уже є певний досвід роботи з дещо складнішими блоками Гутенберга або плагінами, які надсилають запити до публікацій або завантажують і оновлюють мета публікацій. І тому працював з [withSelect](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#withSelect)та/або [withDispatch](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#withDispatch). Це компоненти вищого порядку в WordPress, які дозволяють вам отримати доступ до магазинів WordPress, щоб отримати або надіслати інформацію, яка трохи виходить за межі «звичайного» блокування або редагування публікації. Можливо, ви також були змушені використовувати composeдля об’єднання своїх компонент із кількома компонентами вищого порядку. Якщо у вашому коді використовуються ці шаблони, не хвилюйтеся – вони чудово працюють і працюватимуть надалі! Але з розвитком технологій ми можемо робити краще.
На початку 2019 року React запустив хуки (версія 16.8), які дозволяють використовувати стан без використання класу та вдосконалювати інші функції, що дає більш розбірливий і багаторазовий код. Наприклад, усунення необхідності загортати ваш код у компоненти вищого порядку для доступу до реєстрів. А влітку 2019 року WordPress пішов за ним, запустивши спеціальні хуки: [useDispatch](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#useDispatch)і [useSelect](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#useSelect).
Переваг гачків багато. Найпоширенішим прикладом є можливість використання стану компонента без необхідності писати клас Javascript (useState). Але, на мій погляд, найбільшою перевагою є можливість повторного використання. Усунувши необхідність використовувати такі шаблони, як рендеринг-реквізити та компоненти вищого порядку, компоненти можна записати в набагато більш незалежні частини. Ще одна перевага хуків полягає в тому, що вони полегшують читання та розуміння вашого коду!
Давайте відразу перейдемо до деяких прикладів і подивимося, як реалізувати useSelectхуки useDispatchв нашому коді!
РеалізаціяuseSelect
Почнемо з withSelectвідповідного гачка useSelect. Вони використовуються для отримання реквізитів стану від зареєстрованих селекторів. Типовими прикладами є доступ до селекторів «core» або «core/editor» для виконання запитів до дописів (getEntityRecords), доступу до мета допису (getEditedPostAttribute) або просто отримання поточного типу допису чи іншої інформації.
Для демонстрації я почну з простого прикладу. Припустімо, у мене є блочний компонент, у якому десь є селектор публікацій. Щоб заповнити варіанти публікацій, мені потрібно отримати доступ до реєстру «core» і виконати GetEntityRecords()виклик.
Старий спосіб використанняwithSelect
Якщо я хочу запитувати публікації в блоці, мені потрібно буде обернути свій компонент у withSelect. Зазвичай це робиться в exportзаяві.
Зауважте, що цей приклад коду не є повним як справжній функціональний блок або плагін JS, його вилучено, щоб просто показати основні концепції withSelect. Якщо ви шукаєте практичні приклади коду, у мене є інші статті, які висвітлюють це: наприклад , як реалізувати блоки з вибором публікації або як додати мета публікації до інспектора. Вони записуються через withSelectі withDispatch, так само, а потім поверніться сюди, щоб дізнатися, як перетворити їх на гаки.
Як ви бачите, у рядку #12-16я обертаю свій компонент за допомогою withSelect. Усередині функції withSelect я можу отримати доступ до потрібного мені магазину, і я повертаю запит на публікацію в проп «somePosts«. Потім цей проп буде доступний у моєму AWP_Example_Pluginкомпоненті (як ви бачите, я деструктурую somePostsз пропсів у рядку #3).
Як згадувалося раніше, цей метод працює чудово – і буде працювати так і надалі. Але в цьому є кілька недоліків. По-перше, це не дуже легко зрозуміти. Звичайно, це був дуже простий приклад. З першого погляду на сам компонент ви не впевнені, звідки somePostsвзявся проп або що це таке. Ви повинні знати, як шукати оператор експорту та перевіряти, чи є якісь обгортки. Це також відчувається трохи роз’єднаним. Ви виконуєте досить велику частину важливої роботи за межами вашого компонента, для чогось, що вам дійсно потрібно, щоб воно було доступне у вашому компоненті.
Зробимо це краще за допомогою гачків.
Перетворення вuseSelect
Перетворити a withSelectна useSelectмаксимально просто. Перший крок полягає в тому, що ми можемо визначити змінну somePostsвсередині нашого компонента, а не зовні exportоператором. Другим кроком є перенесення всієї функції, яку ми мали, withSelectу useSelect. І це все.
Наведений вище код забезпечує той самий результат, що й код із withSelect. Різниця в тому, що код тепер набагато зрозуміліший! Тепер ми можемо дуже легко побачити, що змінна somePostsзберігає результат пост-запиту прямо в нашому компоненті.
Важлива примітка: useSelectприймає другий параметр; масив залежностей. Залежності — це змінні, які гарантують, що ми запускаємо лише тоді, useSelectколи одна із залежностей (значення змінної) змінюється. Цей біт важливіший, useDispatchніж тут, тому я поясню його далі в useDispatchрозділі нижче.
РеалізаціяuseDispatch
Тепер давайте подивимося на withDispatchвідповідний гачок useDispatch. Вони використовуються для надсилання реквізитів до реєстрів. Наприклад, сказати Гутенбергу оновити мета допису через «core/editor».
Знову ж таки, з метою демонстрації мої приклади коду не є повними функціональними фрагментами коду – вони ілюструють лише частини, що стосуються цих шаблонів. У цьому прикладі я припускаю, що у мене є текстове поле, яке показує мета допису, і я хочу оновити мета значення допису після зміни.
Старий спосіб використанняwithDispatch
Оскільки withDispatchце компонент вищого порядку, мені потрібно було б загорнути свій компонент у це. Зазвичай це робиться в exportзаяві. Щоб текстове поле для нашого мета працювало, ми
Наприклад:
У рядку #20-26ми загортаємо компонент усередину withDispatch, у якому ми повертаємо функцію «setPostMeta», яка відправляє post meta (для його оновлення). У рядку #6ми деструктуруємо проп, щоб ми могли використовувати його в onChangeподії текстового поля в рядку #13. (Будь ласка, зауважте, що наведений вище приклад не буде функціональним, оскільки ми встановили значення текстового поля як порожній рядок. Це лише для того, щоб продемонструвати, як ми будемо використовувати dispatch).
Знову ми бачимо, що код не такий простий для розуміння. Ви повинні знати, як шукати обгортку, щоб з’ясувати, що таке проп «setPostMeta» або звідки походить. Давайте зробимо це краще за допомогою гачків!
Перетворення вuseDispatch
Змінити withDispatchна useDispatchне так просто, як перетворити withSelectна useSelect. Хоча це все ще досить легко. Слід пам’ятати про дві речі. Один з них useDispatchприймає назву магазину як перший параметр. Тоді ми отримаємо доступ до магазину та викличемо його доступні функції, коли ми його використаємо (наприклад, у onChangeподії текстового поля). По-друге, масив залежностей для useDispatchдругого параметра важливіший, ніж для useSelect. Ви можете ризикувати тим, що ваш код опиниться у вічному циклі, якщо ви не керуєте залежностями належним чином. Лише після зміни змінних залежностей сценарій буде повторно запущено useDispatch.
Наприклад:
У рядку #8ми деструктуруємо те, що нам потрібно з магазину ‘ core/editor‘. Нас цікавить лише editPostфункція, за допомогою якої ми можемо оновлювати мета публікації. Як другий параметр useDispatchми надаємо залежності. Що стосується прикладу оновлення мета допису, використання значення мета допису (за допомогою useSelect) було б ідеальним як залежність. У цьому прикладі я просто встановив його як фіктивну змінну. Подивіться нижче на більш повний і реалістичний приклад. А потім у рядку події #16текстового поля ми викликаємо оновлення мета. Зверніть увагу на різницю в цьому рядку з використанням вище! Оскільки ми використовуємо напряму, а не повертаємо функцію, щоб оновити мета публікації для нас (), нам потрібно надати об’єкт зonChange``editPost``withDispatch``editPost``setPostMeta``metaяк ключ, а потім об’єкт із мета публікації, який ми хочемо оновити. Ми як би розділили withDispatchкод на частини.
Тим не менш, використання useDispatchробить код більш читабельним і зрозумілим. Більше немає коду, доданого поза нашим компонентом, який нам потрібно використовувати всередині.
Більш повний приклад і усуває потребуcompose
Швидше за все, якщо ви використовуєте withDispatch, вам також знадобиться withSelectцей компонент. У наведених вище прикладах для перетворення у useDispatchми оновлюємо мета-значення публікації. Але для того, щоб текстове поле працювало належним чином (а також відображало поточне значення), нам також потрібно буде отримати мета-значення post.
Якщо вам потрібно використовувати кілька компонентів вищого порядку, обернутих навколо вашого компонента, ви, швидше за все, використаєте ще одну функцію Гутенберга; [compose](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-compose/). Це зручна функція для об’єднання кількох компонентів вищого порядку в один компонент вищого порядку, навколо якого можна обернути свій компонент.
Давайте розглянемо більш повний приклад компонента, який отримує мета-значення публікації в текстовому полі та оновлюється, коли його значення змінюється. Ми починаємо з того, як нам потрібно було б це зробити, використовуючи withSelectand withDispatch(а отже, також compose).
Використовуючи withSelect, withDispatchіcompose
У рядку #21-34ми складаємо withSelectі withDispatchобертаємо їх навколо нашого компонента. postMetafrom withSelectі setPostMetafrom withDispatchтепер доступні в нашому компоненті як реквізити. Ми деструктуруємо їх у рядку #7та використовуємо в #13і #14.
Як бачите, необхідний код поза нашим компонентом довший за сам компонент. Я не знаю, як ви, але для мене це здається трохи роз’єднаним. Розробники можуть почати читати цей код зверху, не бачачи нижньої частини, і почати дивуватися, звідки postMetaі setPostMetaзвідки – вони, здається, чарівно доступні. Для мене це дуже неінтуїтивно.
Давайте подивимося, як ми перетворимо наведений вище приклад у хуки.
Використовуючи useSelectіuseDispatch
Як це красиво і розбірливо?! Ми можемо відразу побачити в нашому компоненті postMeta, звідки отримано та як ми отримуємо доступ до editPost. Наш компонент також стало набагато легше повторно використовувати.
Зауважте, що в useDispatchрядку at #12ми додаємо postmeta, який оновлюємо як залежність (postMeta.example_post_meta). Якщо ви повинні підтримувати кілька мета-змінних публікації в актуальному стані в цьому компоненті, вам доведеться додати кожну як залежність, щоб забезпечити виконання диспетчеризації (фактично збереження мета публікації), коли значення однієї з них змінюється.
Я сподіваюся, що це було інформативно та корисно для когось там. Я все ще трохи не знайомий з хуками, але, побачивши переваги їх використання, я не повертаюся назад!