Skip to content

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

Closed
arikon opened this Issue Feb 14, 2014 · 10 comments

6 participants

@arikon
BEM member
arikon commented Feb 14, 2014

В 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
BEM member
arikon commented Feb 14, 2014
@narqo
BEM member
narqo commented Feb 14, 2014

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

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

@arikon
BEM member
arikon commented Feb 14, 2014

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

@SevInf
BEM member
SevInf commented Feb 15, 2014

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

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

@dfilatov
BEM member

@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
BEM member
narqo commented Feb 15, 2014

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

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

@SevInf
BEM member
SevInf commented Feb 15, 2014

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

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

и так далее.

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

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

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

@dfilatov
BEM member

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

@veged
BEM member
veged commented Jan 29, 2015

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

@veged veged closed this Jan 29, 2015
@veged veged added the question label Jan 29, 2015
@zxqfox
BEM member
zxqfox commented Jan 29, 2015

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.