Шаблонизация в браузере когда и зачем нужна?

Например если нужно изменить кусок интерфейса, который базируется на пользовательских данных ввода. Отсылать их на сервер и получать оттуда html совсем не всегда выгодно. Отрабатывает максимально быстро, так как шаблон есть функция. Самые долгие накладки на вставке в DOM и рендере стилей браузером.

Возможность частичной сборки и компиляции со статичными html файлами

Можно а) вставить html строкой в шаблон, б) прочитать html нодой при формировании bemjson, в) прочитать html нодой в шаблоне, если сборка на сервере

Документация про сборку

Проще всего взять пример вот отсюда https://github.com/bem/project-stub

Как организовать сборку для дева, прода, лайв

Матчем на env переменные например. Конфиг для enb, тот самый make.js, обычный js модуль. Ты можешь писать внутри него все что тебе необходимо для сборки и не только. Главное правильное задекларировать сборку. Все это есть в примере выше.

Документация про декларацию

Я не уверен, что прям нужно знать) Но коль хочется, то это массив всех используемых блоков, елементов и их модификаторов, используемых в бандле.

Почему и зачем есть BEMHTML и bh, какой для каких ситуаций лучше

Кажется с выходом нового https://github.com/bem/bem-xjst необходимость в BH отпала в принципе. Все действительно так – это просто два шаблонизатора, ты можешь использовать любой из них. Это как сердце ляжет.

Где доки про BEMTREE, когда что лучше использовать

BEMTREE как и BEMHTML не что иное как движок шаблонизации для https://github.com/bem/bem-xjst с той лишь разницей, что первый на выходе имеет bemjson, а второй html. Обычно BEMTREE используют для формирования bemjson, оперируя данными, которые например можно получать с серверного API. После чего полученный bemjson направляется в BEMHTML, а после в браузер. Чтение документации https://github.com/bem/bem-xjst должно сильно помочь в понимании методов внутри шаблонов.

Доки про SASS|LESS| любые модули

Это не так. БЭМ ничего не навязывает, твой стек на то и твой чтобы быть максимально гибким и таким каким ты его хочешь видеть. Бери инструменты такие какие решают именно твою задачу. Вот например библиотека, компонентов, которая использует PostCSS https://github.com/alfa-bank-dev/ui

Шапка, лейаут в общем html

Есть два пути. Первый это положить кусок bemjson отдельно как commonJs модуль и рекварить его в основной bemjson при сборке. Второй это создать компоненты с шаблонами и стилями. Ведь нет никакой разницы моральной между кнопками и шапкой. Пример такого подхода есть по ссылке выше.

Подключение скриптов, стилей, других библиотек.

В большинстве случаев хватает сил на это блока page из https://github.com/bem/bem-core. Для этого у него есть элементы js и css, также параметр head, в который ты можешь передавать что угодно. Кроме того есть параметр scripts, который по умолчанию затащит все что ты ему скажешь в конец body. Вот пример использования https://github.com/bem/project-stub/blob/master/desktop.bundles/index/index.bemjson.js#L5-L10. Кроме всего прочего всегда остается возможность использовать теги style и script внутри шаблонов.

Какие практики бандлов

Бандл это комплексный результат сборки. То есть он может содержать все что ты потребовал в конфиге для сборщика: скрипты, стили, шаблоны, верстку. Все это собирается по той самой декларации. Которая формируется автоматически по bemjson и зависимостям блоков друг от друга. В идеальном мире бандл ты можешь открыть в бразере и увидеть верстку со стилями и скриптами только для этого куска интерфейса. В https://github.com/bem/project-stub именно такие бандлы. В разных ситуациях нужны разные результаты, иногда только css, иногда только шаблоны и тд. Но это тоже бандл.

Борщик

Утилита для минификации стилей и скриптов, а также заморозки статики. Первые два, а иногда и третий можно заменить на любой известный тебе способ. Внутри используется uglify и csso для минификации. Если ты например будешь использовать PostCSS то сможешь вполне заменить borschik, потому что для PostCSS есть плагины и для заморозки статики в том числе.

Всем привет. Присоеденюсь к вопросу номер три.

Project stub - хорошо... но необходимость изменить процесс сборки заводит меня в тупик. Это такой чёрный ящик с документацией в 20 строк и сильным колдовством внутри. Enb сильно отличается от того, что я использовал раньше (или мне так кажется) и я никак не могу его понять. Можно поподробнее как оно работает?

Вообще, у enb довольно подробный README.

Попробую коротенько: enb всегда имеет на вход одну или несколько входных точек(бандлов). Таковой может быть файл bemsjon или bemdecl. В первом случае bemdecl собирается автоматически. Далее enb как и gulp например, имеет последовательный набор плагинов(технологий) для сборки. В общем случае если собираем по bemjson. То сналача собирается список зависимостей deps.js и строиться bemdecl – список всех сущностей. Потом находятся все файлы с шаблонами, клеются в один и компилируются. Далее собираются скрипты по тому же принципу. В скрипты могут быть влиты шаблоны. По факту это обычный конкат. Далее собираются стили. После чего собираем html. Для этого применяются шаблоны на bemjson. Тот самый файл склееных шаблонов вначале на bemjson бандла указанного в качестве входной точки. Собственно это все. В случае со сборкой по bemdecl мы не можем получить html, потому что нет bemjson. Кажется все достаточно просто и работает по тем же принципам. Глобальная разница лишь в том, что enb работает с файлами. К слову webpack работает с ними же.

Но для наибольной полных инструкций можно обратиться к автору сего творения @blond'у ;)

@apsavin, спасибо за ссылку, что-то проглядел. Действительно, хорошая дока. @awinogradov, большое спасибо за ответы. Насчет сборки лейаутов - так и не понял, как лучше организовать, когда есть шапка, в которой меню для может быть разным, контент разный от странице к странице и тд. Мои вопросы вообще были даже больше к тем людям, что собирают доки на bem.info, ведь текст из readme end гораздо информативнее, чем то, что сейчас на сайте. Да и вообще, получается, что информацию надо собирать по крупицам - то там, то сям, не везде информация актуальная. Некоторые моменты можно узнать только после вопроса на форуме или после просмотра лекции.

@lfoma Проблема в том, что в БЭМ очень много велосипедов. Обычно вы решаете, например, внедрить галп - ну и изучаете галп, не проблема. А тут всё своё. Конечно, сложно создать сайт с докой по всему - это всё равно что пытаться создать сайт с докой в принципе по всем web-технологиям, которыми пользуются люди не из мира БЭМ. Поэтому и порог входа кажется большим. Людям сложно один вебпак внедрить бывает, а тут один enb как вебпак + ещё куча всяких технологий.

@apsavin, ну так надо же бороться с велосипедами и высоким порогом входа, путем улучшения документации, ведь в яндексе есть популизаторы БЭМа. Сейчас же, новичку, что бы найти какие-то решения и понять как это вообще все работает - надо приложить изрядную долю фантазии. Из-за неполной осведомленности и появляются свои велосипеды или, что хуже, люди бросают методологию вовсе. В этом посте я хотел не только найти ответы (которые я рано или поздно найду :) ), а обратить внимание разработчиков, что сразу после изучения документации, возникает много вопросов, которые никак не освещены, но не дают начать сборку проекта. Возможно, не все они относятся к методологии напрямую, но без этих знаний, использовать фуллстек БЭма - невозможно.

надо же бороться с велосипедами

@lfoma под "в БЭМ очень много велосипедов" я имел в виду enb, i-bem, ymodules и прочие борщики.

сразу после изучения документации, возникает много вопросов, которые никак не освещены

Авторы bem.info постоянно работают над этим, это заметно. Но, видимо, не хватает рук.

@apsavin, да, работа видна и у меня никаких претензий нет, замечательно, что есть даже то, что есть. Еще очень круто, что все авторы активно отвечают на вопросы и продолжают пилить разные вещи. Если говорить про велосипеды от разработчиков, то их можно пересчитать и описать что для чего нужно. Тем более, если речь идет про основные технологии.

@lfoma, посмотри https://www.youtube.com/watch?v=VD_l1feBwTk, там достаточно подробно рассказано про сборку на ENB.

И отдельно про сборку на основе деклараций с уровнями переопределения есть абстрактный доклад https://events.yandex.ru/lib/talks/3521/

Доки про SASS|LESS| любые модули .... Я часто встречал мнение, что БЭМ - навязывает свой стек

Это не так. БЭМ ничего не навязывает, твой стек на то и твой чтобы быть максимально гибким и таким каким ты его хочешь видеть. Бери инструменты > такие какие решают именно твою задачу. Вот например библиотека, компонентов, которая использует PostCSS https://github.com/alfa-bank-dev/ui

Дико извиняюсь, если глупость скажу но вот например если есть какие-то блоки с файлами стилей на SCSS и есть блоки на Stylys . Как это всё вместе обработать так, чтоб результаты слились в один CSS файл? Плюс не надо забывать, что у нас стандартные блоки есть на CSS.

Enb-css не подходит, т.к. пролетаем с SCSS и Stylus. Enb-sass и enb-stylus соответственно поддерживают scss и styl файлы плюс встроенная поддержка CSS. А как всё вместе-то сделать? Я так думаю, что не спроста enb-sass и enb-stylus имеют поддержку обычного CSS-а - target-то у нас один. И несколько технологий не могут использовать один и тот-же target. Отсюда эти извраты с впиливанием CSS в любую технологию с CSS препроцессором - нужно как-то обрабатывать CSS стандартных компонентов.

Собственно это и называется "Я часто встречал мнение, что БЭМ - навязывает свой стек". Собственно у нас на выбор есть один любой препроцессор + CSS. Кроме-того реально работающими можно считать только enb-css и enb-stylus и может быть отчасти enb-postcss.

Решением могло бы быть что-то типа конвейера как в gulp, но насколько я понял ничего такого в ENB нет (если есть, то ткните кто-нибудь носом - буду благодарен).

Собственно это и называется "Я часто встречал мнение, что БЭМ - навязывает свой стек". Собственно у нас на выбор есть один любой препроцессор + CSS. Кроме-того реально работающими можно считать только enb-css и enb-stylus и может быть отчасти enb-postcss.

В ENB — нет, в gulp-bem-src — есть.

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

А если в gulp-е какие-то грабли вылезут - ещё куда-то переезжать?

Можно ничего не делать и ждать. Бомжи так и делают. Это тоже вариант ;-)

Хмм - ну хоть что-то, хотя проект какой-то полумёртвый.

https://github.com/gulp-bem/gulp-bem-src/commits/specs Последний коммит 5 дней назад и уже мёртвый ;-( Не, так быстро не умирают

@webhive

Собственно у нас на выбор есть один любой препроцессор + CSS

Это не совсем так с двух сторон: Во-первых, если у нас есть библиотека на препроцессоре №1, которая предоставляет какие-то переменные/миксины/что-то еще для использования в проектном коде, то это все в любом случае не будет работать в коде на препроцессоре №2. И наоборот. Так что это в принципе возможно в очень ограниченном виде.

Во-вторых, вполне можно предсобирать стили в CSS еще на этапе библиотек. Так делается, например, в bem-components — исходники там на Stylus, но для пользователей отдается готовый CSS.

В-третьих, нет никаких проблем выразить такие цепочки на ENB. Ровно такая цепочка решает задачу прогона через borschik и минимизацию. Или вот пример того, как собрать цепочку Stylus -> postCSS: https://github.com/tadatuta/enb-bundle-postcss По аналогии ее можно удлинять до бесконечности.

Можно ничего не делать и ждать. Бомжи так и делают. Это тоже вариант ;-)

Не знаю как там бомжи делают - вам наверно виднее. Вот тут https://ru.bem.info/toolbox/ в разделе "Сборка" указано ENB. Я как человек только ещё рассматривающий БЭМ стэк следую рекомендациям авторов и соответственно выбираю в качестве средства сборки ENB .... и довольно быстро натыкаюсь на проблему. И в качестве решения мне предлагают переехать на совершенно иную систему сборки. Ну вы укажите тогда сразу, что ENB не доделан и лучше использовать Gulp или "не ждать" и написать что-то своё.

Последний коммит 5 дней назад и уже мёртвый ;-(

Насчёт полумёртвого - да я погорячился. Такой вывод был сделан глядя на master с одним коммитом 4-х месячной давности, отсутствием внятного описания и статусом build: failed. Но в общем-то я и сейчас не могу его воспринимать, как средство, которому я мог бы доверять.

так быстро не умирают

Ну если быть точным - 4 месяца стагнации и некая активность последние 2 недели. Больше похоже на действие дефибриллятора :)

@tadatuta

В-третьих, нет никаких проблем выразить такие цепочки на ENB. .... Или вот пример того, как собрать цепочку Stylus -> postCSS: https://github.com/tadatuta/enb-bundle-postcss По аналогии ее можно удлинять до бесконечности.

Да вот как-то не получилось у меня. Вариант этот я видел и пробовал. Промежуточный ?.post.css файл у меня создавался (ну т.е. stylus отрабатывал), но дальше postcss его уже не подхватывал. В итоге у меня был файл ?.css в который собирались файлы из стандартных компонентов, а ?.post.css лежал отдельно. Можно конечно их потом смержить в один, но мне кажется тогда порядок подключения стилей нарушится. В общем выглядело это как будто postcss не видел сгенерированные файлы в папке бандла.

Вполне допускаю, что не заработало оно из-за моей криворукости, но вот как-то не получилось. Попытаюсь ещё.

@tadatuta

Вот если вот так вот делать - это правильно?

...
            [techs.stylus, {
                target: '?.stylus.css'
            }],

            [techs.css, {
                sourceSuffixes: ['.stylus.css']
            }],

...

Насколько я понимаю в этом случае techs.stylus создаёт ?.stylus.css, а techs.css должен сожрать этот ?.stylus.css и выплюнуть css Ну и в итоге на выходе получаю нормальный ?.stylus.css``и пустой?.css``

Только что проверил на project-stub-е.

@tadatuta

В-третьих, нет никаких проблем выразить такие цепочки на ENB. .... Или вот пример того, как собрать цепочку Stylus -> postCSS: https://github.com/tadatuta/enb-bundle-postcss По аналогии ее можно удлинять до бесконечности.

Бррр - всё - сдаюсь - не выходит каменный цветок. Борщик да - работает, а вот комбинация enb-css + enb-stylus (просто взял для примера, чтоб проверить) - никак. Так и эдак вертел, местами менял - не работает.

Во-первых, если у нас есть библиотека на препроцессоре №1, которая предоставляет какие-то переменные/миксины/что-то еще для использования в проектном коде, то это все в любом случае не будет работать в коде на препроцессоре №2. И наоборот. Так что это в принципе возможно в очень ограниченном виде.

Это понятно. Собственно как мне кажется набор CSS препроцессоров этот как раз и есть тот самый случай.

Во-вторых, вполне можно предсобирать стили в CSS еще на этапе библиотек. Так делается, например, в bem-components — исходники там на Stylus, но для пользователей отдается готовый CSS.

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

Вот вариант с цепочками как бы самое оно, но чё-то только не работает. Ну и кстати в enb-технологиях заметил какой-то разброд и шатание. Кто-то использует source:, кто-то sources:, кто-то sourceSuffixes:. Борщику например принципиально чтоб был только source:, а вот enb-css только суффиксы подавай.

Начинаю понимать, почему распространение БЭМ так буксует. Я имею в виду полный стэк, а не только CSS нотацию. Всё очень сырое и какое-то недоделанное. Вроде бы типа гибкость и в тоже время вот так вот взять и начать работать не получается - кругом грабли.

комбинация enb-css + enb-stylus

Такая комбинация и не должна работать по этой схеме.

Есть 2 принципиально разных кейсы:

1. Когда у нас на руках куча файлов каждого блока и мы из них собираем бандл (тут на важно знание о том, где лежит исходный файл, чтобы правильно подменить пути к статике и все такое)
2. Когда у нас уже готовый склеенный бандл (например, полученный на предыдущем этапе с помощью [1]) и мы хотим его как-то преобразовать (автопрефиксер, минимизация, вот это все).

Именно отсюда и «разброд и шатание», про которое ты пишешь — source про путь к целому бандлу, а sourceSuffixes — про суффиксы, по которым нужно матчить файлы каждого отдельного блока.

Аналогичное отличие и у https://github.com/awinogradov/enb-postcss VS https://github.com/tadatuta/enb-bundle-postcss — первая собирает каждый отдельный файл блока, вторая — прогоняет через postCSS весь заранее собранный бандл. Судя по твоему предыдущему комментарию, ты использовал именно enb-postcss, поэтому сборка и не взлетела?

Обе технологии enb-css и enb-stylus работают именно по первому принципу и именно по той самой причине, что им важно знать, где изначально лежит исходник. На выходе каждая из них сгенерирует бандл. Дальше результат их работы действительно нужно склеить (например, с помощью https://github.com/enb/enb/blob/master/techs/file-merge.js). Другое дело, что это изначально бессмысленно — enb-stylus умеет все то, что умеет enb-css и ей можно просто скормить массив суффиксов.

А тут мне получается надо каждый раз предварительно предсобирать что-то

Это не что-то эдакое на самом деле. Достаточно добавить в npm scripts (или другой таск раннер, используемый на проекте) команду типа find . -iname '*.styl' | xargs stylus и всего-то делов.

Вроде бы типа гибкость и в тоже время вот так вот взять и начать работать не получается - кругом грабли.

Надеюсь, что на текущие вопросы я ответил (на самом деле все это можно прочитать и в документации на ENB). Если столкнешься с какими-то новыми граблями — обязательно пиши, чтобы у нас была возможность их исправить.

Надеюсь, что на текущие вопросы я ответил

Да - спасибо - про source и суффиксы было действительно познавательно. Довольно не очевидный момент ... по крайней мере для меня.

на самом деле все это можно прочитать и в документации на ENB

Вот это вот зря было сказано :) Я изучение ENB начал прямо с документации по шагам и очень скоро упёрся в то, что примеры из документации не работают, о чём вам уже сообщали (в том числе я) https://github.com/enb/enb/issues/443 . После таких экспериментов желание продолжать чтение пропадает напрочь. Она сама по себе довольно сложна (много новых терминов и концепций), так ещё и видишь, что нифига не работает, код устарел - гарантии, что дока актуальна тоже никакой. Issue про доку игнорится с марта, т.е. это показатель, что или всем наплевать или нет времени этим заниматься. Вот и приходится инфу из форума выковыривать. К слову форум (по моему мнению) более информативен чем любая дока по БЕМ. И это на самом-то деле ненормально. Вы молодцы, что на вопросы быстро отвечаете, но было бы гораздо лучше всю эту информацию действительно черпать из документации, туториалов и т.п.

Достаточно добавить в npm scripts команду и всего-то делов.

Ну костыль же ... Просто для сравнения в Ember или в рельсе я просто ставлю пакет и всё. Можно опционально конфиг создать и чё-то там дотюнить, но и без него всё как правило работает. А с такими костылями проблема одна - через год уже не вспомнишь где чего натыкал. Или новый человек в команду появляется и поехали - да тут добавь, да там допиши. А если автор костыля уже не с нами?

Блин - чем больше ковыряюсь в разных модных фреймворках тем больше люблю рельсу, ведь именно от этого бардака в своё время на неё и убежал. Пока к сожалению ничего более дружелюбного к программисту не встречал. Есть прямой как рельса путь - делай раз, делай два, делай три и всё работает. Есть стандартный набор средств для автоматизации которые работают. Берёшь доку и попёрли - "степ бай степ пока от монитора не ослеп". Занимаешься голым кодингом, а не выворачиваешь мозги как написать скрипт для сборки. Причем никаких ограничений углубиться и разобравться - но только если тебе это действительно нужно.

Ладно - побрюзжал и хватит

Если столкнешься с какими-то новыми граблями — обязательно пиши, чтобы у нас была возможность их исправить.

Да напишу обязательно :)

Аналогичное отличие и у https://github.com/awinogradov/enb-postcss VS https://github.com/tadatuta/enb-bundle-postcss — первая собирает каждый отдельный файл блока, вторая — прогоняет через postCSS весь заранее собранный бандл.

К слову - я ж ведь уже в сорцах успел порыться :) у https://github.com/awinogradov/enb-postcss фактически то файлы мержатся в один а потом вся эта пачка скармливается postcss. Так, что отличия в подходах минимальны - разница только в каком месте это происходит.

Вообще я думаю вот реально не хватает сборки, чтоб разные технологии лили результаты в один target. Допустим scss и stylus в css. Реализация конечно усложнится (технология уже не сможет монопольно обрабатывать список файлов - нужен будет какой-то хитрый диспетчер который каждый файл будет индивидуально обрабатывать своей технологией), но я думаю оно того стоит. Это и CSS касается - библиотеки могут быть без разницы на чём - stylus, scss, sugarss и т.п. и JS - js, coffee, babel.

Т.е. я сейчас не про цепочки - не про последовательную обработку файлов набором технологий, а параллельную обработку разных технологий с общим target-ом. Реальный кейс - вот напел тут автор postcss про нереальное удобство его нового SugarSS - хочу попробовать. А у меня проект на Stylus который имеет встроенную поддержку CSS и третьего не дано. Вроде бы добавить просто технологию и всё - ан нет - надо крутить цепочки и то это не вариант.

Обе технологии enb-css и enb-stylus работают именно по первому принципу ... на выходе каждая из них сгенерирует бандл. Дальше результат их работы действительно нужно склеить

А после склейки у нас порядок не поменяется - я имею в виду уровни переопределения? Т.е. если в одном бандле у меня переопределение, во втором тоже - дальше то я их смержу и переопределения перекроют друг друга (в зависимости от порядка в котором буду мержить). Или мерж умный?