Vue.js для проекта на Bitrix

Привет, Хабр!

Меня зовут Дмитрий Матлах. Я тимлид в AGIMA. Мы с коллегами обратили внимание, что в сообществе часто возникает вопрос о том, как совместить на одном проекте Bitrix-компоненты и реактивные фронтовые движки. Мы неоднократно сталкивались с подобными задачами, и поэтому я решил подробно рассказать, как мы их решаем. Думаю, если вы используете Bitrix-фреймворк в своих проектах, прочитать будет интересно. Ну и забегая вперед, если вы решаете те же задачи по-другому, то интересно в комментариях узнать поподробнее.

Теория

Подходы к разработке шаблонов представления в проектах на 1С-Битрикс практически не менялись с момента создания платформы. 1С-Битрикс — MVC-фреймворк со своими особенностями. Но в то же время он всё равно работает по понятной схеме: данные модели + шаблонизатор с шаблоном представления = итоговый html клиенту. Классический вариант. Компоненты Битрикс и компоненты фронтовой части хранятся отдельно — всё круто.

Но вокруг все давно говорят о реактивных фронтовых движках и о новом уровне скорости работы и удобстве поддержки.

Интересно попробовать в своем проекте? Да! Но с Битрикс есть некоторые сложности.

Назрел вопрос: как уйти с проторенного пути и поменять фронтовый стек и при этом сохранить все возможности платформы:

• Возможность инкапсулировать логику в компоненты Битрикс.

• Использовать визуальный редактор для настройки роутинга и ключевых параметров модели.

• Сделать интеграцию Backend- и Frontend-разработки простой и понятной.

• Поддержать возможности современной фронтовой разработки. Прежде всего, сборку с Webpack. Что даст фронтовому разработчику возможность использовать ES6 и модульную структуру JS.

• Обеспечивать индексацию контента страниц поисковым ботом, так как инициализация приложения проходит методами JS и до этого момента на странице не отображаются элементы DOM контентной части. Это создает сложности работы поисковым ботам, которые «не умеют» запускать JS на странице либо делают это частично. В качестве решения выступает механизм SSR (Server Side Rendering). Этот вопрос выходит за рамки данной статьи, и мы уже написали про это отдельную статью.

Теперь пробуем со всем этим взлететь.

Сейчас на рынке для перехода по фронтовому стеку есть два популярных решения —  два реактивных JS-фреймворка. Думаю, вы догадываетесь, какие именно: React.js и Vue.js.

Нам ближе оказался Vue.js. Вот почему:

• простота использования;

• прекрасная документация;

• легковесность (около 20 КБ — минимизированная сжатая версия);

• может быть принят постепенно, даже используется как замена jQuery;

• удобная структура хранения html, CSS, JS в компонентах;

• все необходимые библиотеки в составе Router, Vuex (global store);

• хорошая расширяемость (миксины, плагины и т. д.).

Итак, какие есть сложности?

Менять нужно не только стек, но и базовый паттерн с MVC на MVVM. Далее небольшой экскурс.

Работа компонента Битрикс при подходе MVC

Для вывода контента страниц в общем случае используется компонент и его шаблон как основа визуальной части. Роутинг начинается от корня раздела, где находится компонент. Компонент может быть простым и комплексным, т. е. отдает контент одной страницы либо различных в зависимости от параметра в URL.

Такая структура отражает паттерн MVC. Всё привычно. View — шаблон template.php — собирает html для отображения клиенту и, возможно, добавляет JS, который дополнит динамические возможности страницы.

Входные параметры при этом мы задаем при вызове компонента. Эти параметры попадают в шаблон вместе с данными из базы, которые им соответствуют, а роутинг осуществляется на серверной стороне.

Работа с Vue.js реализует паттерн MVVM. 

Работа компонента Битрикс при подходе MVVM

Посмотрим на схему работы приложения Vue.js.

Представление формируется на базе компонента по текущему роуту и данных, которые содержит состояние (store). 

Предлагаю обратить внимание на два момента.

1. Источник данных абстрагирован, т. е. это некий Backend, API, который отдает View-модели данные для отображения в компоненте по Endpoint’ам, определенным в методах actions.

2. Vue-приложение с несколькими логическими блоками, такими, как список/детальная, должно иметь внутренние правила роутинга для выбора подходящего компонента и комплектации представления нужными данными.

По нашему условию, приложение должно подключаться через один общий компонент, настраиваться через параметры в визуальном редакторе и содержать всё необходимое для работы в одном компоненте (возможно, комплексном).

С практической стороны это значит, что компонент Битрикс должен реализовать работу Vue-приложения с пробросом настроек компонента в настройки внутреннего роутинга SPA и обеспечить работу Endpoint’ов в части источника данных (Backend на схеме). Компонент должен «научиться» двум режимам работы:

1. При запросе к странице с Vue-приложением должен вернуть разметку SPA (single page application), код приложения, объект роутинга, объект хранилища и начальное состояние. Т. е. ведет себя как простой компонент с одним шаблоном.

2. При запросах данных в режиме Backend должен возвращать структуру для определения текущего состояния. Используем формат JSON. В таком варианте удобно использовать ЧПУ-режим комплексного компонента.

Соберем всё вместе

Упрощая, можно сделать абстрактный пример работы нашего компонента для каталога с выводом страницы списка и детальных страниц товаров.

При синхронном обращении компонент вернет разметку с блоком привязки Vue-приложения:

• Скрипты фреймворка и плангины Vue, Vue-router, Vuex, Axios.

• Базовые JS-объекты данных GlobalVuexStoreCatalog(list), GlobalVuexStoreProductCard(detail).

• В составе SPA могут находиться сразу несколько шаблонов различных по назначению страниц, таких, как страница списка, детальная, страница результатов поиска и т. д. В таком случае требуется внутренний роутинг. JS-объект c правилами роутинга. Ремарка: в роутинге может не быть необходимости, если в составе SPA страница только по одному шаблону.

• Глобальный JS-объект данных для SPA.

<script type="text/javascript" data-skip-moving="true">   if (typeof window.vueData !== "object") {       window.vueData = {};   }   window.vueData.url404 = '/404.php';   window.vueData.is404 = <?=$is404 ? 'true' : 'false'?>; … </script>

При асинхронном обращении компонент вернет данные из компонента Section либо Detail в виде JSON, который будет добавлен в ветке STATE Vuex-хранилища приложения.

Макеты верстки не содержатся в шаблонах компонентов Битрикс.

Шаблоны компонентов Vue, инициализация приложения целиком на стороне Frontend. Подключается в виде файлов сборки Webpack: catalog.js, catalog.css.

Разберем на примере для шаблона компонента каталога Axios. Для вывода SPA каталог должен иметь такую структуру:

Состав файлов /js/vuex.catalog.list.js и /js/vuex.catalog.product.js Vuex-структуры хранения и управления состоянием.

element.php и section.php — точки входа запроса. Они содержат вызовы компонентов реализации с буферизацией. В составе их обработки входит:

ob_start(); $ElementID = $APPLICATION->IncludeComponent(   "bitrix:catalog.element",   "shop.vue.element",   array(       "IBLOCK_TYPE" => $arParams["IBLOCK_TYPE"],       "IBLOCK_ID" => $arParams["IBLOCK_ID"], ...   ),   $component,   array("HIDE_ICONS" => "Y") ); $jsonElementData = ob_get_clean(); $is404 = (defined(ERROR_404) && ERROR_404 === 'Y') || \CHTTP::GetLastStatus() === '404 Not Found';

На выходе получаем объект JS, который можем добавить в component_epilog.php — общая часть. В нем содержится контейнер для вывода Vue-приложения и определение общей части значений Store.

<div id="catalog-vue" v-cloak></div> <div class="vue-preloader">   <div class="vue-preloader__container"> ...   </div> </div>

Также здесь подключаются файлы сборки Frontend.

Asset::getInstance()->addCss(MARKUP_DIR . '/css/catalog.css', true);

Asset::getInstance()->addJs(MARKUP_DIR . '/js/catalog.js');

В итоге выходит такая схема:

На стороне Frontend-сборки JS-объекты Store подключаются в качестве модулей Vuex:

<script> import {useRouter} from "vue-router"; import {useStore} from "vuex";   export default {   setup() {       const router = useRouter();       const store = useStore();         /* eslint-disable */       if (typeof GlobalVuexStoreCatalog !== 'undefined') {           store.registerModule('catalog', GlobalVuexStoreCatalog);       }       if (typeof GlobalVuexStoreProductCard !== 'undefined') {           store.registerModule('product', GlobalVuexStoreProductCard);       }       return {           router,       }   }, } </script>

Настройки роутинга также подключаются из внешнего JS-объекта, который мы определили в компоненте Битрикс.

const routes = window.routerSettings.routes.map((it) => {   switch (it.type) {       case 'catalog':           return {               path: it.path, component: catalog           };       case 'product-card':           return {               path: it.path, component: product           };   } });   const router = createRouter({   history: createWebHistory(window.routerSettings.BASE_URL),   routes,   scrollBehavior: () => {       return { left: 0, top: 0 };   } })   ... app.use(VueWindowSizePlugin, {   delay: 300, }); app.use(router);   app.mount('#catalog-vue')

Итоги

Таким образом, мы даем возможность оставить всю реализацию компонентов отображения в отдельном репозитории и собирать их с помощью удобных для Frontend-разработчика инструментов.

Мы не переносим верстку в шаблоны компонентов Битрикс, что позволяет избежать этапа интеграции верстки и использовать протестированные макеты, точно совпадающие с требованиями. При проработке задачи требуется создать структуры хранения данных состояния «Store»-компонентов, общие для Backend и Frontend, для создания JSON-файла «заглушки» с приемочными данными для этапа сдачи макета верстки со стороны Frontend.

Реализация может показаться непростой, но в итоге приводит к понятной схеме разделения ответственности разработчиков и удобному внедрению компонентов с Vue-приложениями, в том числе и для использования в блоках конструктора лендингов «Сайты24».

Если вы дочитали до конца, то в этом точно есть что-то героическое, и думаю, вы заслуживаете плюс в карму.