Интерфейсы в i-bem.js

[arikon]

В i-bem.js не хватает интерфейсов. В коде многих блоков обращение ко вложенным блокам (findBlockInside() и тп) идёт по имени вложенного блока. Это ограничивает применение других блоков в качестве составных частей сложных блоков.

Например, в текущих islands тяжело переехать с b-link из bem-bl на link из islands, потому что в коде повсюду используются отсылки на b-link. Заменим в коде блоков на link, и сломается код сервисов, потому что в bemjson останется b-link, с которым js блоков уже не работает.

Здесь помогла бы концепция интерфейса из ОПП. Или базового класса / блока.

В качестве иллюстрации. Вместо:

{
    method: function() {
        var trigger = this.findBlockInside('button');
        trigger.on('click', function() {});
    }
}

такой код:

{
    method: function() {
        var trigger = this.elem('trigger')
            .findInterfaceImplementation('clickable-interface');
        trigger.on('click', function() {});
    }
}

или такой:

{
    method: function() {
        var trigger = this.elem('trigger')
            .findInstranceOf('button');
        trigger.on('click', function() {});
    }
}

Если коротко, то идея в том, чтобы научиться в i-bem.js находить инстансы блоков не только по конкретному имени блока, а по имени его интерфейсов или родителей.

/cc @dfilatov @veged @narqo @mishanga

[arikon]

/cc @SevInf @cody-

[narqo]

[..] Здесь помогла бы концепция интерфейса из ОПП. Или базового класса / блока.

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

[arikon]

@narqo При этом многие блоки переносили из romochka as is. Ну да бог с ним. Этот пример не единственный. Представь любую ситуацию, когда тебе нужно использовать блок, реализующий такую же функциональность, но другой — либо расширяющий существующий блок, либо переписанный с нуля (например, новая версия блока или блок-адаптек вокруг контрола из произвольной внешней библиотеки). Единственный способ сейчас использовать какой-то свой блок — сделать модификатор для существующего блока.

[SevInf]

В качестве еще одного примера, где это было бы полезно можно привести dropdown@v2.

Сейчас в качестве switcher можно использовать блоки button и link. По факту, от свитчера нужно только одна вещь - триггер события click. Чисто теоретически, любой блок, который это умеет мог бы выступать открывашкой попапа. Но в действительности, если мы хотим использовать что-то кроме кнопки или ссылки, мы должны будем написать свой модфикатор к dropdown со своим js и bemhtml. При наличии интерфейса clickable любой реализующий его блок мог бы использоваться внутри dropdown без каких либо модификаций.

[dfilatov]

@arikon У тебя есть понимание каким образом быстро в DOMе находить интерфейсы, в особенности родителькие?

@sevinf А если завтра мне понадобится чтобы появилась версия дропдауна, которая не по клику открывается, а, допустим, по ховеру? Как мне поможет clickable? Сейчас же можно сделать привязку к любому поведению. На самом деле, у нас есть была идея как сделать "открываться по любому BEM-событию click внутри свитчера". Без live-инициализации это и сейчас можно сделать. Но с live там есть некоторые издержки производительности и мы пошли по более явному пути.

Что касается dropdownа из v2. Специфичный bemhtml для модификаторов там требуется только ради шоткатов и обеспечения проброса модификаторов. В случае clickable вообще непонятно кому и куда этот код написать. Без учета этого, для добавления нового варианта дропдауна там требуется совсем минимум кода, что, собственно, видно на примере линка: https://github.com/bem/bem-components/blob/issues/228%40v2/common.blocks/dropdown/_switcher/dropdown_switcher_link.js

[narqo]

При наличии интерфейса clickable любой реализующий его блок мог бы использоваться внутри dropdown без каких либо модификаций.

Я понимаю идею в целом, но: затраты которые нужно приложить, чтобы «мой блок» удовлетворял интерфейсу нужному для дропдауна (ведь не факт, что я думал использовать его там), не кажутся ощутимо меньше, чем написать модификатор для дропдауна.

[SevInf]

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

• все, по чему можно кликнуть с каким-либо видимым результатом должно реализовывать clickable.
• все, что может получить фокус - focusable
• все, у чего есть тема - themable

и так далее.

@dfilatov, для добавления модификатора нужно все-таки, хоть и минимально, понимать внутренности блока. Наличие интерфейса бы позволило вообще об этом не задумываться и устанавливать в switcher, все на что можно кликнуть.

Проброс модификаторов, кажется, можно сделать в bemhtml самого блока. Если свитчер понимает модификатор size - прокидываем size, если понимает disabled - прокидываем disabled.

Сделать открытие поhover clickable никак не поможет - но возможность переопределить блок и привязаться к любому поведению он не отнимает.

[dfilatov]

давайте соберем встречу и поговорим об этом голосом

[veged]

много обсуждали и пока остаёмся при мнении, что это не нужно

[qfox]

По-моему, это перекликается с уже имеющимся функционалом declMix, baseMix.

Недавно хотелось найти все блоки внутри, наследованные от control.