Есть блок post, у него есть элемент <span class="post__action post__create" data-bem='{"post__create": {"url": "/post/create"} }'>Создать</span>.
На post__create навешен обработчик клика. Примерно такой:
_sendCreateRequest: function(e) {
var $target = $(e.target),
params = this.elemParams($target);
$.get(params.url)
.done(function() {});
}
И вот будет этот обработчик работать правильно или нет — зависит от порядка, в котором обявлены элементы на дом-ноде. <span class="post__action post__create"> — не работает, <span class="post__create post__action"> — работает.
И вот вопрос — это косяк в логике блока и так делать ообще не нужно никогда, или всё-таки баг в this.elemParams() и его стоит зарепортить?
Стоит исправить логику. На одной дом-ноде не должно быть двух элементов блока. Представь что будет, когда ты для обоих элементов напишешь шаблоны - что ты будешь ожидать в результате?
На одной дом-ноде вполне может быть два элемента блока, если второй миксуется к первому.
да, при миксе ты можешь добавить элемент другого блока. Но какой смысл в миксе в пределах одного блока?
Точно такой же, как и при миксе 2х блоков на одной ноде.
Банально, если в одном случае кнопку с действием и какой-то индикатор нам надо разделять, а в другом — в одном месте рисовать. В одном случае это две разные дом-ноды, в другом — одна.
Ну и да, добавлю — у нас half-стек, шаблоны на twig/handlebars.
Я, конечно, должен предложить конвертировать twig/handlebars в bh/bh-php ;-)
Давай по-пацански:
У меня в голове сейчас именно такая картинка. Есть блок
a, который у дочернего элемента спрашивает "ты кто?!", а ему отвечают я элементb, но со мной тут еще ребята намиксованы. Т.е. сущность все равно одна, пофиг сколько намиксовано всего. Но должен оставаться кто-то, кто будет "за главного" :)обязан ;)
@sipayRT это нужно для шаблонов, потому что там конфликт интересов, который не придумали как разрешать. Для JS мы легко можем создать столько инстансов, сколько надо, и когда надо, я не вижу проблемы иметь несколько инстансов, привязанных к одной дом-ноде. Равно как и в CSS. И тут, и там главный уже не нужен, главный нужен только для шаблонов.
@sipayRT только вот почему-то ответ на вопрос «кто главный» сделан по принципу — кто «последний, тот и папа» (ну, то есть наоборот, кто первый).
вот у меня в голове именно такой принцип.
я не могу прям сейчас придумать такую ситуацию, которая убедила бы тебя в моей правоте :(
Мне кажется, не важно, стоит смешивать элементы блока на ноде или нет. Важно, что это возможно и что в такой ситуации поведение elemParams как минимум не очевидно/не документировано, как максимум - требует исправления (возможности указать строкой имя элемента для jquery-объекта, например).
elemParams()понимает строку в качестве аргумента (см. https://ru.bem.info/libs/bem-core/v2.7.0/desktop/i-bem/jsdoc/#jsdoc-elemParams-1).bem-core.Достаточно разрешить вызов
this.elemParams(elemName, $jqueryObject)@tadatuta мне хочется для начала понять, насколько bem-way размещать несколько элементов на одной дом-ноде и дёргать для них параметры из
data-bem. Ведь ничто не мешает сделать что-то типа такого:@h4 ничего противоречащего bem-way в нескольких элементах не вижу. Ну и напомню, что в будущей bem-core v3 элементы станут полноправными JS-сущностями и все подобные моменты будут работать изначально правильно.
@apsavin
Когда есть
elemNameв виде строки, то смысл в$jqueryObjectтеряется. Проблема может быть в том, как из$(e.target)вынуть нужныйelemName.@tadatuta смысл не теряется. Никак нельзя автоматом вынуть нужный elemName, так что я предлагаю указывать его явно. Просто строка - ищет элемент по имени в блоке и берет его параметры Строка и jquery элемент - ищет элемент по имени в jquery элементе и берет его параметры jquery элемент - текущая логика. Или вообще запретить возможность такого вызова.
@tadatuta я подумаю на досуге, что можно предпринять.
А какой роадмап у bem-core v3?
@h4 вот майлстоун, но скорее всего он будет еще расширяться. А в терминах дат, к сожалению, пока ничего ответить не смогу :(