Как я написал YandexMarket2 на Vue.js

Привет, сообщество!

Вчера опубликовал большое обновление компонента YandexMarket2 и, наконец, могу рассказать о технических подробностях, которые анонсировал ещё здесь.
Серии уроков не будет — уж слишком долго пишу тексты.

Так вышло, что я уже больше двух лет активно не разрабатывал сайты на MODX, позабыл Ext JS, быстро привык к Vue.js на фронте, к PHP 7+ с автозагрузкой классов и захотел привнести это в нашу систему. Изначально планировал сделать компонент со слабой связанностью с MODX, чтобы можно было легко портировать на MODX3, а то и на другие системы. Скажу сразу: внедрить всё не удалось, а то бы до сих дорабатывал первую версию.

Заметкой хочу показать процесс и удобство разработки компонента, а может и подтолкнуть кого-то ещё написать компонент с интерфейсом на Vue.js, а то и полноценную админку для MODX4 (шутка. или нет :)

Общая концепция

За основу компонента взял стандартную заготовку modExtra.
А дальше уже плохо помню что и как, могу пропустить какие-то важные моменты и перепутать, так как делал давно)

Сперва много изучал, кто и как внедрял Composer (менеджер пакетов для PHP) в MODX-пакеты. И наткнулся на реализацию удобной разработки компонентов для MODX с использованием Composer — github.com/craftsmancoding/repoman — интересная концепция, но заброшена. Ребята даже написали огромную конвенцию для разработчиков компонентов (прочитал только про Autoloading).

В итоге в core/components/yandexmarket2 проинициализировал composer, чтобы держать всю логику в папке src/ рядом со стандартной структурой пакета.

Я быстро отказался от идеи переделать всё что можно, поэтому почти всё стандартное: процессоры, лексиконы, контроллеры, схема и даже модели, но для них есть соответствующие прокси-классы. И чтобы в MODX классах использовать свои namespaced классы, пришлось везде добавить подобное:

require_once(dirname(__FILE__, 3).'/vendor/autoload.php'); //3 - глубина

Далее в корне проекта через vue-cli создал vue проект и начал экспериментировать, чтобы найти наиболее удобный способ работы. Вообще компоненты собираю на установке прямо на хостинге. Делать локальную копию мне совсем не хотелось и делать каждый раз сборку проекта по каждому чиху, дожидаться загрузки на сервер и обновлять там страницу соответственно тоже.

Хотелось сделать, чтобы локально запущенная html страничка с функцией hot-reload через vue serve связывалась с MODX на сервере и оперировала его данными. К этой страничке (стандартная заготовка index.html) и подключены выкачанные стили со шрифтами из админки.

Из-за механизма CORS с локальной машины просто так не подключиться к серверу, так как браузер не захочет отправлять куки (где хранится ID сессии). С заголовком modAuth проблем нет, но куки приходится прокидывать в кастомном заголовке modCookie (предварительно разрешив его политикой Access-Control-Allow-Headers), который уже на сервере обрабатывается и добавляется в PHP массив $_COOKIE. После чего запрос успешно авторизовывается и возвращает данные из процессоров.

Для этого механизма иногда обновляю руками в локальном env файле (для vue) modAuth токен и два параметра для печенек: MODSESSID, PHPSESSID. Может кто глубоко погружался, зачем нам два разных ID сессии?)

Ну а дальше уже можно более-менее по пунктам.

Фронтенд

Больше двух лет назад @srs опубликовал несколько заметок про использование vuejs вместо extjs с дальнейшими пояснениями и даже заготовкой для разворачивания modExtra.
Но с тех пор так ни одного компонента с Vue в modstore не появилось (поправьте, если ошибся).
Эти заметки помогли не наступать на некоторые грабли и сэкономить время.

Я решил пойти немного дальше и внедрить целый фронтенд UI фреймворк, чтобы не изобретать велосипед.
На одном из проектов уже использовал Vuetify, где есть множество подходящих компонентов (табы, таблицы, деревья, инпуты, комбобокс), которые можно стилизовать под стиль стандартной админки MODX, чтобы не смотрелось инородно.

Чтобы стили фреймворка не конфликтовали со стилями MODX и админка не поехала, при сборке итогового css файла к каждому свойству добавляется специальный префикс. Тут на помощь пришла магия Webpack, который до сих пор нормально не освоил и многого там ещё не понимаю.

Что-то много текста, а картинок нет. Вот пример встраивания дерева полностью на Vue.

Причём процессор для получения ресурсов можно использовать прям стандартный или из miniShop2, но тут используется собственный, наследованный от modResourceGetNodesProcessor, чтобы добавить свои условия для выборки и немного убрать лишнего из присылаемых данных.

Не ставил цели сделать полную визуальную и функциональную копию ExtJs компонентов.
Из Vuetify выкинул стандартные иконки, заставил использовать наши иконки (которые FontAwesome, но с префиксом icon-) и, как мне кажется, выглядит довольно органично. Отступы и шрифт немного увеличены, чтобы стать более дружественным к сенсорным устройствам).

Помимо этого сделал похожим компонент табов.

Vuetify стилизуется достаточно хорошо. Я использовал как минимум 3 варианта подгонки:

• Часть свойств для визуального вида можно передать как параметр компоненту.
• Можно также указать заранее описанные в документации SASS переменные — как глобальные вроде размера шрифта, так и отступы или ещё какие-то размеры по каждому компоненту.
• А то, что разработчики не предусмотрели для изменения (потому что соблюдают Material Design гайдлайны), всегда можно поменять старым добрым CSS переопределением, чем частенько пользовался.

Хватит про фронтенд, на бэкенде тоже интересно. Ну и всегда можно в комментариях спросить про Vue)

Серверная составляющая

Вообще, очень хотелось писать на PHP с автозагрузкой классов, чтобы были только namespace без всяких require, использовать composer и PHP8 хотя бы PHP 7.1.

Когда перед первым релизом решил проверить, как отрабатывает cron скрипт, то оказалось, что для PHP 7.1 ещё рановато. Был неприятно удивлён, что скрипт даже не запустился, а сразу упал с ошибкой. Раньше на shared-хостингах почти не пользовался терминалом и был уверен, что версия PHP для сайта совпадает с серверной версией.

Сейчас пользуюсь только modhost.pro и там по умолчанию php cli версии 7.0. Конечно, на modhost можно запустить и другую версию PHP так (это же не запрещено?)

/usr/bin/php7.4 ~/www/core/components/yandexmarket2/cron/generate.php

Но на других хостингах вполне могут быть другие пути и проще было поправить код до версии 7.0, чем решать множество проблем в поддержке.

Признавайтесь, кто ещё на PHP <= 7.0?

Напомню, что для сгенерированных MODX-классов (которые от xPDOSimpleObject) сделал свои proxy-классы Pricelist, Field и т.д, наследуемые от базового абстрактного. В конструктор которых прокидываю уже объект $modx и соответствующий xPDO объект.

<?php
...
abstract class BaseObject
{
    protected $modx;
    protected $object;

    public function __construct(modX $modx, xPDOObject $object = null)
    {
        $objectClass = static::getObjectClass();
        /** @var xPDOObject $newObj */
        if (!$object && $newObj = $modx->newObject($objectClass)) {
            $object = $newObj;
        }
        if (!$object || !is_a($object, $objectClass)) {
            throw new InvalidArgumentException("You must provide ".$objectClass.' entity');
        }
        $this->object = $object;
        $this->modx = $modx;
    }

    //тут наследники должны вернуть класс объекта, который они проксируют
    abstract public static function getObjectClass(): string;
    ...

По идее все методы проксируются внутрь конечного объекта, но какие-то поля обрабатываются: даты, json в более подходящий вид. И во всей своей логике используются уже нормальные классы.

Когда ставил composer, то думал что в проекте появится куча зависимостей, но на деле там всего 2 сторонних, причём одна из них — это пакет agelxnash/jevix, который используется для обработки контента для CDATA полей. Чтобы не ставить принудительно компонент Jevix. Да и pdoTools для работы компонента не нужен. Понадобится, если кто-то захочет использовать Fenom обработку значений.

Тут я понял, что не упоминал, что компонент пишет XML файл с использование стандартного класса XmlWriter, а не как старая версия, собирающая файл из текстовых строк (и как большинство выгрузок что видел).

Изначальной идеей всей выгрузки было получить все товары за 1 запрос. Я даже был уверен, что так и есть. Пока не добавил debug_mode с показом количества запросов.

В проекте вовсю использовался $modx->getIterator($className, $q), чтобы не упереться в память при большом количестве товаров (да ещё обернув это php генераторами). И выяснил, что там достаточно неэкономно собирается объект msProduct, даже если руками приджойнены msProductData и msVendor, то при попытке получить какое-то из значений товара или просто при $product->toArray() для каждого экземпляра будет выполнено по паре запросов в БД.

Чтобы решить эту проблему пришлось написать свой xPDOLazyIterator (а может лучше нужно было назвать Greedy), где с помощью рефлексии класса msProduct (ReflectionClass) объекту проставляются protected свойства Data и Vendor с соответствующими созданными экземплярами из данных этой же записи.

Возможно, этот механизм нужно будет внедрить в miniShop2 (там рефлексия не нужна, а просто хватит проверки, все ли поля были получены для этих объектов из базы и засеттить их в соответствующие свойства).

Иначе для выгрузки пару тысяч товаров с несколькими сотнями категорий было несколько тысяч запросов в БД, а сейчас вся выгрузка на этом проекте менее 50 запросов (с учётом MODX запросов) формирует за 15 секунд 7-мегабайтный файл потребляя около 20мб оперативной памяти.

Рабочий процесс

Я работаю в PhpStorm с сервером на modhost, как вы поняли. Там же подключаюсь к базе данных через SSH-туннель и по сути никакой особо разницы нет с какими-то локальными решениями. Vue старательно обновляет страницу при любом изменении фронтенда, контроллер в dev-ветке разрешает присылать ему псевдо-куки)

Теперь касательно сборки и деплоя проекта. Стили и скрипты из корня собираются только в ветке master по команде vue-cli-service build и автоматически кладутся по пути /assets/components/yandexmarket2/. Соответственно никаких node js пользователям ставить не нужно. Исходники Vue в пакет не попадают, но не уверен, что они кому-то полезны, пока я их бесконечно меняю)

В итоге пакет упаковывается стандартным методом через build.php. Тут, наверное, больше нечего добавить.

Минусы такого подхода

Небольшой минус, это то, что цветовая схема жёстко прибивается и не стилизуется вместе с админкой MODX, когда там используются темы или кастомизации)

А более существенный, это то, что сторонним разработчикам сложно переопределить скрипты и стили, например, чтобы добавить своё поле, как это можно делать с ExtJs через плагины.
Хотя сборка исходников может решить эту проблему.

Вывод

Работать удобно и приятно с более строго типизированным PHP (с версии 7.4 было бы вообще супер) и реактивным Vue.js. Переписывать SeoFilter на Vue.js пока не планирую, там интерфейс сложнее, но рефакторинг там давно напрашивается)

Статья получилась довольно длинной и скучной, но кто осилил — поделитесь мнением.
Нужно ли дальше делать подобные компоненты или они наоборот уводят MODX куда-то в сторону?)

/usr/bin/php7.4 ~/www/core/components/yandexmarket2/cron/generate.php

php7.4 ~/www/core/components/yandexmarket2/cron/generate.php