Нет, потребуется переопределить ближайший «слот», о котором позаботился разработчик при проектировании компонента. Если он заранее догадался, что потребуется менять кнопочку, то можно будет именно ее и переопределить через реестр. Иначе — ближайшего родителя, доступного в реестре.

Подробнее о том, как работает bem-react/di можно посмотреть в докладе verybigman www.youtube.com/watch?v=nhgC_43C38Q

Реализуем их через github.com/bem/bem-react/tree/master/packages/di

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

В целом схема в CI такая:
1. Открытие pull request-а в репозиторий с общим кодом автоматически выпускает canary-версию затронутых пакетов
2. Во все проекты, где используется затронутый пакет, автоматически отправляется pull request с обновлением package.json и package-lock.json до версии, выпущенной в п. 1
3. Эти pull request-ы триггерят запуск тестов в затронутых репозитория
4. Отчеты по этим тестам публикуются в исходный pull request из п. 1. Если там упали обязательные проверки, влиться не получится
5. Если все проверки прошли успешно и разработчик вмержил изменения, автоматически будет выпущена стабильная версия общего пакета, а pull request-ы в проекты обновятся на использование этой стабильной версии. Так что разработчикам останется только их влить.

В Лего сейчас именно так. На проектах — по-разному. Для мира i-bem четкая структура важна, а для Реакта с явными импортами код может лежать как решит каждая конкретная команда и зачастую принимают решение все-таки держать код на Реакте отдельно, но импортировать стили/тесты из тех же desktop.blocks/**

Мы достаточно много экспериментировали с «магической» сборкой, которая также, как и в МАМ, не требовала указания явных импортов. В частности такой подход позволил очень удобно работать с уровнями переопределения. Но сейчас скорее движемся в сторону «явное лучше неявного» и возвращаемся к классическим импортам, которые хотя и заставляют писать больше бойлерплейта, зато делают код более очевидным, не требующим знать о соглашениях, чтобы с ним разобраться.

Стараемся выделять в CommonJS, то, что можно использовать из i-bem и React + используем общие тесты и стили для компонентов.

Конец немного предсказуем. Где-то с середины статьи было такое чувство, что в ней будет раскрыт и этот вопрос. Так и вышло.

Серверный рендеринг позволяет пользователям получать результат быстрее: не тащить на клиент шаблоны, не ждать пока они отработают, а сразу получить готовую HTML-разметку, которую можно начинать отрисовывать в браузере даже еще до того, как она полностью загрузится.

Ну даже не знаю… :)
Я же правильно понимаю, что приведенный сниппет кода должен ярко иллюстрировать ущербность БЭМа?

Она в том, что
1. Среди возможностей есть по-настоящему асинхронная во всех смыслах модульная система, позволяющая при необходимости точечно переопределять любые модули (стоит ли говорить, что ее использование опционально и БЭМ не перестанет быть БЭМом без нее?)
2. Помимо возможности декларативно описать реакцию на изменение модификаторов, можно воспользоваться и соответствующими событиями, которые обладают всеми возможностями нативных событий.
3. При необходимости отменить поведение события по умолчанию, нужно (о мой б-г!) вызвать preventDefault().
4. В hello-world примере не стали задвигать телегу про единый источник истины, докручивать флакс с привкусом редакса и прочие свистелки, которые каждый имеющий голову разработчик выбирает для себя сам и которые не имеют прямого отношению к тем вещам, за которые отвечает БЭМ.

Все верно? Ничего не упустил? :)

Утверждение примерно в духе «с Windows явно что-то не так, и это не только необходимость перезагружаться при установке обновлений, иначе не было бы столько холива».

Тот факт, что про холивары про БЭМ не утихают во фронтенде ТАК долго уже о чем-то да говорит. Сколько технологий родилось, поднялось на волне хайпа и было забыто, пока нас ругают за читабельность кода, а потом пишут комментарии в духе habrahabr.ru/company/htmlacademy/blog/337286/#comment_10428564? ;)

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

Трудно читаемый код с такими длинными классами

Парадокс в том, что читать верстку, написанную с соблюдением БЭМ несравнимо удобнее. Стоит только начать, вернуться назад желания уже не возникнет.

Нет проектов с более, чем 2-мя верстальщиками

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

Дальше все полностью аналогично деплою совершенно типичного сайта на express. В простом случае подойдет какой-нибудь pm2 или аналог, чтобы следить, что процесс жив и добавить его в автозагрузку для переподнятия после рестарта сервера. Плюс мониторинги и прочая безопасность по вкусу.

Ты же знаешь ответ ;)
Зависит от отдела == опыта команды и требований.

Борис, «по ссылкам не ходи @ комментарий пиши»?
Там ровно ноль связи с i-bem и каким-либо легаси ;)

Удивился, если бы увидел завтра статьи на тему — «прощай angular, здравствуй бэм», " бэм vs react", «создателя redux уличили в подготовки покушения на создателя бэм»

На самом деле всё чуть-чуть иначе: БЭМ в симбиозе с React, мастер-класс по внедрению возможностей БЭМ в проекта на redux и так далее.

А что именно осталось непонятным после прочтения статьи? Мы бы с удовольствием дополнили и/или упростили.

Полагаю, что ваши обманутые ожидания происходят из-за того, что в Яндексе под «разработкой интерфейсов» понимают именно front-end, а UX и «красоту» относят к дизайну.

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

Прошедшая Мобилизация была гораздо шире, там присутствовал дизайн, как отдельная «школа», но ШРИ, как и в Симферополе, затрагивала лишь программирование front-end-а.

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

Например, BEMHTML.

Есть подозрение, что под словом «БЭМ» вы понимаете что-то свое, если противопоставляете компонентному подходу.

На bem.info в «Основных понятиях» сказано буквально следующее: «Блок — логически и функционально независимый компонент страницы, аналог компонента в Web Components. Блок инкапсулирует в себе поведение (JavaScript), шаблоны, стили (CSS) и другие технологии реализации.»

Вы удивитесь, но среди предлагаемых на официальном сайте вариантов нейминга в том числе присутствует camelCase.