Организация блоков в пределах уровня

[lilliputten]

Существует ли (рассматривается ли) способ организации блоков в рамках одного уровня переопреледния?

Как пример можно рассматривать ситуацию, когда имеется некоторая (предположим) сущность "Report" и все имеющие к ней отношение блоки удобно было бы хранить в одной папке. Поначалу пытался для таких ситуаций использовать отдельные уровни (создаём уровень blocks/Report, в котором храним всё, имеющее отношение к "Report"), но это получается как-то вне концепции и вообще дичь.

Т.е.: возможна ли не плоская, а древовидная структура папок для блоков внутри уровня?

[tadatuta]

В теории структура папок может быть совершенно произвольной (до тех пор, пока принцип можно формализовать в виде схемы для https://github.com/bem-sdk/bem-fs-scheme.

На практике же bem-fs-scheme на данный момент поддерживается в сборке на gulp и в мире bem-react-core. А в ENB все еще не внедрена, так что быстро взять и задать нужную схему в конфиге ENB не получится, но мы бы не отказались от помощи по внедрению туда bem-fs-scheme ;)

[lilliputten]

@tadatuta, вернусь к этой теме, до сих как-то не даёт покоя, но и к.-то новой информации не появляется (пробовал задать вопрос перед последним bemup, но как-то не прошло). Можно как-то пояснить, каким образом возможно организовать схему хранения компонент (блоков) с группировкой в иерархической древовидной файловой структуре? Имеется в виду группировка сущностей внутри одного уровня переопределений. Напр.: g1/g2/b1/__e1/_m1/, где g* -- произвольного уровня вложенности папки, отражающие взаимосвязь блоков. Это возможно в рамках существующего bem-fs-scheme или потребуется слегка его поломать? Ломать именно его или лучше в bem/sdk.walk?

[tadatuta]

Хорошая новость: мы продвинулись в плане внедрения bem-sdk в ENB и сейчас есть альфа-версия.

Плохая новость: bem-fs-scheme был объявлен устаревшим в пользу https://github.com/bem/bem-sdk/tree/master/packages/naming.cell.stringify + не готового еще bem/bem-sdk#281

Если резюмировать: прямо сейчас нужно приложить достаточно много усилий, чтобы построить такую схему. Если есть желание и силы, можно, например, помочь с покрытием тестами в bem/bem-sdk#281 (по аналогии с соседними пакетами в bem-sdk).

[qfox]

bem-fs-scheme просто не нужен).
В walk решили делать такое bem/bem-sdk#282, могу детали рассказать, если интересно, свет в конце тоннеля виден.

bem/bem-sdk#281 тоже нужна, блокер для закрытия bem/bem-sdk#282

[lilliputten]

@zxqfox Если правильно понял, может быть что-то вроде pattern: '.*/${entity}/${tech}'... -- где допускается один (как минимум?) "лишний" уровень для группировки? Не уверен, но что-то мне подсказывает, что более гибкая схема (произвольный уровень вложенности, типа '(.*/)*${entity}/${tech}') может уже отлавливаться с трудом?

[qfox]

@lilliputten да, и не надо такое искать, это слишком медленно. Для таких случаев удобнее явно указать массивом, или даже маской, пути к папкам (уровням), где лежат сущности по какому-то набору правил — соглашению. При чем, в схему мы решили унести и common/desktop/touch, чтобы не было проблем с {common,desktop,touch}.blocks/....

В bem/bem-sdk#281 приехало рабочее обновление, можно даже смотреть.
Осталось пройти ревью и можно будет внедрять в walk.