Возьмём например абстрактный код на любом языке.
Мы ведь можем создать объект класса menu и положить его в конструктор класса select и при этом зависимым будет только select. menu ничего не знает о его пользователе, он знает только о своих зависимостях, например о list.

Что бы select управлял menu, ему нужно просто вызывать его методы.

Вот мне и хотелось бы узнать, как вызывать методы (условно) элементов.

Возможно в бэм-фреймворке вы ассоциируете элементы с картой методов, например через WeakMap.

Да, это реальный вопрос. Как я сказал, я не использую инструменты i-bem, потому что большинство кода который я использую, мне приходится проверять, а на изучение кода всех тулзов bem сейчас нет времени, но идея выглядит очень крутой. Я хочу использовать автономные элементы для вёрстки

тогда советую по диагонали пробежаться по документации — https://ru.bem.info/technologies/classic/i-bem/ — она достаточно лаконичная и там месть ответы на эти вопросы

кратко: да, есть способ явно позвать методы блоков/элементов, пользуясь знаниями об их апи и направление зависимостей можно выстраивать любым способом (а->б, а<-б и а<->б)

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

Тут говорится о БЭМ-событиях https://ru.bem.info/technologies/classic/i-bem/events/
Вы через них отправляете запросы компонентам?

Я только хочу понять как это принято делать. Не в конкретной реализации, а на алгоритмическом уровне.

Сейчас представляю для себя такие варианты:

1. При загрузке страницы инициирую объект, в который складываю все элементы с задекларироваными классами. Декларация представляет собой имя класса и карту его методов bemManager.decl({class: 'menu', methodList:{clearInput: e=>{...}}}). Для вызова метода, передаю элемент (компонент) в менеджер, получаю карту методов и вызываю нужный условно var menu = bemManager.get(menuElm); menu.clearInput().  Декларация поставляется с компонентом и методы (например clearInput) содержат взаимодействие с элементом.

У этого подхода такие недостатки: зависимость от фреймворка, фреймворк обязан следить за обновлением DOM и модифицировать свой список объектов.

2. Для вызова метода, пушу кастомное событие документу CustomEvent('bem-menu', {details: {target: menuElm, action: 'clearInput'}}), все компоненты menu прослушивают это сообщение и делают проверку на то к ним ли это обращение (сравнивают target с собой) и если да, то выполняют метод, если это корректное имя.

Недостатки такие: использование событий для обмена сообщениями, для управления, а не для сообщения о каких-то дейсвиях. Невозможность получения прямого ответа на запрос (хотя можно например передавать коллбэк, который будет выполнять компонент при обработке, но если обрабатывать некому, то и коллбэк вызван не будет)

---

На сколько такие способы взаимодействия близки к эталонной реализации? Первый - это примерно то, что и реализует i-bem? Если нет или не совсем, то опишите схематично, как вы вызываете методы сейчас.

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

Прочитал. Но не нашел описания пункта "с помощью непосредственного вызова методов других экземпляров или статических методов класса".

Этот вариант мне очень подходит. Как это происходит?

через поиск экземпляров блоков/элементов (https://ru.bem.info/technologies/classic/i-bem/dom/#%D0%9F%D0%BE%D0%B8%D1%81%D0%BA-%D1%8D%D0%BA%D0%B7%D0%B5%D0%BC%D0%BF%D0%BB%D1%8F%D1%80%D0%BE%D0%B2-%D0%B1%D0%BB%D0%BE%D0%BA%D0%BE%D0%B2-%D0%B8-%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D0%B2-dom-%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%B5) и явный вызов их методов

т. е. не через get из реестра, а есть апи, которое выдаёт привязанный к дому инстанс нашего класса

А как объекты привязываются к DOM?

Надёюсь мы поняли друг друга правильно, я сейчас прочитал заголовок "Взаимодействие блоков и элементов", это ведь не только о элементах компонента? Это распространяется и на компоненты внутри блоков?

в БЭМ методологии кроме блоков и элементов нет объектов — всё выражается их комбинацией

Значит пункт  "с помощью непосредственного вызова методов других экземпляров или статических методов класса" означает взаимодействие с дочерними элементами независимого блока? Если это так, то я наверное что-то не понимаю. Разве такое взаимодействие не запрещено? Как я понял, бэм требует стандартной инкапсуляции - мы можем взаимодействовать с дочерними элементами независимого блока только через API блока

ковыряться во внутреннем устройстве блока снаружи скорее «не рекомендуется», но на уровне апи не запрещено

"При загрузке страницы в браузере выполняется инициализация блоков. В ходе нее создаются экземпляры блоков — JS-объекты всех блоков, упомянутых в классах HTML-элементов страницы. JS-объект, привязанный к HTML-элементу, обрабатывает происходящие на нем DOM-события и хранит состояния данного экземпляра блока."

Я это представляю так как описал выше в способе №1.
Только объект записывается не в глобальный реестр, как вы и сказали, а манкипатчится вот так: blockElm.myCustomPropertyForStoreMethods = [карта методов]

Правильно?

если вложенность такая:
 а
    б
       ц (и этот ц, это детали реализации б)

то чтобы из а повлиять на ц, в б должно быть выставлено какое-то апи — но для удобства быстрого прототипирования этим апи можно считать прямой доступ к ц из а

не понимаю, почему это важно и в реальности под капотом там немного по другому, но если так проще понимать, то да, семантически примерно так

Я до этого ещё не доходил, но это очень полезное замечание. Но тогда блок б не считается абсолютно автономным? Ведь этот договор о инкапсуляции по сути заменяет закрытый ShadowDOM

да — но наш принцип, что «заборы» нужно иметь на уровне самодисциплины и понимания что за чем используется, а не на уровне апи, которое бы запрещало что-то явно