Комментарии 13
И как это совместимо будет с подходом
TypeScript->JavaScript, Less->CSS, SCSS->CSS?
Я с Elixir не работал, но исходя из того, что это надстройка над Gulp — его можно использовать и с CleverStyle Framework без особых сложностей. Можно либо складывать артефакты туда, откуда их автоматически подхватит фреймворк, либо написать кастомную небольшую интеграцию с помощью обработчиков упомянутых в статье событий.
Я пытался сделать работу со статикой максимально декларативной, то есть вы указываете какой файл (или группу файлов, которая в продакшене конкатенируется в один файл) нужен на какой странице, а обо всём остальном, включая версии и зависимости побеспокоится фреймворк. То есть вам никогда не нужно писать нечто подобное:
<link rel="stylesheet" href="{{ elixir('css/all.css') }}">
<script src="{{ elixir('js/app.js') }}"></script><link rel="stylesheet" href="{{ elixir('css/all.css') }}">
<script src="{{ elixir('js/app.js') }}"></script>
удобнее, чем
"assets" : {
"admin/Uploader" : "admin.css",
"Uploader" : "script.js"
},
в куче модулей.
Даже написание задачи gulp для нужных файлов все равно выйдет короче. Я б на вашем месте сделал gulpfile.js с заданием для скриптов/стилей модулей, которые у вас в комплекте идут, может кому понадобится
А как там с зависимостями, нужно в повторять подключение множества файлов раз за разом?
Вот есть у меня один модуль, в котором нужно загружать котиков, и второй модуль, который непосредственно реализует загрузку файлов в общем виде. В каждом из модулей есть набор CSS/JS/HTML файлов, но перед тем как грузить котиков мне нужен сам функционал загрузки.
В моем случае это будут два модуля, каждый из который имеет в простейшем виде следующее:
{
"package" : "Kitty",
"require" : "Uploader",
"assets" : {"Kitty": "*"},
...
}{
"package" : "Uploader",
"assets" : {"Uploader": "*"}
...
}gulpfile.js не подходит по идеологическим причинам — CleverStyle Framework не требует на сервере ничего кроме PHP, к тому же все модули опциональные, они в репозитории, но не обязательно в комплекте.
Использование только PHP позволяет делать удобные интеграции всего вместе в том числе с клиентского интерфейса, когда нет доступа к CLI в принципе. Например, установка Bower/NPM пакетов с помощью Composer плагина прямо из админки с интерактивным прогрессом, хотя для самого Composer в обычном режиме нужен доступ к CLI, а плагин должен быть установлен глобально.
А как там с зависимостями, нужно в повторять подключение множества файлов раз за разом?
такое разруливать самому, но случай какой-то странный.
Например, установка Bower/NPM пакетов с помощью Composer плагина прямо из админки с интерактивным прогрессом
это конечно круто, но я б отнес к разряду «свистелко-перделок».
Если нет ноды на серваке — то закидывать в cvs скомпилленные ассеты и не придется ничего запускать.
Даже если не используется никакая csv — по фтп закинуть скомпилленные файлы будет проще.
Вот есть у меня один модуль, в котором нужно загружать котиков, и второй модуль, который непосредственно реализует загрузку файлов в общем виде.
мы все еще про зависимости фронтэнда или про модули в вашей системе? Если модули в вашей системе — то что-то тут нечисто
мы все еще про зависимости фронтэнда или про модули в вашей системе? Если модули в вашей системе — то что-то тут нечисто
Зависимости между модулями используются и для бекенда, и для фронтенда, так что, полагаю, ответ зависимости фронтенда. В примере выше я имел ввиду именно его.
Самый простой случай — разные модули зависят от чего-то одного — например, от загрузчика в админке, для которого свой кусок собирается, и на публичной части сайта — +1 строка в каждую секцию, не особо критично и просто
а если у вас такое в бекэнде модуля — то что-то у вас нечисто
А если зависимость необязательная? К примеру, WYSIWYG редактор — на базовую функциональность не влияет, может как быть, так и отсутствовать. Криво как-то вписывать это вручную в gulp-задачу, да ещё с проверками на наличие файлов.
В том-то и преимущество в CleverStyle Framework — вы не прописываете вручную ничего для использования. Разработчик модуля объявляет всё декларативно во время разработки, после чего достаточно установить модуль, и на основании декларативной конфигурации нужное странице будет подключено и закэшировано как положено.
мне больше нравится подход чтоб я сам решал когда что подключить и нужно ли оно мне.
Вдруг я захочу вместо скрипта от модуля использовать свой?
Так я вместо скрипта от модуля напишу такс для своего и все, модуль продолжит обновляться, а мои изменения работать как мне нужно
может мне вообще не понадобится оттуда ничего кроме одного куска — в вашем случае все равно подключится то что система посчитает нужным.
Советов несколько:
- делите на самостоятельные куски, чтобы подключать только нужное
- если это JS — выделяйте в AMD модуль и грузите только его (об этом будет отдельный пост)
- если первые два варианта не подходят — есть вероятность, что лишнего кода не так много и с этим можно жить
Если совсем кастомная ситуация — вы всегда можете дополнить встроенную функциональность фреймворка и интегрировать туда в том числе gulp, если контролируете окружение. Фреймворк не покрывает 100% ситуаций самостоятельно, но оставляет возможности интеграции для покрытия 100% ситуаций при необходимости. Нужно следить за балансом предоставляемой из коробки функциональности.
Вдруг я захочу вместо скрипта от модуля использовать свой?
Вот здесь не совсем понятно что имеется ввиду. Модуль это самостоятельная единица, перезаписывать отдельные файлы тоже в теории можно (подписаться на события установки/обновления модулей и перезаписывать нужный файл поверх, либо подписаться на упомянутое в статье событие и редактировать путь к исходному файлу в маппинге ресурсов), но это уже как-то совсем дико. Какой сценарий имеется ввиду?
редактировать путь к исходному файлу в маппинге ресурсов
это и имеется в виду. Вдруг разработчик модуля слегка криворукий, а модуль все же полезный, мало ли что может быть. Пока работал с вордпрессом — такое бывало.
А так в gulpfile переписал путь и все, исходный файл не тронут
За советы спасибо, но я наверно не так объяснил что имел в виду — как раз визуальный редактор к примеру не нужен в публичной части сайта, а в админке норм
webpack + npm… не надо писать свои менеджеры модулей на php.
Bower/NPM используются и так, а вот Webpack зачем? Node.js на сервере может не быть, работает он медленнее, для интеграции в проект (таким образом, как это описано в статье) всё равно придется написать кучу кода. А так никаких императивных конфигураций не нужно и всё шустро работает. А если Webpack для чего-то нужен, то его можно несколькими строчками интегрировать как готовый сторонний сервис вместо того, чтобы требовать на уровне фреймворка.
Система сборки фронтенда в CleverStyle Framework или почему вам может быть не нужна кастомная