Этот пост представляет собой краткое введение в способ поддержания вашего кода Gutenberg в соответствии с текущими стандартами с помощью хуков React. Мы увидим, насколько это выгодно, почему мы должны это делать и как.
А, крючки?
Я предполагаю, что у вас уже есть некоторый опыт работы с немного более сложными блоками или плагинами Gutenberg, которые запрашивают сообщения или извлекают и обновляют метаданные сообщений. И, таким образом, работал с [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
Преобразование withSelectв useSelectнастолько просто, насколько это возможно. Первый шаг заключается в том, что мы можем определить переменную somePostsвнутри нашего компонента, а не снаружи с помощью exportинструкции. Второй шаг — перенести всю функцию, которая у нас была, withSelectв useSelect. Вот и все.
Приведенный выше код дает тот же результат, что и код с withSelect. Разница в том, что код стал намного понятнее! Теперь мы можем очень легко увидеть, что переменная somePostsхранит результат почтового запроса прямо внутри нашего компонента.
Важное примечание: useSelectпринимает второй параметр; массив зависимостей. Зависимости — это переменные, которые гарантируют, что мы запускаемся только тогда, useSelectкогда одна из зависимостей (значений переменных) изменилась. Этот момент более важен useDispatch, чем здесь, поэтому я объясню этот момент далее в useDispatchразделе ниже.
РеализацияuseDispatch
Теперь давайте посмотрим на withDispatchи соответствующий ему хук useDispatch. Они используются для отправки реквизита в реестры. Например, сказать Гутенбергу обновить метаданные сообщения через ‘ core/editor‘.
Опять же, в демонстрационных целях мои примеры кода не являются полными функциональными фрагментами кода — они иллюстрируют только части, относящиеся к этим шаблонам. В этом примере я предполагаю, что у меня есть текстовое поле, показывающее метаданные сообщения, и я хочу обновить метазначение сообщения при изменении.
Старый способ использованияwithDispatch
Поскольку withDispatchэто компонент более высокого порядка, мне нужно было бы обернуть свой компонент внутри этого. Обычно это делается в exportзаявлении. Чтобы текстовое поле для нашей мета работало, мы
Например:
В строке #20-26мы оборачиваем компонент внутрь withDispatch, в котором мы возвращаем функцию «setPostMeta», которая отправляет метаданные сообщения (для его обновления). В строке #6мы деструктурируем свойство, чтобы мы могли использовать его в onChangeсобытии текстового поля в строке #13. (Обратите внимание, что приведенный выше пример не будет работать, потому что мы установили значение текстового поля в пустую строку. Это просто для демонстрации того, как мы будем использовать диспетчеризацию).
Мы снова видим, что код не так прост для понимания. Вы должны были бы знать, как искать обертку, чтобы выяснить, что такое реквизит «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мы обновляем мета-значение записи. Но для того, чтобы текстовое поле работало правильно (а также отображало текущее значение), нам также необходимо получить мета-значение записи.
Если вам нужно использовать несколько компонентов более высокого порядка, обернутых вокруг вашего компонента, вы, скорее всего, воспользуетесь еще одной функцией Гутенберга; [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строке #12мы добавляем постмета, которую мы обновляем как зависимость (postMeta.example_post_meta). Если бы вам нужно было обновлять несколько мета-переменных постов в этом компоненте, вам нужно было бы добавить каждую в качестве зависимости, чтобы гарантировать выполнение отправки (фактически сохранение мета-переменных поста) при изменении значения одной из них.
Я надеюсь, что это было информативно и полезно для кого-то там. Я еще немного не знаком с хуками, но, увидев преимущества их использования, я не поверну назад!