Хочу использовать bh.js на клиенте. на сервере используется bh.php. Для сборки используются bem-tools. И что то я никак не соображу как подключить все это в браузер...
Вот так пытаюсь подключить в deps.js блока
({
tech: 'bh',
mustDeps: [
{
tech: 'bh',
}
],
})
По-моему, должно быть как-то так:
Но как по-мне, если таких блоков много, лучше написать merge в make файле сборщика и сливать технологии там.
Спасибо за код. Сейчас попробую.
Вот тут не понял, что это и зачем.
Вот тут есть пример для bemhtml https://github.com/bem/project-stub/blob/bem-core/.enb/make.js#L63-L90
Попробуй так
Спасибо всем за ответы, но все равно bh не доступен на клиенте. я так понимаю что в случае успеха технологию можно будет проверить через
modules.isDefined('bh');?@kompolom чтобы собрать BH на клиент, потребуется соответствующая технология для сборки. Готовой для
bem-tools, кажется, нет, но по смыслу можно:Подробнее про технологии bem-tools можно узнать тут (ориентироваться нужно исключительно на
v2): https://ru.bem.info/tools/bem/bem-tools/tech-modules/Если потребуется помощь — пиши.
Применительно к bh.js шаблоны куда соберутся? в
_index.js?Я пересел на
enbтеперь у меня есть модульbhна клиенте, но нет шаблонов@kompolom какая технология написана в депсах:
bemhtml,bh,bh.js?И какая указана тут https://github.com/bem/project-stub/blob/bem-core/.enb/make.js#L67? Они должны совпадать.
Ещё уточню, что в
bem-coreиbem-componentsвезде указаноbemhtml, поэтому на своём проекте удобнее всего указывать точно так же.Тоесть, в депсах пишу bemhtml, а реально подключастя bh шаблоны?
Да ))
Магия....
Что за треш, зачем так сделали?
Да никто не использует BH просто
Зачем сделали понять можно. Но вот как догадаться простому смертному что для технологии
bhнужно писатьbemhtml...Нет, я не могу понять, зачем так делать, мне кажется, это полная жесть.
Да ну, смешно вроде. У вас просто нет чуства юмора...
Какой нафиг юмор? Как такие вещи ревью проходят?
Да у меня истерика. Я не знаю :fire: :smile_cat:
@tadatuta Что за жесть? ;)))
@apsavin так сделали потому что в клиентском коде исторически был
BEMHTML.apply(). текущее решение позволяет добавить поддержку BH без поломки обратной совместимости.На самом деле в
bem-componentsсейчас нет ни одного блока, которые явно зависят от шаблонизаторов вjsтехнологии. А все зависимости сtech: bemhtmlнаписаны для тестов, поэтому для пользователей нет никакой разницы.Всё так же можно собирать с депсами
tech: bh, но нужно не забывать менять это тут https://github.com/bem/project-stub/blob/bem-core/.enb/make.js#L67, т.к.project-stubне учитывает все варианты.Но, если такие блоки появятся, то в
js-коде будет подключатьсяBEMHTMLмодуль. В зависимостях можно будет прописать иtech: bemhtmlиtech: bh, чтобы работало и так и так. Но BH нужно будет собирать с опциейmimic: 'BEMHTML'.Почему
BEMHTML, а неBH? Потому чтоBHумеет мимикрировать подBEMHTML, аBEMHTMLподBHнет.@tadatuta О какой обратной совместимости речь? Если авторы проекта меняют bemhtml на bh, они в любом случае заморачиваются, ничего страшного, если еще и конфиг сборки поменяют.
@andrewblond Если можно настроить сборку клиентских шаблонов bh, как клиентских шаблонов bh, а не bemhtml - именно так и нужно советовать людям, пожалейте их.
Вообще, если bemhtml в depsByTech может означать "клиентские шаблоны", а не bemhtml - то, наверное, нужно подумать о том, чтобы как-то эту ситуацию обрулить покрасивее.
@apsavin
Речь о том, что у нас есть огромная кодовая база, где в клиентском JS уже было написано
BEMHTML.apply()и мы не можем «просто так взять и» переписать все эти блоки. При этом, учитывая, что шаблоны на BEMHTML и BH на одних и тех же входных данных дают полностью одинаковый результат, дать возможность бесплатно перейти на новый шаблонизатор было можно. Собственно @andrewblond все уже написал выше.@tadatuta но при этом можете "просто так взять и" переписать шаблоны для них на bh?
@apsavin да. это минорное изменение — добавление новой фичи. оно не требует сломать то, что работало.
@apsavin ну и еще раз: для новых проектов нет необходимости делать именно так. эта фича нужна существующим проектам, для которых ее существование понятно и оправдано.
это тот тип девелопмента, когда реалии заставляют писать адовые юзерагенты, чтобы не взрывать сниффинг на кривых регекспах. мы бы рады обладая сегодняшним опытом и заранее зная как все будет, написать сразу хорошо. но возможности не учитывать существующую кодовую базу у нас нет. при этом, вроде как, никто из тех, кто начинает с чистого листа, пострадать не должен был.
Видимо, мне не понять. Как может быть переписывание шаблонов с bemhtml на bh "минорным изменением"? Этого нельзя было сделать исключительно на уровне компании? Если вы сделали костыль для себя, зачем советовать другим им пользоваться? bemhtml - это "какие-то клиентские шаблоны" в зависимостях навсегда? На мой взгляд, когда ты пишешь bemhtml, а собирается bh - это и есть ситуация, когда что-то сломано.
Вижу апдейт, пожалуй, после него самым важным оказывается вопрос, выделенный жирным.
@apsavin
не переписывание, а дописывание рядом. а потом одной строкой в конфиге можно включать то один, то другой. например, сейчас Серп для старых браузеров под кодовым названием Бабуля благодаря наличию 2 полностью идентичных наборов шаблонов позволил на большом реальном проекте с реальной нагрузкой доказать, что скорость выполнения BEMHTML и BH практически одинаковая, хотя на синтетических тестах некоторый разрыв.
текущая реальность такова, что:
как бы ты решил эту задачу, если нужно сохранить обратную совместимость?
Дописывание рядом == переписыванию по трудозатратам.
Ты немного лукавишь, так отвечая на вопрос про советы. Судя по дискуссии выше, вполне можно было объяснить, как настроить новый проект на использование bh, не прибегая к этому хаку.
Разумеется, в описанных тобой условиях задача не разрешима. Но можно: