Существует ли (рассматривается ли) способ организации блоков в рамках одного уровня переопреледния?
Как пример можно рассматривать ситуацию, когда имеется некоторая (предположим) сущность "Report" и все имеющие к ней отношение блоки удобно было бы хранить в одной папке. Поначалу пытался для таких ситуаций использовать отдельные уровни (создаём уровень blocks/Report, в котором храним всё, имеющее отношение к "Report"), но это получается как-то вне концепции и вообще дичь.
Т.е.: возможна ли не плоская, а древовидная структура папок для блоков внутри уровня?
В теории структура папок может быть совершенно произвольной (до тех пор, пока принцип можно формализовать в виде схемы для https://github.com/bem-sdk/bem-fs-scheme.
На практике же
bem-fs-schemeна данный момент поддерживается в сборке наgulpи в миреbem-react-core. А вENBвсе еще не внедрена, так что быстро взять и задать нужную схему в конфиге ENB не получится, но мы бы не отказались от помощи по внедрению тудаbem-fs-scheme;)@tadatuta, вернусь к этой теме, до сих как-то не даёт покоя, но и к.-то новой информации не появляется (пробовал задать вопрос перед последним bemup, но как-то не прошло). Можно как-то пояснить, каким образом возможно организовать схему хранения компонент (блоков) с группировкой в иерархической древовидной файловой структуре? Имеется в виду группировка сущностей внутри одного уровня переопределений. Напр.:
g1/g2/b1/__e1/_m1/, гдеg*-- произвольного уровня вложенности папки, отражающие взаимосвязь блоков. Это возможно в рамках существующего bem-fs-scheme или потребуется слегка его поломать? Ломать именно его или лучше в bem/sdk.walk?Хорошая новость: мы продвинулись в плане внедрения bem-sdk в ENB и сейчас есть альфа-версия.
Плохая новость:
bem-fs-schemeбыл объявлен устаревшим в пользу https://github.com/bem/bem-sdk/tree/master/packages/naming.cell.stringify + не готового еще https://github.com/bem/bem-sdk/pull/281Если резюмировать: прямо сейчас нужно приложить достаточно много усилий, чтобы построить такую схему. Если есть желание и силы, можно, например, помочь с покрытием тестами в https://github.com/bem/bem-sdk/pull/281 (по аналогии с соседними пакетами в bem-sdk).
bem-fs-schemeпросто не нужен). Вwalkрешили делать такое https://github.com/bem/bem-sdk/issues/282, могу детали рассказать, если интересно, свет в конце тоннеля виден.https://github.com/bem/bem-sdk/issues/281 тоже нужна, блокер для закрытия https://github.com/bem/bem-sdk/issues/282
@zxqfox Если правильно понял, может быть что-то вроде
pattern: '.*/${entity}/${tech}'...-- где допускается один (как минимум?) "лишний" уровень для группировки? Не уверен, но что-то мне подсказывает, что более гибкая схема (произвольный уровень вложенности, типа'(.*/)*${entity}/${tech}') может уже отлавливаться с трудом?@lilliputten да, и не надо такое искать, это слишком медленно. Для таких случаев удобнее явно указать массивом, или даже маской, пути к папкам (уровням), где лежат сущности по какому-то набору правил — соглашению. При чем, в схему мы решили унести и common/desktop/touch, чтобы не было проблем с
{common,desktop,touch}.blocks/....В https://github.com/bem/bem-sdk/pull/281 приехало рабочее обновление, можно даже смотреть. Осталось пройти ревью и можно будет внедрять в
walk.