По Реакту куча тоториалов куча, больше, чем про что либо иное. А если речь про bem-react, то, думаю, кейсов пока маловато. Разве что репозиторий Антона @awinogradov https://github.com/awinogradov/aviasales

Кейсов и не появится больше, пока не будет более точных вопросов 😉

есть ли конфиг для bem create чтоб создавал заготовки как Вы это видете ? или что то подобное ?

но в реакт бем коре

Э

:D

Оффтоп.
Суперкофиги дичь. Лучше настравать vim под себя и не сильно отходить от стандартов.

Здесь мой текущий конфиг.
https://github.com/belozer/dotfiles/tree/master/config/nvim

В целом уже около года на нём и +- всё устраивает.

UPD.
Не использую встроенные сплиты. Разбивку на экраны делаю через терминал.

blagodary tebya moi drug :D

господи какой я тупой. прочитал бэм быстрый старт,мой мозг не готов воспринимать такую академическую подачу информацию, особенно глючит когда употребляется слово сущности))
пока понял что работа c css выстраивается на классах. хмм, блок это блок(класс) ,элемент это уточняющая деталь или просто имеется ввиду что назначаем название предкам блока, с модификатором я поплыл и понял что надо спать)

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

классический стек бэм довольно сложный

Любая методология это способ избавиться в первую очереь от глобальных стилей и связанных с ними конфликтов.
Такие конфликты - больше 50% проблем css.

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

и наверно сейчас это больше именно методология, то есть у тебя 3 псевдо личности. Дизайнер, менеджер и программист. И все они говорят на одном языке когда обсуждают какую то сущность проекта. Так как все в этом мире БлокЭлементМодификатор. А ты только переводишь это в любымый js быстро и компонентно. Проще понять это стартануть project-stub и нажимать кнопки )

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

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

Блоки — отдельные компоненты, элементы — вспомогательные члены компонента. В основном, на элементах основывается внутреннее строение компонента + выстраиваются связи с другими компонентами: описывается внутренняя геометрия (отступы), декорирование, элементы миксуются к внутренним компонентам (которые, в последствии, находятся из js), и т.д. И тут речь, очевидно, не только про CSS

да блоки элементы достаточно понятно если смотреть в рамках css , тк я js еще почти не тыкал. с модификаторами надо вникнуть,почитаю еще

спасибо за ответы)

Модификаторы не должны рвать компонент. Это как мутации — когда сверх меры, организм не выживает, но совсем без мутаций — тож невозможно

привет. Вопрос такой. В доке есть раздел про расположение блока относительно других блоков. Тут всё понятно, добавляем соотвествующий элемент и пишем туда отступы. Но взаимоотношения между блоками не заканчиваются на отступах. Что если связь определена цветом? Например шапка имеет тёмный bg-color, соотвественно всё что там должно быть светлого цвета. Цвет фона определяющий. Имею ли я право  записывать свойство color для блоков внутри шапки в эти связующие элементы (аля header__logo, header__description, header___menu и так далее)? Или же принято ограничиваться только позиционированием?