С каждым годом в веб разработке появляется все больше разнообразных решений которые используют модульный подход и упрощают разработку и редактирование кода. В данной статье я предлагаю вам свой взгляд на то, какими могут быть переиспользуемые front-end блоки (для проектов с бэкендом на php) и предлагаю пройти все шаги от идеи до реализации вместе со мной. Звучит интересно? Тогда добро пожаловать под кат.
Реализация будет в виде composer пакета, который можно будет использовать в совершенно различных проектах, без привязки к WordPress.
Мотивом написать данную статью было желание поделится решением для организации модульных блоков, а также желание читателя хабра написать свою статью, что сродни желанию создать свой пакет, которое порой возникает у начинающих использовать готовые пакеты composer или npm.
Как можно заключить из текста выше, это моя первая статья на хабре, по-этому просьбане бросать помидоры не судить строго.
Генерировать html и управлять зависимостями блоков мы будем через php, что говорит о том, что наш пакет будет подходить для проектов с бекендом на php. Также условимся на берегу что, не вдаваясь в споры, не будем поддаваться влиянию новомодных вещей, таких как css-in-js или bem-json и будем придерживатьсяэль-классико классического подхода, т.е. предполагать что html, css и js это разные файлы.
Теперь давайте сформулируем наши основные требования к будущему мини-фреймворку:
Теперь давайте продумаем структуру нашего мини фреймворка более детально.
зажечь оправдать слово фреймворк в названии для нашего пакета, а именно – указать требования к коду наших блоков:
Ниже части реализации (классы) будут в формате : текстовое описание, код реализации и код тестов. Согласен с людьми, которые говорят что тесты есть лучшая документация, однако к своему стыду я начал использовать их в своих проектах недавно, по-этому не смотря на мои старания их имена или структура могутповергнуть в шок сбивать с толку, просьба не принимать близко к сердцу.
FieldsReader
Все наша магия при работе с моделями и контроллерами будет строится на функции ‘get_class_vars’ которая предоставит нам имена полей класса и на ‘ReflectionProperty’ классе, который предоставит нам информацию об этих полях, такую как видимость поля (protected/public) и его тип. Мы будем собирать информацию только о protected полях.
Также упростим дальнейшую разработку, добавив автоинициализацию стандартных полей значением по умолчанию, это избавит нас от необходимости инициализировать их в конструкторе вручную, что при большом количестве блоков сэкономит наше время.
FieldsReader.phpFieldsReaderTest.php
Model
Данный класс по сути лишь небольшая обертка для класса FieldsReader, который содержит поле ‘isLoaded’, что отвечает за состояние модели, оно пригодится нам когда мы будем работать с twig, и функции ‘getFields’, которая возвращает массив со значениями protected полей, в котором ключи это их имена.
Model.phpModelTest.php
Controler
Данный класс также как и Model наследует класс FieldsReader, однако имеет и другие важные задачи. Содержит два поля – модель и массив ‘external’, который пригодится нам далее при работе с twig шаблоном.
Статический метод getResourceInfo позволяет получить информацию о статических ресурсах данного блока (twig,css,js) , такую как имя ресурса или относительный путь к нему (мы можем получить это из имени и пространства имен контроллера благодаря соблюдению требований выше).
Метод getTemplateArgs будет возвращать данные для twig шаблона, это все protected поля соответствующей модели (без префикса ‘_’ если есть) и два дополнительных поля, _template и _isLoaded, первое будет содержать путь к шаблону, а второе отображать состояние модели. Также в этом методе мы реализуем возможность использовать блок в блоке (т.е. иметь класс Model в другом классе Model как поле) - мы соединяем поля контроллера и поля соответствующей модели по имени : т.е. если каждому полю с типом контроллер мы находим соответствующее поле в модели (с типом модель), то мы инициализируем поле контроллер моделью и вызываем метод getTemplateArgs у этого контроллера, получая таким образом все необходимую информацию для отображения этого вложенного блока.
Метод getDependencies на основании наших полей с типом контроллер рекурсивно (с обходом всех подзависимостей) возвращает нам уникальный (т.е. без повторений) список используемых классов-контроллеров, что помогает нам реализовать возможность зависимости ресурсов одного блока от другого.
Также отмечу отдельный момент, автоматическую инициализацию поля модели в конструкторе контроллера, т.е. если существует класс с таким же именем как у контроллера, но без суффикса (смотри требования выше), то это поле будет инициализировано объектом этого класса. Это позволит избежать лишнего кода в дальнейшем (т.е. создания модели отдельно от контроллера) и необходимо для расширения (это выходит за рамки нашей статьи).
Controller.phpControllerTest.php
Settings
Вспомогательный класс, думаю что не нуждается в комментариях
Settings.php
Twig
Также вспомогательный класс, лишь уточню что мы расширили twig своей функцией _include (которая является оберткой для встроенного и использует наши поля _isLoaded и _template из метода Controller->getTemplateArgs выше) и фильтр _merge (который отличается тем, что рекурсивно сливает массивы).
Twig.phpTwigTest.php
Blocks
Это наш объединяющий класс.
Метод loadAll загружает все контроллеры и вызывает статический метод onLoad у каждого контроллера (в нашем случае это не используется, как было указано выше это необходимо для расширения и выходит за рамки статьи).
Метод renderBlock принимает объект контроллера и производит рендер блока, передавая в twig шаблон аргументы из метода Controller->getTemplateArgs выше. Также добавляет класс используемого контроллера и классы всех его зависимостей в список использованных блоков, что позволит нам далее получить используемый css и js.
Ну и наконец метод getUsedResources используя список выше и статический метод Controller::getResourceInfo позволяет нам после рендера блоков получить используемый css и js код, объединенный в правильной последовательности, т.е. с учетом всех зависимостей./
Blocks.phpBlocksTest.php
Вот и все, теперь осталось объединить эти части и наш мини-фреймворк готов. Момент публикации composer пакета я опущу, т.к. это довольно простая задача и если вам будет интересно то вы без труда найдете информацию по этому поводу.
Создаем блоки для теста, пусть это будут Header, Article и Button. Header и Button будут независимыми блоками, Article будет содержкать Button.
Header
Header.phpHeaderC.phpheader.twigheader.css
Article
Article.phpArticleC.phparticle.twigarticle.css
Button
Button.phpButtonC.phpbutton.twigbutton.css
Подключаем наш пакет и рендерим блоки, результат вставляем в html код страницы, в шапке выводим использованный css код
example.php
в результате вывод будет примерно таким
example.png
Вот и все, спасибо за внимание.
Ссылки:
репозиторий с мини фреймворком
репозиторий с демонстрационным примером
репозиторий с примером использования scss и js в блоках (webpack сборщик)
репозиторий с примером использования в WordPress теме (здесь вы также можете увидеть пример расширения класса контроллера и использования автозагрузки всех контоллеров, что добавляет поддержку ajax запросов для блоков).
Источник статьи: https://habr.com/ru/post/556494/
Предисловие
Представлюсь - я молодой веб разработчик с опытом работы 5 лет. Крайний год я работаю на фрилансе и большая часть текущих проектов связана с WordPress. Несмотря на различую критику CMS в общем и WordPress в часности, я считаю сама архитектура WordPress это довольно удачное решение, хотя конечно не без определенных недостатков. И один из них на мой взгляд это шаблоны. В крайних обновлениях сделаны большие шаги чтобы это исправить, и Gutenberg в целом становится мощным инструментом, однако к сожалению в большинстве тем продолжается каша в шаблонах, стилях и скриптах, которая делает редактирование чего-либо крайне болезненным, а переиспользование кода зачастую невозможным. Именно эта проблема и подтолкнуло меня к идее своего мини фреймворка (читай пакета, но поскольку он будет предъявлять требования к структуре, то гордо назовем мини фреймворком), который бы организовывал структуру и позволял переиспользовать блоки.Реализация будет в виде composer пакета, который можно будет использовать в совершенно различных проектах, без привязки к WordPress.
Мотивом написать данную статью было желание поделится решением для организации модульных блоков, а также желание читателя хабра написать свою статью, что сродни желанию создать свой пакет, которое порой возникает у начинающих использовать готовые пакеты composer или npm.
Как можно заключить из текста выше, это моя первая статья на хабре, по-этому просьба
Постановка задачи
Понятие блок ниже будет по сути тем же понятием что и блок в BEM методологии, т.е. это будет группа html/js/css кода которая будет представлять одну сущность.Генерировать html и управлять зависимостями блоков мы будем через php, что говорит о том, что наш пакет будет подходить для проектов с бекендом на php. Также условимся на берегу что, не вдаваясь в споры, не будем поддаваться влиянию новомодных вещей, таких как css-in-js или bem-json и будем придерживаться
Теперь давайте сформулируем наши основные требования к будущему мини-фреймворку:
- Обеспечить структуру блоков
- Предоставить поддержку наследования (расширения) блоков
- Предоставить возможность использовать блок в блоке и соответственно поддержку зависимости ресурсов одного блока от ресурсов других блоков
Структура мини фреймворка
Как условились выше, такие ресурсы как css и js всегда будут в виде обычных файлов, т.е. это будут .js и .css или .min.css и .min.js в случае использования препроцесссоров и сборщиков (как webpack например). Для вставки данных в html код мы будем использовать шаблонизатор Twig (для тех кто не знаком ссылка). Кто-то может заметить, что Php и сам по себе хороший шаблонизатор, не будем вдаваться в споры, кроме доводов указанных на главной странице проекта Twig, отмечу важный для меня пункт, то что он дисциплинирует, т.е. заставляет отделять обработку от вывода и подготавливать переменные заранее, и в данном случае мы будем использовать его.Теперь давайте продумаем структуру нашего мини фреймворка более детально.
- Блок
Каждый блок будет состоять из:- Статических ресурсов (css/js/twig)
- Класса модели (его поля мы будет предоставлять как данные для twig шаблона)
- Класса контролера (он будет отвечать за наши ресурсы, их зависимости друг от друга и связывать модель с twig шаблоном)
- Вспомогательные классы : Класс Settings (будет содержать путь к блокам, их пространство имен и т.д.), класс обертка для Twig пакета
- Blocks класс
Связующий класс, который :- будет содержать вспомогательные классы (Settings, Twig)
- предоставлять функцию рендера блока
- содержать список использованных блоков, чтобы иметь возможность получить их ресурсы (css/js)
- автоматически загружать все контроллеры (небольшой задел на будущее, это немного выходит за рамки текущей статьи, скажу просто что необходимо для тестов и возможности расширения)
Требования к блокам
Теперь когда мы определились со структурой пришло время- php 7.4+
- Все блоки должны иметь одну родительскую директорию
- Классы моделей и контроллеров должны иметь PSR-4 совместимое пространство имен с автозагрузчиком (PSR-4 де факто стандарт, если вы используете автозагрузчик от composer, т.е. указываете autoload/psr4 директиву в вашем composer.json то ваш проект уже соответствует этому требованию)
- Соглашение об именах:
- Имя контроллера должно содержать ‘C’ суффикс
- Класс модели должен иметь то же пространство имен и то же имя (без суффикса) что и соответствующих контроллер
- Имена ресурсов должны соответствовать имени контроллера, но с данными отличиями:
- Без суффикса контроллера
- Верблюжья нотация в имени должны быть заменена на тире (CamelCase = camel-case)
- Нижнее подчеркивание в имени должно быть заменено на тире (just_block = just-block)
- Таким образом по правилам выше имя ресурса с контроллером ‘Block_Theme_MainC’ будет ‘block—theme--main’
Реализация
Пришло время перейти к реализации нашей идеи, т.е. к коду.Ниже части реализации (классы) будут в формате : текстовое описание, код реализации и код тестов. Согласен с людьми, которые говорят что тесты есть лучшая документация, однако к своему стыду я начал использовать их в своих проектах недавно, по-этому не смотря на мои старания их имена или структура могут
FieldsReader
Все наша магия при работе с моделями и контроллерами будет строится на функции ‘get_class_vars’ которая предоставит нам имена полей класса и на ‘ReflectionProperty’ классе, который предоставит нам информацию об этих полях, такую как видимость поля (protected/public) и его тип. Мы будем собирать информацию только о protected полях.
Также упростим дальнейшую разработку, добавив автоинициализацию стандартных полей значением по умолчанию, это избавит нас от необходимости инициализировать их в конструкторе вручную, что при большом количестве блоков сэкономит наше время.
FieldsReader.phpFieldsReaderTest.php
Model
Данный класс по сути лишь небольшая обертка для класса FieldsReader, который содержит поле ‘isLoaded’, что отвечает за состояние модели, оно пригодится нам когда мы будем работать с twig, и функции ‘getFields’, которая возвращает массив со значениями protected полей, в котором ключи это их имена.
Model.phpModelTest.php
Controler
Данный класс также как и Model наследует класс FieldsReader, однако имеет и другие важные задачи. Содержит два поля – модель и массив ‘external’, который пригодится нам далее при работе с twig шаблоном.
Статический метод getResourceInfo позволяет получить информацию о статических ресурсах данного блока (twig,css,js) , такую как имя ресурса или относительный путь к нему (мы можем получить это из имени и пространства имен контроллера благодаря соблюдению требований выше).
Метод getTemplateArgs будет возвращать данные для twig шаблона, это все protected поля соответствующей модели (без префикса ‘_’ если есть) и два дополнительных поля, _template и _isLoaded, первое будет содержать путь к шаблону, а второе отображать состояние модели. Также в этом методе мы реализуем возможность использовать блок в блоке (т.е. иметь класс Model в другом классе Model как поле) - мы соединяем поля контроллера и поля соответствующей модели по имени : т.е. если каждому полю с типом контроллер мы находим соответствующее поле в модели (с типом модель), то мы инициализируем поле контроллер моделью и вызываем метод getTemplateArgs у этого контроллера, получая таким образом все необходимую информацию для отображения этого вложенного блока.
Метод getDependencies на основании наших полей с типом контроллер рекурсивно (с обходом всех подзависимостей) возвращает нам уникальный (т.е. без повторений) список используемых классов-контроллеров, что помогает нам реализовать возможность зависимости ресурсов одного блока от другого.
Также отмечу отдельный момент, автоматическую инициализацию поля модели в конструкторе контроллера, т.е. если существует класс с таким же именем как у контроллера, но без суффикса (смотри требования выше), то это поле будет инициализировано объектом этого класса. Это позволит избежать лишнего кода в дальнейшем (т.е. создания модели отдельно от контроллера) и необходимо для расширения (это выходит за рамки нашей статьи).
Controller.phpControllerTest.php
Settings
Вспомогательный класс, думаю что не нуждается в комментариях
Settings.php
Twig
Также вспомогательный класс, лишь уточню что мы расширили twig своей функцией _include (которая является оберткой для встроенного и использует наши поля _isLoaded и _template из метода Controller->getTemplateArgs выше) и фильтр _merge (который отличается тем, что рекурсивно сливает массивы).
Twig.phpTwigTest.php
Blocks
Это наш объединяющий класс.
Метод loadAll загружает все контроллеры и вызывает статический метод onLoad у каждого контроллера (в нашем случае это не используется, как было указано выше это необходимо для расширения и выходит за рамки статьи).
Метод renderBlock принимает объект контроллера и производит рендер блока, передавая в twig шаблон аргументы из метода Controller->getTemplateArgs выше. Также добавляет класс используемого контроллера и классы всех его зависимостей в список использованных блоков, что позволит нам далее получить используемый css и js.
Ну и наконец метод getUsedResources используя список выше и статический метод Controller::getResourceInfo позволяет нам после рендера блоков получить используемый css и js код, объединенный в правильной последовательности, т.е. с учетом всех зависимостей./
Blocks.phpBlocksTest.php
Вот и все, теперь осталось объединить эти части и наш мини-фреймворк готов. Момент публикации composer пакета я опущу, т.к. это довольно простая задача и если вам будет интересно то вы без труда найдете информацию по этому поводу.
Демонстрационный пример
Ниже приведу демонстрационный пример использования пакета, с одним чистым css для наглядности, если кому-то интересен пример с scss/webpack смотрите ссылки в конце статьи.Создаем блоки для теста, пусть это будут Header, Article и Button. Header и Button будут независимыми блоками, Article будет содержкать Button.
Header
Header.phpHeaderC.phpheader.twigheader.css
Article
Article.phpArticleC.phparticle.twigarticle.css
Button
Button.phpButtonC.phpbutton.twigbutton.css
Подключаем наш пакет и рендерим блоки, результат вставляем в html код страницы, в шапке выводим использованный css код
example.php
в результате вывод будет примерно таким
example.png
Послесловие
Данный пакет был создан для личных целей, я использую его в своих проектах и он облегчает мне разработку, и я буду рад если он пригодится кому-то еще. Не стесняйтесь задавать вопросы и комментировать – я буду рад ответить на ваши вопросы и услышать ваше мнение.Вот и все, спасибо за внимание.
Ссылки:
репозиторий с мини фреймворком
репозиторий с демонстрационным примером
репозиторий с примером использования scss и js в блоках (webpack сборщик)
репозиторий с примером использования в WordPress теме (здесь вы также можете увидеть пример расширения класса контроллера и использования автозагрузки всех контоллеров, что добавляет поддержку ajax запросов для блоков).
Источник статьи: https://habr.com/ru/post/556494/