bemtree генерирует входные данные для bemhtml. данные от вашего сервера попадают в bemtree, на выходе получается bemjson bemjson попадает в bemhtml, на выходе получается html Есть альтернативные технологии, например, sbmaxx/bem-priv

1) Без bemtree не будет возможности автогенерации bemjson в синтаксисе bemhtml, а значит придется собирать его руками; 2) Либо же, если перенести логику bemtree на уровень bh/bemhtml — deps будет разрастаться, и потеряется гибкость шаблонов блоков.

Основная мысль в том, что bemjson нужен как есть, он максимально логично и полно отражает структуру страницы в БЭМ-терминах, а значит вариант (2) не возможен, а вариант (1) руками делать не хочется => нужен bemtree или аналог. Как аналог был priv.js — можно поискать причины его появления. Для bh сейчас есть идея использовать processBemJson как вариант bemtree, с отдельным набором матчеров — оно получится немного беднее, но главное, что будет возможность на выходе иметь bemjson, и значит иметь т.н. poor-man аналог bemtree, но на чистом js без необходимости сборки (bemtree/bemhtml требуют компиляции xjst).

Надеюсь, общий смысл ясен ;-)

По сути bemtree - это нормализация данных? Его синтаксис очень похож на bemhtml, что вызывает некую непонятность.

Без bemtree вообще можно обойтись?

@zxqfox bemtree/bemhtml не требуют никакой компиляции в dev режиме

@belozyorcev Наоборот, bemtree и аналоги - это денормализация данных.

Можно обойтись без bemtree, собирая bemjson из входных данных любым другим способом.

По сути bemtree - это нормализация данных?

@belozyorcev Смотря что вкладывать в процесс нормализации. На мой взгляд этот термин не полно отражает смысл, скорее это сборка bemjson из сырых данных.

Его синтаксис очень похож на bemhtml, что вызывает некую непонятность.

Это так задумано ;-)

Без bemtree вообще можно обойтись?

Можно, конечно, но в любом случае bemjson собирать нужно, и в этом случае будет изобретаться свой велописед. bemtree не идеален, но ничего лучше я пока не видел ;-) И если бы оно появилось в открытом доступе — здесь про это бы говорили.

@apsavin dev режим до сих пор unstable, не считается ;-)

@zxqfox

Смотря что вкладывать в процесс нормализации. На мой взгляд этот термин не полно отражает смысл, скорее это сборка bemjson из сырых данных.

да. Именно это и хотел сказать :)

@zxqfox не замечаю никакой нестабильности. На аналог bemtree я выше дал ссылку. Это уже к "здесь про это бы говорили"

@apsavin Есть некоторые несовместимости при использовании упрощенного синтаксиса, из-за которой одни и те же шаблоны в dev режиме просто не работали. Я давно туда не лез, так что возможно уже либо запретили, либо исправили. Не уверен. Но в продакшн режиме bemxjst явно стабильнее.

@zxqfox были проблемы раньше, да, сейчас синтаксис стал более строгим.

@zxqfox А как ты генерируешь bemjson для bh.php?

@kompolom Ну пока руками. В самом большом проекте мы используем смарти, и только пытаемся съехать на bh.php.

Сейчас генерируем (либо модифицием) входное из админки дерево руками в «модулях», которые отрабатывают для разных типов страниц. Типы страниц (условно p-*) имеют свои шаблоны, и свой пхп код. Сейчас они лежат отдельно от блоков, и хотим усовершенствовать этот процесс.

Можно, например, запускать в контексте объекта класса BlocksLayout (или типа того), условно, файл m-layout.bemphp (в блоке m-layout, где layout — тип лайаута страницы):

<?php
return [
  'block' => 'page',
  'styles' => '{{assets:styles}}', // стили и скрипты собираются в рантайме
  'javascripts' => ...,
  'content' => [
    // передаем во внутрениий блок, где something — тип страницы,
    // и p-something — его блок
    'block' => 'p-something',
  ]
];

Дальше отрабатывает такой же файл для каждого из content (в данном случае блока p-something) и идем глубже, по аналогии с bemtree.

Мы не хотим разбрасываться такими вещами, потому что их сложно кешировать тонко, и эти bemphp в p-* часто будут содержать что-то типа $this->layout->getContent(), который генерируется полуавтоматически в админке.

Что будет дальше — возможно, вместо таких файлов сделаем что-то вроде prebh.php, в котором напишем матчеров для bh.php, и будем запускать processBemJson с сырыми данными. Но тут надо и прибраться в блоках проекта, и желательно, чтобы не уходить далеко в сторону, реализовать это в bh.js.

А bemjson у вас настоящий (js), или создаете аналогичную структуру на php массивах?

@kompolom На пхп. У нас это, т.н. BEMContent, у которого есть ->traverse и ->map, позволяющие бегать по нему и модифицировать. ;-) Но мы от этого хотим уйти, потому что не очень быстро. И очень громоско

Я вот тоже задался вопросом. При изучении BEM-стека я предпочёл использовать BH. Начал эксперементировать и даже делать компоненты. Один сейчас на ревью в конкурсе от Яндекса. Сейчас есть возможность внедрить такой подход к созданию компонентов на уровне компании. И вот пока я не зашёл слишком далеко (у меня в разработке ещё 2-3 аналогичных компонента), хочу посоветоваться с вами. Дело в том, что мои компоненты, в отличие от bem-components, на вход ожидают данные в нормализованном виде. У меня возник страх, что я могу получить определённую долю гемороя из-за того, что я все преобразования data-bemjson-html по сути выполняю в одном наборе bh шаблонов.

Чем мне это грозит? Должен ли я срочно перейти на связку bemhtml+bemtree?

@Guria "срочно" ничего делать не нужно) Переходите или на bemhtml + bemtree, или на bh + priv.js Реализация priv.js может быть очень разной, если не хотите пилить сами - выше ссылка на готовую. Сложнее переиспользовать блоки, если формат данных, который ним приходит, зашит прямо в шаблоны.

@Guria, вот то-то и у меня

Посмотрим что ещё скажет @tadatuta после ревью :)

@Guria, а ты все вложенные блоки подключаешь через deps.js ? Используя такой подход.

Кто-то уже подключал bempriv.js ? Можете подсказать, что для этого нужно?