Gatsby анонсировали выход своего нового плагина (v4) для WordPress. Плагин был полностью переработан, чтобы улучшить установки headless WordPress, в которых Gatsby отвечает за фронтэнд. Плагин обладает интеграцией с Gatsby Cloud для обеспечения реалтайм-превью и инкрементальных билдов.
Команда Gatsby проделала долгий путь в сфере интеграции с WordPress-сайтами для сложных сценариев использования. В настоящий момент существует три способа работы Gatsby с WordPress, каждый из которых имеет свои плюсы и минусы:
- Gatsby Source WordPress + WP REST API
- Gatsby Source GraphQL + WPGraphQL
- Gatsby Source WordPress (v4) + WPGraphQL
Первый подход основан на использовании WP REST API для получения всех данных (постов, термов, медиа и т.д.) и кэширования их в кэше узлов Gatsby. Второй метод позволяет разработчикам писать GraphQL-запросы для извлечения данных из кэша Gatsby и обработки этих данных в шаблонах.
По словам разработчика Gatsby и создателя WPGraphQL Джейсона Бала, первые два подхода применимы только для самых простых сценариев использования.
«Если вы начинаете добавлять расширенный функционал, такой как, к примеру, Flex Fields от Advanced Custom Fields, WP REST API начинает разваливаться и становится очень сложным для работы в таком отделенном виде», – рассказал Джейсон. – «В WP REST API реализована схема, позволяющая плагинам и темам расширять это API и объявлять, к какому типу данных будет относиться каждая конечная точка. Это полезно для разделенных приложений, когда ясно, какие данные следует ожидать».
«Но проблема в том, что плагины и темы могут расширять WP REST API без использования схемы, к примеру, просто определяя типы полей как object ли array. Это означает, что у разделенных приложений, включая и Gatsby, нет простого способа понять, что несут в себе эти поля. Gatsby полагается на консистентные данные, но WP REST API не является консистентным. Форма данных, возвращаемых конечными точками (особенно когда плагины расширяют REST API), непредсказуема, что проблематично для разделенных приложений».
WPGraphQL создавался как альтернатива WP REST API, решая многие из этих болевых точек с помощью своей усиленной схемы. Такой подход позволяет сразу проанализировать схему, чтобы понять, какие данные доступны еще до их запроса.
«Даже в тех случаях, когда заданы Flex Fields от Advanced Custom Fields (возвращаемые данные могут поставляться в виде одной из поддерживаемых разметок Flex Fields), Gatsby все равно может сразу провести базовый анализ», – рассказал Джейсон. – «Усиленная схема в WPGraphQL позволяет поставлять разделенные инструменты, не боясь никаких ошибок».
Подход Gatsby Source GraphQL + WPGraphQL имеет некоторые улучшения по сравнению с использованием WP REST API, однако ранее он был ограничен отсутствием кэширования данных в кэш узла Gatsby. В итоге сайты WordPress не могли использовать облачные коммерческие предложения от Gatsby в виде превью и инкрементальных билдов. Джейсон объяснил, что связка Gatsby Source (v4) + WPGraphQL берет «лучшее из двух миров»:
«На WordPress-сервере используется WPGraphQL для представления данных WP в типизированной схеме GraphQL. Плагин Gatsby Source WordPress v4 использует GraphQL Introspection для чтения схемы с WordPress-сайта и создания практически идентичной схемы в Gatsby. Данные извлекаются с помощью WPGraphQL и кэшируются в Gatsby. Пользователи работают с GraphQL для взаимодействия с кэшем Gatsby и получения данных для обработки компонентов на сайте Gatsby».
Новая интеграция позволяет просматривать все изменения в реальном времени на сайте Gatsby путем щелчка по кнопке «превью». Процесс публикации больше не требует реконструкции всего сайта. Все изменения оперативно передаются на необходимые страницы. В итоге вы получаете быстрые статичные страницы во фронтэнде. Комбинация нового плагина вместе с Gatsby Cloud – идеальный опыт создания контента.
Если вы хотите протестировать бета-версию плагина Gatsby Source, вы можете найти его (и его зависимости) на GitHub. Также потребуются плагины WPGraphQL и WPGatsby.
Источник: wptavern.com
