Модульная сборка, терминология

Форум /

Есть такая страничка, заявляющая, что она раскрывает смысл терминов Блок, Элемент, Модификатор. https://ru.bem.info/method/definitions/ Но, во-первых, нет конкретного определения, и, во-вторых, ничего не говорится про технологии, реализации, и другие важные при разработке сборки части.

Надо бы определиться с терминологией и определениями, чтобы можно было двигаться дальше. Подсобите, пожалуйста.

БЭМ — акроним Блок-Элемент-Модификатор;
Блок — ключевая самодостаточная сущность, описываемая набором реализаций (обычно, набор файлов и папок в папке блока);
Элемент — вспомогательная сущность, составная часть блока, описываемая аналогично блоку, которая имеет ровно один родительский блок, и не может использовать вне его контекста;
БЭМ-сущность — это определение содержания страницы или сущность в БЭМ-предметной области: блок ИЛИ элемент со всеми его состояниями (модификаторами);
БЭМ-предметная область — предметная область, описывающая все возможные варианты БЭМ-сущностей, их свойств, и отношений между ними;
Методология БЭМ — это набор паттернов и способ описывать действительность при помощи кода и размышлять о БЭМ-сущностях вне зависимости от того, на каком языке программирования реализуется проект;
Модификатор — состояние БЭМ-сущности, описываемое реализациями аналогично БЭМ-сущностям, может иметь строго одно строковое или булевое значение, не может как использоваться отдельно от БЭМ-сущности, так и считаться отедльной БЭМ-сущностью, поскольку является его состоянием (часть целого не может быть целым, если целое состоит не только из этой части);
Уровень — набор реализаций БЭМ-сущностей (обычно, набор папок с блоками и их внутренней структурой с элементами и модификаторами);
Библиотека — набор уровней;
Реализация (в технологии) — функциональная часть БЭМ-сущности, описанная в рамках конкретной технологии файлом или папкой с набором файлов;
Технология (tech, technology) — набор процессов для преобразования исходных файлов в целевой продукт (материалов в изделие, результат работы процессов, см. wiki: Технология);
БЭМ-технология — технология, применимая к БЭМ-сущностям;
Технология сборки — процесс преобразования реализаций блоков, используемый инструментами для сборки (обычно, модуль или набор , stateful?);
Технологии борщика — технология, реализуемая js-файлами, используемая инструментом borschik;
Цель (сборка) — результат работы технологии сборки;
Зависимость — способ включения в сборку сущности или её состояний других сущностей или состояний;
Зависимость по БЭМ-технологии — зависимость, используемая в случае сборки определенной БЭМ-технология (верно?);
Бандл (сборка) — это набор реализаций сущностей, описанный некоторой специальной реализацией (точкой входа для сборщика с набором сущностей, обычно, в виде реализации технологии bemdecl.js или bemjson.js), и некоторое кол-во собранных целей на выходе, а также способный включать в себя дополнительные уровни;
Merged-бандл — частный случай бандла, включающий в себя сборку всех используемых наборов сущностей и их состояний со всех бандлов;
Dist-бандл — частный случай бандла, включающий в себя сборку всех доступных БЭМ-сущностей, обычно используется для сборки библиотек;
JS-бандл — целевой файл бандла с реализацией JS;
CSS-бандл — целевой файл бандла с реализацией CSS (?, противоречит JS-бандлу, где в сборку включаются еще и шаблоны, и стили);
JS-бандл (путаница, может mixed-бандл?) — цель специальной технологии, результат которой содержит в себе CSS, JS и шаблоны, поставляемая в виде одного файла технологии JS.

Off-topic. А еще вот такое хочу:

  // возвращаем первое удачно разрешенное
  target('bemdecl', oneOf(
    // либо грузим файл `{level.path}/{bundle.name}/{bundle.name}.bemdecl.js`
    fs.provide('bemdecl.js'),
    // либо пытаемся загрузить bemjson.js и собрать динамически из bemjson.js
    bemjsonToBemdecl(fs.provide('bemjson.js'))
  ));

10 years ago

tadatuta

@zxqfox Мы тут недавно откопали свой старый, но совершенно замечательный сайт. Там есть раздел про определения и, кажется, что он написан гораздо более человеческим языком, чем текущий контент. Так что мы откопаем стюардессу ;)

А про технологии мы даже целый пост опубликовали.

PS: Оффтопик выглядит совсем как поведение по умолчанию в bem-tools ;)

10 years ago

qfox

@tadatuta Ну хорошо, смотрим определение блока:

Некая самостоятельная сущность, кирпичик проекта. Блок содержит информацию о самом себе и может знать о своих детях — элементах блока.

Это, конечно, круто, но это очень неточно. Это скорее рекомендация к применению, нежели определение.

Для человека со стороны это примерно как «Какой-то самодостаточный кирпич, из которого (из одного?!) все собирается». Почему-то про глобальный main.js и main.css вспомнилось и про фреймворки.

Читаем дальше:

Часть блока, которая отвечает за какую-то отдельную функцию. Элементы блока имеют смысл только в рамках своего родителя. Могут быть обязательными и не обязательными.

Часть блока (кирпича) — глина? Отвечает за какую-то отдельную функцию — глина разных сортов? И дальше определение опять кончается и идет подсказка, мол, догадайся сам, что это такое.

Я к чему это. Лаконичного и ёмкого определения для каждой сущности очень нехватает. Это не сложно, но этого нет ;-(

10 years ago

dab

Как мне видится:

блок — единичная, самодостаточная сущность. Максимально независимая от других компонента. Может содержать в себе элементы и другие блоки.
элемент — сущность, не имеющая смысла в отрыве от блока. Может содержать в себе другие элементы и блоки.
модификатор — описание текущего состояния блока или элемента.

Все эти сущности могут быть описаны на файловой системе. В различных реализациях. Например так:

./block/
    ./__element/
        ./block__element.css
        ./block__element.js
        ./block__element.bemhtml
    ./_state/
        ./block_state_true.css
    ./block.css
    ./block.js
    ./block.bemhtml

Реализации возможны любые.

10 years ago

qfox

@dab Про «содержать в себе» — ощущение, что описание сразу про две разные проекции. С одной стороны — Блок может содержать элементы и блоки, с другой — элемент может содержать другие элементы и блоки ;-) Неоднозначтость.

Один модификатор — это одно состояние? Или все модификаторы в сумме — это одно состояние? Стоит ли отразить в определении, что модификаторы могут иметь значение? Что делать с блоками, которые «Один блок — N-дом нод», как там с состояниями?

Пожалуй, еще одно: «могут быть описаны на FS» — это значит, что могут быть описаны иначе? Теоретически, конечно, могут, но на практике я не видел ни одной реализации, чтобы сравнить. Может есть примеры НЕ файлового описания технологий сущностей?

10 years ago

dab

@zxqfox Где ты видишь неоднозначность — я вижу ясность. Блок может содержать и элемент может содержать.

Модификаторы описывают текущее состояние. В распределенном блоке — тоже самое.

Генерируемая в рантайме? Пока не уверен, но допускаю что может быть.

10 years ago

dab

@zxqfox на счет офф-топика — https://github.com/enb-bem/enb-bem-techs/blob/master/techs/bemjson-to-bemdecl.js

10 years ago

qfox

@dab

Где ты видишь неоднозначность — я вижу ясность. Блок может содержать и элемент может содержать.

Ну тогда лучше описать, что любая сущность может содержать любую сущность. Но качество этого содержания несколько отличается от концепции, в которой элемент не может существовать отдельно от блока. Т.е. самодостаточность элемента отсутствует. Неоднозначность тут как раз в определении содержания:

b/
  e/
c/

или

{ block : 'b', contents : { elem : 'e', contents : { block : 'c' } }

Модификаторы описывают текущее состояние. В распределенном блоке — тоже самое.

Тут я спорю не с состояниями, а с точностью определений.

Один модификатор — это описание состояния. А два? Каждый модификатор описывает состояние или они оба описывают одно состояние блока? Т.е. сосотяниЕ или состояниЯ?

Генерируемая в рантайме? Пока не уверен, но допускаю что может быть.

Но меж тем мы продолжаем говорить, что сущности МОГУТ быть описаны на FS. Что однозначно говорит нам, что сущности МОГУТ НЕ БЫТЬ описаны на FS => либо могут вообще не быть описаны, что бред (или нет?), либо могут быть описаны как-то еще, но примеров, похоже, нет ;-(

10 years ago

qfox

на счет офф-топика

Ну там, скорее, про oneOf шла речь. Сейчас сборка падает на «bemjson.js не найдет, паситесь». Либо наоборот, если я от bemdecl бандлы собираю. Т.е. оно меня вынуждает делать разные уровни для сборки разными способами, или явно указывать в пути до бандлов с bemdecl.

10 years ago

dab

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

С какой целью ты приводишь два разных примера:

{
    block : 'b',
    content : 
        { 
           block : 'b',
           elem : 'e', 
        }
},
{ 
    block : 'c' 
}

{
    block : 'b',
    content : 
        { 
           block : 'b',
           elem : 'e', 
           content : 
                { block : 'c' } 
        }
}

10 years ago

qfox

@dab Само слово «содержать» неоднозначно трактуется, потому что блок может иметь (путаница с содержать?) элементы, элемент однозначно имеет родительский блок, но могут когда речь идет о содержать в себе в реализации в bemjson — это так, но это ничего не описывает и только сбивает. Например, блок не может содержать элемент другого блока, если он не вложен в другой блок, потому что элемент не может быть использовать вне контекста блока — а у тебя сказано, что блок может содержать элементы и блоки. Т.е. неоднозначность.

И нигде не сказал что любая сущность может содержать любую.

А разве нет? Если блок может содержать блоки и элементы, и элемент тоже — значит блок или элемент может содержать блоки или элементы, значит сущность может содержать сущность.

upd первый пример был про файловую систему ;-) второй — про bemjson

10 years ago

dab

@zxqfox при всем этом сначала было слово: элемент — сущность, не имеющая смысла в отрыве от блока.

10 years ago

dab

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

Когда ты берешь блок и используешь по назначению в своем проекте — ты наполняешь его содержимым по своему усмотрению. Например в *.bemjson.js.

10 years ago

qfox

@dab Спасибо, принято.

Поправил пачку, определений, добавил про бандлы и технологии. Стало лучше? Может быть засунем в PR в bem-method и обсудим детально?

Ибо: Зако́н то́ждества — закон логики, согласно которому в процессе рассуждения каждое осмысленное выражение (понятие, суждение) должно употребляться в одном и том же смысле. «…иметь не одно значение — значит не иметь ни одного значения; если же у слов нет (определенных) значений, тогда утрачена всякая возможность рассуждать друг с другом, а в действительности — и с самим собой; ибо невозможно ничего мыслить, если не мыслить (каждый раз) что-нибудь одно» © Аристотель, «Метафизика»

А без законов логики науки не бывает.

10 years ago

qfox

Наткнулся на путаницу, в зависимости от контекста: Как отличить блок в bemjson от блока на диске? Решение где-то между блок vs блок и bemjson.js vs уровень (или библиотека).

10 years ago

dab

@zxqfox

Наткнулся на путаницу, в зависимости от контекста: Как отличить блок в bemjson от блока на диске? Решение где-то между блок vs блок и bemjson.js vs уровень (или библиотека).

На мой взгляд, ты все еще смешиваешь реализацию блока и его использование.

10 years ago

qfox

@dab ;-) Ты меня троллируешь, да?

Как назвать блок/элемент в bemjson? Узел в бэм-дереве?

10 years ago

dab

@zxqfox взаимное впечатление.

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

«Не нужно множить сущности без необходимости» ©

10 years ago

qfox

@dab Сущности у нас две: блок и элемент. Верно? Других сущностей я не нашел, буду рад, если ты меня поправишь.

Для меня разница между блоком и узлом в БЭМ-дереве такая же, как и между тэгом и дом-нодой.

Кстати, BEM-node норм? ;-) Все тот же узел в БЭМ-дереве, но по-буржуйски.

10 years ago

dab

@zxqfox По-сути сущность одна — блок. Все остальное во имя его и для его блага.

10 years ago

qfox

@dab Веру я сомнению не подвергаю ;-) Но если все называть неведомыми «штуками», то получится «штука в штуке делает штуки». Сущности множить не надо, но надо устаканить определения терминов. Если собирать «штуки» в другие «штуки» и в неокрепших головах и в коде будет тоже «штука» под названием «каша», меня это уже года 2 или 3 терзает, и не знаю, почему ты против.

Ты согласен с разницей между тэгом и дом-нодой?

Чтобы оставлять комментарии, необходимо авторизоваться.