Для систематизации активных проектов, а также для быстрого старта новых в недрах компании был разработан шаблон-заготовка, содержащий много полезностей для эффективной работы:
Что проект может предложить искушенным битрикс-девелоперам:
"Безопасная" структура
Конфиги, гит-директория, вендорные файлы находятся аж на 2(!) уровня выше веб-директорий.
"Готовность" к многосайтовости.
Зачастую (особенно, когда гит инициализируют в корневой веб-директории) добавление второго сайта под версионный контроль становится непростой (и внезапной) задачей. В нашем случае эта проблема решена на архитектурном уровне. Проект изначально стартует в структуре, подразумаевающей наличие нескольких сайтов.
Композер "из коробки".
Помимо очевидной автозагрузки, и подключения сторонних библиотек общего назначения, также становится возможна установка Битрикс-модулей из Packagist и публичных/приватных репозиториев (благодаря пакету composer installers)
Данный пакет позволяет снизить количество копипасты файлов шаблонов при создании и наследовании компонентов, а также более явно разделить слои контроллера и отображения (Иными словами использовать Bitrix API в шаблоне становится намного сложнее).
Огромные возможности по работе с данными "из коробки" и простой механизм расширения.
Работа с клиентской частью в Битрикс, мягко говоря, немного отстает от современных реалий веб разработки. Поэтому управление фронтом решено было делегировать более подходящему инструменту.
Который как следует из названия является настройкой над Вебпаком.
Он позволяет относительно легко настроить работу с актуальным стеком технологий.
В нашем случае это:
6 Редакция Javascript (ES6)
VueJS для "сложного-богатого" фронтенда
SCSS и БЭМ для организации работы со стилями
Версионирование и деплой.
Чтобы релизить как можно чаще и быть уверенным, что все будет пернесено, собрано, установлено как надо, используется утилита для автоматизированного деплоя https://deployer.org/
При использовании системы контроля версий также крайне желательно придерживаться некоторых правил, чтобы не замусорить проект и быть уверенным в коде, что находится на "боевом окружении"
Аплодирую стоя за "Работа с клиентской частью в Битрикс, мягко говоря, немного отстает от современных реалий веб разработки" Это ж сколько раз пришлось переписать эту строку удаляя маты)
Беликов Олег, так тут encore, который является обёрткой над вебпаком. Всё с этим нормально. Зачем там cli-webpack? Это уже частный случай. Там можно сказать, что нужен реакт/angular/ember/preact и т.п.
Kryachek Mikhail написал: В плане велосипеда для универсальных getter и dispatch, ибо управление\использование state на прямую хоть и можно, но, имхо, не самая лучшая идея
Но есть же Vuex. Чем он вам не нравится? нормальный стор с геттерами, мутациями, действиями.
Так про Vuex речь и идет. И еще раз, если стор описан НЕ вами, то у вас остается только 2 варианта 1) работать со state напрямую 2) добавлять свои модули со своими геттерами и и действиями Либо разработчику решения сотворить костыль и сделать set действие и get геттер, для манипулирования состояниями.
Так про Vuex речь и идет. И еще раз, если store описан НЕ вами и пробрасывается автоматически, что собственно в текущей реализации будет удобно, то у вас остается только 2 варианта: 1) работать со state напрямую 2) добавлять свои модули со своими геттерами и и действиями Либо разработчику решения сотворить костыль и сделать централизованные set действие и get геттер, для манипулирования состояниями.
Я так понял вы версионируете публичные части сайтов. Расскажите пожалуйста, сталкиваетесь ли вы с какими нибудь проблемами из-за этого и как их решаете? Например кто-нибудь через виз.редактор добавляет статическую страницу/каталог, или меняет параметр компонента на странице.
Крюков Валерий, вы так делаете перед каждым деплоем? Вручную, или как-то автоматизировали этот процесс? И если если не закоммитили "продуктивные" изменения, то деплой их затрёт, верно? Точнее не затрёт, а в новом билде их не будет.
Они запускаются автоматически в начале каждого деплоя, либо вручную если нет необходимости в деплое.
Сейчас все построено так, что если эти изменения есть, то деплой просто не сработает (если не закомментировать соответствующие проверки в скрипте)
Здесь конечно надо добавить какой-нибудь флаг, который бы позволял пропускать эту проверку, если изменения на продуктиве можно/нужно игнорировать. В этом случае в новом релизе не будет этих изменений.
Гаврилов Евгений написал: Правильно ли я понимаю, что все vue-компоненты грузятся сразу без ленивой подгрузки? Т.е. на главной странице я получу js корзины и оформления заказа? Возможно, это стоило как-то разделить на бандлы. Иначе грузить несколько мегабайтов js просто зайдя на главную или перейдя из поиска на карточку товара нет никакого желания. С таким подходом пользователь до корзины то и не дойдёт.
Запоздалый ответ, но тем не менее.
В Wepack (а в скором времени и в спецификации ECMAScript) есть замечательная возможность динамического подключения модулей. Совсем недавно она была добавлена и в наш проект.
При сборке Вебпак вытащит код компонента в отдельный "чанк"
И данный модуль будет загружен только, когда VueInvoker найдет на странице подходящий контейнер для динамического элемента
Тоже самое касается "модулей-роутов".
Если вы решите использовать данный подход к разделению кода на модули и захотите загружать некоторые (или все) "роуты" только когда в body есть подходящий класс, то нужно использовать похожий механизм подключения:
Можете, для мамонтов, расписать требования к серверу и окружению? Пока опытным путём вижу что для работы Битрикса на этой сборке нужен php >=7.1.3, установленный composer и node, но неизвестно что ещё не заведётся.
у меня всегда только один вопрос - "а нахрена?") Поясню.
В 2014-м году, мы делали сайтец, все дофига быстро, данные на странице динамические где нужно (аяксы или пуш/пуллы), а сайт сделан за пару недель с нуля. Не требуется никаких билдов, сборок, зависимостей, дорогих разработчиков - два битриксовых "фуллстека". Сайт грузится за 0.9 секунды. Другой пример. В 2016-м году, делали нечто, что потом начали люди называть SPA - но за счёт аяксов, которые грузят что нужно. При этом сохраняется структура страниц на сервере, и нет и не было проблем с индексацией. Опять же, никаких зависимостей, дорогих разработчиков (делал один человек за 10 дней), сайт грузится за 0.7 секунды, потом "переходы по страницам" происходят за примерно 0.4 секунды.
И вот сейчас, 2024-й год, нужно сделать сайт. Нанимаем фронтов-колдунов, бэкендеров-хренендеров, каждый по месяцу возится над своей частью, потом они пытаются все синхронизировать, не билдятся билды, не грузятся зависимости, мелкие правки - через билды, любой чих затягивается на сутки. В итоге миллионы зависимостей, много дорогих разработчиков, сложные технологии. Сайт грузится 0.8 секунд, "переходы" - 0.6 секунд. Вопрос - на кой хрен такой прогресс?)) Стало дольше, дороже, сложнее, ненадежнее.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».