Там как раз есть HOC для «сбора из запчастей»

т.е. компоненты в БЭМ React - это конструктор который требует каждый раз сборку необходимого функционала?

так же происходит и со стилями для модификаторов?
правильно я понял?

Если вы не понимаете общую концепцию методологии, bem-react вам не поможет. Начните с теории на bem.info , а уже потом переходите к инструментам — это не Реакт или Ангуляр, которые можно изучать «по ходу», используя bem-react вы ни на йоту не приблизитесь к пониманию концепции и компонентного подхода.

да вот я слушал выступления на БЭМапах и пытаюсь сопоставлять это с Реакт реализацией - пока не сходится

Считайте БЭМ как философию типа SOLID — куча фреймворков и библиотек построены по этому принципу, но их использовfние не поможет вам понять SOLID. Тут нужно наоборот (иначе просто не получится) — изучаем какое-то базовое понятие в БЭМ → понимаем, чем оно полезно и где мы можем его применить → находим хелпер, помогающий это понятие реализовать в коде среди bem-react (или классического стека).

Т. е. добавив bem-react в зависимости, не случится какая-то «магия» и ваш код не бэмизируется.

спасибо - попробую )

но меня кроме чистого БЭМ интересуют и архитектурные вопросы в построении сложных компонент которые могут быть использованы и не в БЭМ проектах

Я могу попробовать объяснить, как это устроено, но у меня мышление сильно завязано на классический стек — его создавали без привязки на какой-либо фреймфорк или библиотеку: Ангуляр/Реакт/Вью/Эмбер и так далее (поэтому получился свой ни на что не похожий )))

Это реально какая-то очень тонкая философская грань между «БЭМ — лишь классы через чёрточку» и «у меня БЭМ-зрение, я могу любой компонент разложить по полочкам на раз-два».

Но лично у меня эта тонкая грань очень растянулась по времени. Чем-то похоже на езду на велосипеде — пока не научишься — постоянно падаешь и злишься, но стоит один раз поехать самостоятельно и уже никогда не разучишься. Одна нейронная связь между «до» и «после».

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

Ну, конкретно про кнопку уже описано в самой доке к bem-react: https://github.com/bem/bem-react/tree/master/packages/core

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

как в https://github.com/bem/yandex-ui ?

ну вот в примере из ui - я сначала должен обернуть базовую кнопку в хок с модификатором а потом еще и в пропсах указать этот модификатор - это же можно сделать под капотом?

ведь тут же по сути я говорю: хочу такой-то модификатор - ну вот фабрика бы внутри обернула бы мне базовую кнопку в хок с нужным модификатором и пробросила бы нужный пропс и освободила бы от этого разработчика!

Хочется же сервиса по высшему разряду как когда-то было на Ленинградке: подъезжаешь и говоришь мне нужна с темто темто и темто - и старшая бац и привела то что хочешь 😂
а тут ты подъезжаешь называешь параметры а тебе говорят: эээ дружок - у нас кружок умелые ручки - что соберешь с тем и повеселишься! )))

У нас такая история была с бэм-импортами.
Мы писали import Button from ‘b:Button m:size=m m:view=default|action’

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