Некоторое время назад я писал о Decoupled, Headless и традиционной архитектуре CMS. Этот пост посвящен выбору того, что вам подходит. Я писал о различных характеристиках архитектуры и их последствиях. Знание различий поможет вам выбрать подходящий вариант. Основываясь на этом посте, вы могли подумать, что вам нужно выбрать между Decoupled или Headless. Но, возможно, есть из чего выбрать.

Недавно мы поставили проект с React и Drupal. Проект требовал многогранного поиска наряду с возможностями CMS. Для соответствия требованиям мы интегрировали Searchkit с Drupal. Searchkit - это набор компонентов React с серверной частью Elasticsearch.

Фасетный поиск является основным компонентом, но в конечном итоге мы использовали другие компоненты React во внешнем интерфейсе.

Мы обнаружили, что интегрировать Searchkit было относительно просто, и на самом деле было очень приятно иметь такой богатый пользовательский опыт компонентов Searchkit и React. В конце концов мы начали создавать больше компонентов React для интерфейса и реплицировать этот богатый пользовательский интерфейс. С другой стороны, мы не хотели терять преимущества Drupal. Мы определенно хотели извлечь выгоду из внешнего интерфейса Drupal для создания тем / рендеринга структуры веб-сайта, такой как основной макет, навигация, логины пользователей и т. Д.

Постепенно развязанный

Зная, что нам требуются возможности CMS и мы хотим извлечь выгоду из тематики Drupal, мы не хотели использовать API-first или Headless подход. Однако нам нужно было хотя бы кое-что отделить. Мы использовали веб-сервисы Drupal для создания нескольких API и интеграции с другими приложениями. Для основного макета и структуры навигации мы использовали темы и шаблоны Drupal. Searchkit был подключен к шаблону страницы Drupal, который рендерился из контроллера страницы Drupal. Использованный нами подход фактически называется постепенно развязанный. Я считаю, что это не настоящий отраслевой стандарт. Dries написал об этом еще в 2015 году, и я думаю, что он придумал этот термин как бы отчасти. Есть даже блок-схема, которая поможет вам выбрать лучший подход к разделению Drupal. Хотя Дрис сказал, что постепенно разъединение - это будущее или, по крайней мере, будущее Drupal, я считаю, что это больше похоже на переходный период. Я думаю, что в нынешнем технологическом ландшафте с таким большим количеством различных устройств конечной целью является создание полнофункциональной безголовой CMS с чистым API. Сегодняшние безголовые CMS не так полнофункциональны, как CMS, такие как Drupal. Однако Drupal постоянно развивается до изолированной архитектуры и поэтому является интересным выбором.

React + интеграция с Drupal

Итак, как мы интегрировали React с Drupal? Давайте посмотрим поближе. В этом примере я предполагаю, что у вас есть опыт работы как с Drupal, так и с React. Если не прочтите об этом сначала, или просто пропустите эту часть.

В этом примере у нас есть тема Drupal, которая включает папку src с исходными кодами Javascript. Наши проекты фактически используют Машинопись, потому что мы считаем, что это помогает нам соответствовать нашим стандартам качества. Но для целей этого примера давайте остановимся на Javascript. Тема Drupal находится в (обычной) папке web / themes / custom. В корне проекта у нас есть package.json, который определяет все наши JS-зависимости. Также другие инструменты настройки, такие как webpack, находятся в корне папки. В результате все наши инструменты разработчика доступны из корневой папки. Таким образом, если ввести npm install в корне проекта, будут установлены все модули node_modules. Однако он будет собирать (npm build) исходники javascript в папке сборки, расположенной в теме Drupal, которая является общедоступной.

Файл Component.js в основном содержит загрузку и рендеринг компонента React. Это то, что вы ожидаете от обычной установки. Как в примере ниже.

Мы используем webpack и Babel для сборки и компиляции Component.js в build / component.js. Теперь для запуска компонента достаточно включить файл javascript на страницу. И вот здесь Drupal играет роль. Что мы сделали, так это определили библиотеку в нашей настраиваемой теме Drupal, которая ссылается на javascript component.js. Это позволяет нам прикрепить файл к шаблону, например, в массиве рендеринга Drupal. Как только библиотека станет доступной, мы можем использовать обработчики препроцессора или просто #attach для включения и запуска компонента практически в любом шаблоне.

Но обычная начальная загрузка React, как в приведенном выше примере, может вызвать проблемы. Он ожидает, что корневой элемент будет доступен, поэтому мы можем запускать его только тогда, когда доступна DOM. Для этого вам нужно немного изменить загрузку и использовать Drupal’s Javascript API. Drupal.behaviors позволяет вам делать эквивалент jQuery (document) .ready (). Это особенно важно при использовании динамического кеша страниц Drupal и BigPipe. Итак, обновите Component.js до чего-то вроде:

Следующим шагом является предоставление данных из Drupal в ваших компонентах React. Предполагая, что вы хотите передавать данные от сущностей или конфигурации. Вы можете использовать Drupal webservices для создания REST API, и ваш компонент React будет получать данные из этого API. Изначально мы начали с пары сущностей, которые хотели передать React. Поэтому мы просто закодировали объекты в JSON и включили это в наш шаблон Twig. Выглядит это так:

Вы также можете использовать drupalSettings для передачи ваших значений. Теперь осталось просто прочитать переменную в вашем компоненте React. Очевидно, вы можете немного улучшить начальную загрузку и внедрить данные в качестве свойств или состояния в свой компонент React.

В конце концов мы создали компоненты React, которые использовались как FieldWidgets на страницах администрирования Drupal. Мы повторно использовали компоненты в админке Drupal, чтобы включить настройку компонента и показать обновленный предварительный просмотр в реальном времени.

Заключение

Постепенная развязка, возможно, не самая чистая форма архитектуры и фактически добавляет связность. Однако это рентабельный и прагматичный подход, который открывает множество возможностей. Это позволяет вам создавать богатые компоненты пользовательского интерфейса, интегрированные в вашу любимую CMS. С другой стороны, это просто прагматический подход, пока экосистема Headless CMS не созрела. Тем не менее, он оказался успешным, и мы обязательно продолжим его использовать в будущих проектах.

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

Первоначально опубликовано на www.ibuildings.nl.