этим должен заниматься application state manager - выберите любой и используйте
верстка не должна заниматься логикой приложения

Спасибо

Привет всем. Есть вопрос по классическому стеку, конкретно i-bem.js, да и в целом по методологии.
У меня в приложении есть блок "steps", отвечающий за поэтапный ввод пользователем каких-либо данных. Например, есть регистрация в 3 шага: на 1-м пользователь вводит логин, почту и пароль, на 2-м дополнительные данные, и на 3-м вылезает капча. Шаги представлены элементами "steps__item", на которые примиксованы 2 блока "form" и блок "capcha" соответственно.
Итак, задача элемента "steps__item" - отловить успешный ввод пользователем данных и сгенерировать событие "done". Далее его отловит "steps" и что-то с этим сделает. Блок "form" при успехе генерирует событие "success", а блок "capcha" - "correct". Очевидно, это простой пример, в реальности может быть больше вариантов "шагов".
Если я буду проверять миксы и ловить все эти события напрямую в "steps__item", мне придется указывать в его зависимостях все допустимые блоки. В таком случае, даже если в итоге блок "capcha" не будет использован нигде в приложении, он будет включен в сборку.
Другой вариант - дергать "steps__item" из самих блоков "form" и "capcha". Как по мне - это еще хуже, ведь по сути мы добавляем в реализацию этих блоков код для работы с левым элементом, не относящимся к ним напрямую. И опять же, есть куча случаев использования этих блоков вне "steps".
Третий вариант, который мне кажется наиболее адекватным - использовать под каждый микс модификатор элемента, например "steps__item_type_form" для "form", и "steps__item_type_capcha" для "capcha". И в этих модификаторах описывать специфику взаимодействия с тем или иным примиксованным блоком. Опять же, данный вариант не идеален, т.к. модификатор как-будто кажется "лишним".
Так что вопрос к знатокам: как лучше решить данную задачу? Какие еще могут быть варианты?

модификаторы эти не «лишние» — они как раз и выражают специфику блока steps в разных случаях

ещё можно бросать события в какой-нибудь канал, либо в виде вышестоящего блока (например page), либо через события на классе — https://ru.bem.info/technologies/classic/i-bem/events/

А разве бросать события в "page" != делать блок зависимым от контекста? Ту же самую проблему я вижу в своем втором варианте. Блок ничего не должен знать о вышестоящем блоке, будь то "steps" или "page".
А события на классе - это как? Может я слепой, но ничего подобного в документации не описано. Там есть только события на экземпляре.

ну если считать, что page есть всегда, то это терпимое нарушение

из класса https://ru.bem.info/technologies/classic/i-bem/events/#%D0%B8%D0%B7-%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%B0-1

но я бы делал через модификаторы

Так это подписка из класса, про это я в курсе. Не совсем понимаю, как это мне поможет.

можно взять какой-то класс, вместо лукапа наверх до page

Короче ладно, мне это в любом случае не особо подходит. Буду использовать модификаторы.

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

Я хочу сделать анимацию нажатия кнопки, что бы она прыгала при нажатии. Но очевидно что это может быть нужно не всем. При этом, я не хочу добавлять модификатор, потому что это абсолютная мелочь и таких мелочей может быть например 5-10 и это чисто визуальная деталь которую пользователь может либо включить в сборку, либо нет.

Есть ли у БЭМ какие-то предложения как это можно поставлять пользователю, кроме варианта с привязкой к модификатору?

По большому счёту, меня просто отталкивает то, что на кнопке будет 10 модификаторов с длинными именами. В этом нет проблемы, но мне просто не нравится что у самого примитивного элемента может быть из коробки 10 только своих классов которые не делают ничего, а только добавляют внешние изменения.

Мб вы используете какую-нибудь сущность типо Button.extends, куда складываете опционально применяемые для сборки глобальные для компонента стили?

Типо ButtonPressAnimation.css содержащий

.Button:active {
  color: red;
}

Пример, когда у Текстового блока 7 модификаторов с рядом значений, которые меняют только его внешний вид https://www.notion.so/dbe76fd23ef84eaa89e10524bae09041 На практике достаточно гибко и удобно! http://wtpr.wiki

.Button:active {
  color: red;
}

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

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

если вариации не встречаются на одной странице, а нужно просто уметь для разных страниц собирать разный css, то можно в файлах с неймингом для модификаторов писать стили на основной блок — тогда после сборки один класс блока будет сразу всё нести

Что ты имеешь в виду под "в файлах с неймингом для модификаторов писать стили на основной блок"?

Это модификаторы содержащие смысл. Размер, отступы, название стиля.

А я говорю о сущностях описывающих что-то очень конкретное, которые применяются всегда или никогда.

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

По-моему это преждевременная оптимизация, я бы не парился так сильно насчет десятка лишних строк css на проекте, как правило это очень хорошо сжимается gzip/brotli т.к. набор словаря будет не таким большим

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

Все остальное это придумывание и работа ради работы