Представляем мост React-Gutenberg: поддержка безголовых блоков для еще большего удобства редактирования

Вы в восторге от возможностей, которые предлагает безголовый WordPress, но маркетинговая команда вашего клиента привязана к редактору WYSIWYG Gutenberg.

Посмотрите, как новая поддержка блоков Gutenberg от Faust для проектов без головы объединяет эти две возможности, чтобы модернизировать вашу разработку и расширить возможности ваших маркетологов.

Динамики:

• Тереза ​​Гоббл, инженер-программист WP Engine
• Блейк Уилсон, старший инженер-программист в WP Engine

Слайды сессии:

Стенограмма:

ТЕРЕЗА ГОББЛ: Привет, ребята. Меня зовут Тереза ​​Гоббл. Я инженер-программист с WP Engine, работаю в команде Faust.

И я здесь с Блейком Уилсоном, старшим инженером-программистом, чтобы познакомить вас с React-Gutenberg Bridge — поддержкой безголовых блоков для еще большего удобства редактирования. Добро пожаловать. Давайте начнем.

Итак, сегодня нам есть что рассказать. Прежде всего, я расскажу о нескольких вещах, связанных с проблемой и решением, которое у нас есть для вас, а также о ценности React-Gutenberg Bridge. Затем мы перейдем к Блейку, который предоставит нам демонстрацию React-Gutenberg Bridge в действии. После этого мы поговорим о паре технических деталей. И мы также посетим будущую дорожную карту того, что у нас есть для этого.

Так вот проблема. Не существует упрощенного способа перевода блоков Гутенберга из WordPress в безголовый интерфейс. Существующие решения не являются масштабируемыми или интуитивными, но они не обеспечивают возможности для разработчиков, на которые могут рассчитывать безголовые разработчики.

Разделение нарушает возможность естественного использования блочного содержимого Gutenberg в редакторе. Агентствам остается только гадать, как они делают это по-своему или с нуля, практически не руководствуясь указаниями. И много вопросов без ответа остается для людей.

Что насчет стиля? Как насчет повторного использования, динамических блоков, внутренних блоков? Что ж, вот тут-то и появляется мост React-Gutenberg. Это решение состоит из двух частей: во-первых, это способ программного предоставления блоков Gutenberg, чтобы их можно было анализировать и читать на безголовом интерфейсе. Эта часть называется WPGraphQL Content Blocks.

Во-вторых, у нас есть разъем для облегчения настройки и рендеринга этих блоков в безголовом интерфейсе. И это пакет под названием Faust WP Blocks. Здесь вы увидите пошаговое руководство о том, как это работает с обоими этими частями решения.

Серверная часть вашего веб-сайта на основе React имеет свои блоки Gutenberg, которые предоставляются плагином WPGraphQL Content Blocks. Он предоставляет содержимое block.json для WPGraphQL. Он предоставляет его плагину под названием WPGraphQL.

Затем дело доходит до пакета коннектора, который позволяет настраивать, обнаруживать и отображать блоки. И это на самом деле будет обсуждаться намного больше, когда мы сегодня будем обсуждать технические вопросы и демонстрацию. Так какую ценность это приносит вашей команде?

Что ж, это сквозное продуманное решение, которое уменьшает сложность и двусмысленность. Это экономит время разработки, следуя определенным соглашениям. Это позволяет использовать блоки и шаблоны блоков в комбинации. И его можно использовать снова и снова. Теперь, когда у вас есть представление о том, как работает мост React-Gutenberg, давайте отправимся к Блейку, чтобы увидеть его демонстрацию в действии.

БЛЕЙК УИЛСОН: Спасибо, Тереза. Всем привет. Я Блейк Уилсон. Я старший инженер-программист в WP Engine.

И я в команде Faust JS, создающей Faust. Сегодня у меня для вас отличная демонстрация, демонстрирующая два компонента, которые мы создали, чтобы помочь организовать мост React-Gutenberg. Итак, давайте приступим к делу.

Для начала я покажу вам, что у меня есть для моей установки. А затем мы можем перейти к фактическому коду и посмотреть, что у нас там есть. Итак, для начала у меня есть сайт WordPress, работающий на Local.

У меня установлено несколько плагинов. Итак, у меня есть плагин Faust. Это помогает облегчить предварительный просмотр и все подобные полезные вещи на вашем сайте Faust JS. У меня есть WPGraphQL, который необходим для преобразования вашего сайта WordPress в конечную точку GraphQL.

А еще у меня есть блоки контента WPGraphQL. Итак, это один из плагинов, которые мы создали, чтобы облегчить этот мост React-Gutenberg. Это решение состоит из двух основных частей.

Итак, у нас есть одна часть, которая программно предоставляет данные блока Гутенберга через WPGraphQL, а затем другая часть, чтобы использовать их на вашем внешнем интерфейсе Faust JS. Давайте начнем с рассмотрения блоков содержимого WPGraphQL и того, как это работает.

Итак, мы заглянем в нашу графическую IDE. И у меня есть этот запрос, настроенный здесь, чтобы получить данные страницы. Так что в этом случае мы просто получаем заголовок страницы.

Таким образом, блоки содержимого GraphQL предоставляют тип блоков содержимого в вашей схеме GraphQL. Итак, если мы вводим блоки контента, вы можете видеть здесь, мы получаем информацию для данной страницы и всех блоков на этой странице. Давайте перейдем и отредактируем эту страницу и добавим немного контента.

Итак, мы перейдем к странице образца. И вы можете видеть, что у нас есть чистый лист. Итак, давайте продолжим и создадим несколько блоков. Давайте создадим здесь несколько столбцов.

И мы сделаем колонку 50/50. Давайте добавим абзац на эту половину, а затем на изображение на этой половине. Итак, у меня есть изображение в моей медиатеке. Давайте продолжим и бросим это.

И вы можете видеть здесь, у нас есть две колонки. Опять же, абзац слева и изображение справа. Итак, давайте обновим это. И вернемся к WPGraphQL Content Blocks и посмотрим, что у нас получится в результате.

Как видите, теперь у нас есть два блока контента. Первый здесь — основной столбец, основной столбец. И затем мы получаем отрендеренный HTML внутри этого.

Итак, самое замечательное в WPGraphQL Content Blocks то, что мы также обрабатываем InnerBlocks. Итак, вы можете видеть здесь, если мы добавим параметр к блокам содержимого с именем flat true, вы можете видеть, что теперь мы получаем фактически все блоки, которые были даже в этих столбцах. Таким образом, мы обрабатываем это дело для вас также.

Мы получаем основной столбец, основной столбец, основной абзац, основное изображение. Так что все это делается программно для вас. И теперь вы можете использовать данные этого блока на своем внешнем интерфейсе. Итак, давайте копнем немного глубже здесь.

Допустим, нам нужны некоторые из атрибутов этого. Мы можем использовать это, используя объединение в GraphQL. Итак, мы сделаем на основном изображении, получим атрибуты. И допустим, мы хотим, например, заголовок.

Итак, вы видите, что здесь нет подписи. Вернемся к нашей тестовой странице. Мы продолжим и добавим заголовок здесь. Моя подпись. Обновите это.

И если мы обновим этот запрос, мы увидим, что теперь мы получаем мою подпись в качестве надлежащего атрибута в блоках контента WPGraphQL. Итак, это часть 1 решения. Теперь мы действительно можем получить все данные нашего блока Гутенберга и использовать их для обработки на нашем внешнем интерфейсе.

Итак, давайте перейдем к VS Code и посмотрим, как мы справимся с этой частью. Итак, это пример проекта Faust JS, который я собрал. Это очень просто. Он основан на схеме Faust Scaffold Blueprint, но с некоторыми дополнительными настройками для обработки этих блоков.

Итак, если мы посмотрим на пакет JSON, вы увидите здесь несколько зависимостей, некоторые из обычных пакетов Faust, такие как core и CLI. У нас также есть блоки Faust VP. Итак, это один из тех пакетов, который предоставляет все наши вспомогательные функции.

У нас также есть некоторые зависимости WordPress для обработки стилей и так далее. Вы также заметите, что у нас есть каталог WP Blocks. Так что здесь живут все наши блоки для нашего внешнего интерфейса, и он действует как реестр для всех блоков, которые мы используем на нашем внешнем интерфейсе.

Как видите, у нас есть файл index.js. И это, по сути, объект, который определяет все блоки, которые мы используем на нашем интерфейсе. Как видите, у нас есть основной абзац, основной столбец, основные столбцы и основное изображение.

С точки зрения настройки, есть две основные части, о которых мы будем говорить. Итак, один из них — поставщик блоков WordPress и средство просмотра блоков WordPress. Итак, давайте посмотрим, как это выглядит в действии. Давайте сначала посмотрим на поставщика блоков WordPress.

И это будет доступно в pages_app. Итак, вы можете видеть, что у нас есть этот компонент, этот поставщик, поставщик блоков WordPress. И он принимает конфигурационную поддержку, которая принимает блоки. Как видите, здесь мы импортируем блоки из WP Blocks, индекса этого каталога и передаем их в объект конфигурации.

По сути, это говорит о том, что поставщик блоков WordPress обертывает все ваше приложение и дает контекст для всех этих блоков всему вашему приложению. Теперь давайте перейдем к шаблонам WP в нашем единственном шаблоне. И вы можете видеть здесь, что мы вызываем средство просмотра блоков WordPress с поддержкой блоков контента. Итак, это данные блока, которые мы получаем от WPGraphQL.

Ладно, хватит о настройке. Давайте раскрутим это и посмотрим, как это выглядит в действии. Итак, я собираюсь запустить NPM run dev, который настроит среду разработки на локальном хосте 3000. И страница, над которой мы работали раньше, была страницей с косой чертой, поэтому я посещу страницу с образцом косой черты localhost 3000, чтобы увидеть эти Гутенберг. Блоки, которые мы установили ранее.

Как видите, у нас есть одинаковые блоки в нашем редакторе Гутенберга. Итак, давайте вернемся к нашему редактору Gutenberg для образца страницы. И вы можете видеть, что здесь у нас есть два столбца, это мой абзац, а затем наше изображение, которое соответствует тому, что у нас есть в нашем интерфейсе здесь.

Итак, вы можете сказать, что это выглядит великолепно и все такое, но можем ли мы изменить стили? Можем ли мы изменить размер шрифта? Вы точно можете.

Итак, давайте вернемся к нашему редактору Gutenberg и внесем некоторые изменения в эти блоки. Итак, давайте добавим фоновый цвет к нашему абзацу. Давайте также изменим размер на большой. Для этого изображения давайте сделаем его закругленным.

Убираем надпись. И мы обновим это. И вы можете видеть здесь, что эти стили теперь применяются. И вы можете видеть их на своем переднем конце.

Таким образом, мы действительно возвращаем опыт издателя, которого вы не ожидаете от WordPress, на ваш безголовый сайт WordPress. Еще одна замечательная вещь заключается в том, что теперь, когда вы получаете программные данные для этих блоков, вы можете сделать свой компонент React с функциями, специфичными для фреймворка, такими как следующее изображение. Теперь, вместо простого рендеринга HTML, который вы получаете от WPGraphQL, теперь мы можем использовать эти программные данные для создания компонента, который рендерит все наши изображения в Гутенберге со следующим изображением, обеспечивая нам ленивую загрузку, лучшую производительность и более оптимизированные изображения. в целом, создавая лучший пользовательский опыт для наших пользователей.

Так что это здорово. Мы видим именно то, что ожидаем в нашем редакторе Gutenberg, но допустим, мы добавляем компонент, который, возможно, еще не поддерживается или который мы не настроили на нашем сайте Faust. Итак, давайте продолжим и создадим новый компонент здесь. Мы будем использовать таблицу.

И мы сделаем две строки — строку 1, строку 2. Идите и обновите это. И если мы оглянемся назад на наш код, то увидим, что у нас есть четыре определенных блока: основной абзац, основной столбец, основные столбцы и основное изображение. У нас здесь нет основной таблицы.

Так что же произойдет, когда мы просмотрим эту страницу? Давайте взглянем. Итак, мы вернемся к образцу страницы в нашем интерфейсе Faust. И вы можете видеть, что у нас все еще есть таблица со строками 1 и 2.

Это связано с тем, что если блок еще не определен в вашем проекте Faust JS, мы сделаем разумный интеллектуальный запасной вариант для отображаемого HTML. Таким образом, вы не видите undefined, null или вообще никакого контента. По крайней мере, вы получаете исходный отрендеренный HTML.

Имея все это в виду, давайте посмотрим, что на самом деле требуется для создания блока — как он на самом деле выглядит. Итак, мы вернемся к VS Code здесь. И давайте возьмем, к примеру, основное изображение.

Как видите, это всего лишь традиционный компонент React. Мы называем это основным образом. И он принимает реквизиты, как и любой другой компонент React.

Здесь, по сути, две части блока. Итак, у нас есть настоящий компонент React, представляющий собой уровень представления. Затем мы получаем block.fragments — данные, необходимые для работы этого блока.

Итак, вы можете видеть здесь, что мы создаем фрагмент, фрагмент основного образа на основном образе. И мы получаем эти атрибуты — атрибуты, которые нам нужны для рендеринга этого блока. Итак, вы можете видеть, что мы получаем альтернативный текст, источник, заголовок, имя класса, ширину, высоту и так далее.

И затем мы можем применить эти атрибуты к нашей фактической логике React. Таким образом, все запрошенные здесь поля доступны в реквизитах. Таким образом, вы можете увидеть, как появляются props.attributes, то есть атрибуты, которые мы запросили здесь, attribute.alt, attribute.source и так далее. Так что это отличный способ разместить все требования к данным для вашего блока в одном файле.

Это гарантирует, что вы запрашиваете только те данные, которые вам нужны, и убедитесь, что ваши запросы приятны и эффективны. В этом примере проекта у нас также есть несколько вспомогательных функций. Вы можете видеть, что здесь есть пара — получить стили и получить реквизит размером с изображение.

Таким образом, они, по сути, просто берут эти стили из WordPress и объединяют их в реальный объект стилей, который может использовать React. В настоящее время стили поддерживаются для встроенных стилей. Вы также можете получить глобальные таблицы стилей, но в настоящее время мы работаем над обеспечением поддержки для theme.json.

Итак, Тереза ​​немного расскажет об этом в нашей будущей дорожной карте. Но в идеале наступит момент, когда мы сможем получить все наши стили, отступы, поля и т. д. из theme.json и применить их здесь, в безголовом интерфейсе. Имея все это в виду, давайте приступим к краткому техническому обсуждению с Терезой и мной, чтобы поговорить о том, где мы находимся сегодня с этой функцией и куда мы планируем двигаться в будущем.

ТЕРЕЗА ГОББЛ: Спасибо за демонстрацию, Блейк. Это было здорово. Давайте перейдем к некоторым техническим деталям и поговорим о том, как это работает. Итак, первое, что у меня есть для вас, — каковы требования для использования блоков контента WPGraphQL?

БЛЕЙК УИЛСОН: Да, да. Отличный вопрос, Тереза. Таким образом, единственным требованием для использования плагина является наличие установленного WPGraphQL. Очевидно, что если вы хотите, чтобы ваш сайт взаимодействовал с Faust JS, вы можете установить пакет блоков Faust JS, который поможет облегчить рендеринг и все эти полезные вещи в безголовом интерфейсе. Но для фактического предоставления данных блока все, что вам нужно, это WPGraphQL и плагин WP GraphQL Content Blocks.

ТЕРЕЗА ГОББЛ: Потрясающе. Как также собираются данные блока?

БЛЕЙК УИЛСОН: Да, так что все данные блока собираются любым блоком в WordPress, который использует функцию типа блока регистрации. Таким образом, практически любой блок, который вы используете для взаимодействия с этой функцией, будет отображаться в блоках контента. И самое замечательное в этом то, что он ретранслируется с файлом block.json и автоматически самоописывает и самодокументирует все эти поля. Итак, у вас есть документация «все в одном».

ТЕРЕЗА ГОББЛ: О, круто. Какая экономия времени. Еще одна вещь, о которой я хотел бы, чтобы вы рассказали немного больше, это то, что происходит с неподдерживаемым блоком? Что происходит, когда запрашивается неподдерживаемый блок?

БЛЕЙК УИЛСОН: Да, это еще один отличный вопрос. Здесь могут произойти два реальных сценария. Таким образом, может быть случай, когда, скажем, у вас есть блок в ваших данных публикации, который с тех пор был удален из WordPress.

Возможно, это была сторонняя блокировка, которая была удалена. Так что это один из случаев неподдерживаемого блока, который не поддерживается ни во внешнем интерфейсе Faust, ни в реестре WordPress. В этом случае мы фактически возвращаем блок в блоки контента, называемые неопределенным блоком или неизвестным блоком, чтобы вы могли правильно ввести его в своем безголовом интерфейсе. И затем, вторая часть, если блок в реестре WordPress поддерживается, но еще не поддерживается в вашем внешнем интерфейсе Faust JS, в этом случае мы возвращаемся к отображаемому HTML. Таким образом, по крайней мере, вы визуализируете отображаемый HTML, а не null, undefined или любые подобные значения.

ТЕРЕЗА ГОББЛ: О, круто. И это на самом деле приводит меня к моему следующему вопросу. Что касается сторонних плагинов на безголовом отделенном веб-сайте, можете ли вы использовать сторонний плагин с помощью плагина WPGraphQL Content Blocks? Как все это работает вместе?

БЛЕЙК УИЛСОН: Да, да. Таким образом, для любого стороннего плагина, возвращаясь к этому первому или второму вопросу, если они взаимодействуют с функцией зарегистрированного типа блока в WordPress, этот блок будет автоматически отображаться для блоков контента WPGraphQL. Пока эти данные обрабатываются, вы можете создать блок в интерфейсе Faust JS. И самое замечательное в этом то, что, скажем, у вас есть сторонний блок для карусели. После того, как вы создали это один раз в своем внешнем интерфейсе Faust JS, вы можете затем повторно использовать его в других проектах в будущем.

ТЕРЕЗА ГОББЛ: О, отлично. Вот тут-то и появляется элемент повторного использования. И с помощью этого плагина вы действительно можете преодолеть часть этого разрыва со сторонними плагинами, которые не работают из коробки с несвязанными веб-сайтами.

Кроме того, если вы сейчас заглянете в чат, у нас на самом деле есть учебник, созданный, чтобы помочь людям создать блок из стороннего плагина. Итак, вы посмотрите в чат сейчас, вы сможете увидеть это и щелкнуть по нему. Дайте ему закладку.

Так как же обрабатывать блоки внутри блоков? Это может быть очень сложно. Не могли бы вы рассказать нам немного о том, как это будет выглядеть?

БЛЕЙК УИЛСОН: Конечно, да. Итак, у нас есть этот флаг или этот параметр, когда вы запрашиваете блоки контента, называемые плоскими. И это либо принимает истинное, либо ложное значение. И поэтому, когда это указано как true, вы фактически получите плоский массив или плоский список всех блоков на этой странице, будь то столбец, изображение или абзац.

У вас будет полный список всех блоков, запрошенных на этой странице, с двумя дополнительными свойствами. Одним из них является идентификатор узла. Так что это фактический идентификатор этого конкретного блока. И тогда у вас также будет идентификатор родителя, который является родителем этого блока. Итак, что вы можете сделать, так это преобразовать это в реальный иерархический список на вашем внешнем интерфейсе, в значительной степени решив головоломку внутреннего блока, как мы видели в Гутенберге раньше.

ТЕРЕЗА ГОББЛ: Потрясающе. Так что на самом деле есть опция при выборке блоков контента, которую вы можете указать, чтобы возвращать плоский список блоков в пределах их соответствующих родительских дочерних идентификаторов?

БЛЕЙК УИЛСОН: Да, да, именно так.

ТЕРЕЗА ГОББЛ: Отлично. У нас также есть еще один учебник здесь, в чате, опять же, для блоков контента WPGraphQL, чтобы взглянуть на эту конкретную функцию. Итак, я хотел задать вам еще один вопрос о стилизации — стилизация с помощью глобальных таблиц стилей, встроенных, каков подход? Как обрабатывается стиль?

БЛЕЙК УИЛСОН: Да, да. Таким образом, стиль, вероятно, является одним из самых больших толчков, которые мы пытаемся исследовать прямо сейчас. В примере, который я только что показал, используются встроенные стили.

Также поддерживаются глобальные стили, глобальные таблицы стилей. И я думаю, что вы коснетесь этого далее в дорожной карте. Но в идеале мы также хотим поддерживать поддержку theme.json, где мы можем получить поля, отступы, цвета и всю другую полезную информацию из theme.json, а затем применить ее. Так что мы будем работать над этим на следующем этапе разработки.

ТЕРЕЗА ГОББЛ: Потрясающе. Спасибо, что провели нас через это. Я знаю, что многие люди действительно взволнованы этим. Так как же нам запретить издателю использовать неподдерживаемые блоки?

БЛЕЙК УИЛСОН: Да, да. Значит есть плагин. Это зависит. Если вы используете сторонние блоки, в некоторые из них уже встроена эта функция.

Но если нет, то есть плагин под названием «видимость блоков», с помощью которого вы можете переключать определенные блоки с точки зрения издателя. Допустим, у вас есть карусельный блок, который еще не реализован на вашем сайте Faust. Вы можете установить блочную видимость и снять флажок, чтобы издатель не использовал ее, пока она не поддерживается или находится в разработке.

ТЕРЕЗА ГОББЛ: О, круто. То есть видимость блоков плагинов может переключать, скрывать и показывать определенные блоки?

БЛЕЙК УИЛСОН: Да, да, именно так. Таким образом, у вас есть ограниченное количество блоков, которые вы поддерживаете, как на стороне WordPress, так и на вашем безголовом сайте, чтобы издатели знали, хорошо, мы можем использовать это с уверенностью, что это будет поддерживаться на внешний интерфейс.

ТЕРЕЗА ГОББЛ: О, это точно звучит как более чистая подача. Ладно, круто. Последний вопрос к вам. Соответствуют ли эти внешние блоки редактору издателя?

БЛЕЙК УИЛСОН: Да, отличная реплика. Так что еще нет. Это то, над чем мы собираемся работать в будущем, но на данный момент эти блоки поддерживаются для безголового внешнего интерфейса.

Если у вас есть пользовательский блок, созданный в WordPress, и вы используете команду создания блока NPX, вам все равно потребуется поддерживать это представление на стороне WordPress. Но это то, над чем мы работаем. У нас есть это в нашей дорожной карте.

ТЕРЕЗА ГОББЛ: О, круто. ХОРОШО. Спасибо, что обсудили с нами эти вопросы, Блейк. Это было действительно полезно, и демо тоже.

Давайте продолжим, переключим передачу и на самом деле немного поговорим о дорожной карте проекта. На самом деле у нас есть пять фаз, две из которых уже завершены — фаза 1 и фаза 2. На фазе 1 мы увидели реализацию метода деконструкции, а затем эффективной реконструкции блока.

После этого мы перешли к этапу 2, который был сосредоточен на более тесной интеграции Faust с блоками Gutenberg, чтобы гарантировать, что у людей есть полный доступ к различным утилитам и вспомогательным функциям, которые там есть. Этот следующий этап, на котором мы сейчас находимся, этап 3, мы сосредоточены на обеспечении поддержки theme.json и повторно используемых блочных библиотек, как Блейк упомянул во время нашего технического обсуждения.

После того, как мы это сделаем, наступят этапы 4 и 5. Фаза 4 сосредоточена на улучшении существующего опыта разработки и редактирования, а фаза 5 — на поддержке более широкой экосистемы за пределами ядра WordPress. Мы очень рады этим предстоящим этапам, и мы надеемся, что вы свяжетесь с нами и заглянете в наш блог, чтобы быть в курсе того, где находится дорожная карта.

Вы можете увидеть ссылку в чате ниже на наши сообщения в блоге, если вы посмотрите. Идите и добавьте их в закладки. Что ж, спасибо всем за то, что присоединились к нам для обсуждения React-Gutenberg Bridge. Я хочу вернуть Блейка на экран здесь, чтобы он тоже мог поблагодарить и дать нам немного больше информации о том, куда вы можете пойти, если у вас возникнут нерешенные вопросы после этого.

БЛЕЙК УИЛСОН: Да, спасибо, Тереза, и спасибо всем, кто сегодня присоединился к этой сессии и смотрел ее. Мы очень рады получить отзывы сообщества об этой функции, чтобы вы все могли начать ее опробовать.

Так что, если вам это нравится, у нас есть пример проекта по ссылке в чате. У нас также есть ссылка в чате для нашего безголового Discord, так что это просто место, где вы и другие единомышленники безголовых разработчиков можете присоединиться и поговорить о предстоящих функциях и выпусках в безголовом пространстве. Так что спасибо вам всем еще раз. Мы действительно это ценим.