Ребятки рассудите: если верстать на реакте по-дедовски, закладывая некоторые состояния

отображения (ну там открыт табчик или закрыт, активна кнопка/неактивна) путём добавления дополнительных классов к DOM-элементам используя БЭМ-методологию, это ОК или прошлый век и лучше юзать module.css и css in js?

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

css-in-js оверкилл если то что вы делаете простой проект без дизайн системы или ее подобия, БЭМ это не дедовский способ, а вполне нормально, и тем не менее css модули мне кажутся лучшим решением для большинства задач это мое мнение.

Получается, что БЭМ-методология в корне не годится для реакта?

То, что ты в начале описал не зависит от того, как ты пишешь стили, навесить доп. класс в любом случае можно. Если юзаешь бэм, то никто не запрещает применять его и модули одновременно, всё-таки одно другое не заменяет полностью, хотя тут наверно большинство другого мнения.

насчет active-не active — да, классами. да, css-modules или css-in-js

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

ну в реакте ты можешь не забывать что у тебя есть блок и он задаёт margin для элементов)

ну такое. зачем, когда есть css-modules или css-in-js. а насчет дебага чел загнул. в дев режиме имена классов остаются теми же, что в файле модуля + хэш. в проде имена выпиливаются

Модули вообще никак не стакаются с БЭМ. Ничто не стакается с БЭМ в принципе, т.к. эта система замкнута сама в себе и любые сторонние сущности напрочь рушат концепцию бэм, тем более модульный КСС

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

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

По мне блоки очень хорошо ложатся на компоненты.

Они ложатся В компоненты. В компоненте может быть любое кол-во блоков. а вот в блоке напротив не может быть что-то большее, чем блок. Сравнивать их, всё равно что сравнивать грузовик, и ящики, которые этот грузовик перевозит

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

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

это когда?

Что когда?

когда можно делать элементы элементов?

Ну это ж не значит, что надо верстать как мудак. Примеси совсем уж так-себе идея для обеспечения реюзабельности стилей.

если у тебя DRY прямо в крови, то можешь юзать миксины. но в большинстве случаев переменных хватает

Ну правильнее будет сказать не когда, а как, сейчас найду эту часть в доке

переменные не решают проблему дублирования, ты просто будешь переписывать свойства по 100500 раз записывая переменные, вместо значений. А на счёт проектирования: организация CSS кода - это часть проектирования, при чём не самая последняя на фронте.

если честно, я не понимаю концепцию то есть, условно у нас есть Button. внезапно, нам нужен Button с Icon. мы берем Button, добавляем ему startIcon, endIcon пропы, вешаем на них классы из модуля и все

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

ну это тебя уже в степь какую-то лютую понесло. ты создаешь одну и ту же вариацию Button с разными классами?

А можно просто написать button button—red и кнопка будет красной, а потом добавить icon и там будет икнока

а зачем тогда реакт?

А реакт не эту проблему решает

В общем речь была о служебных блоках, не удалось найти почему-то кокретно как он пишется в доке, помню, что это делается примерно так <ul class='list'> <li class='list__item'> <a class='list__item-link'>link</a> </li> </ul> Но с реактом надобность и в таком в принципе отпадает, когда всё можно делать через композицию. https://ru.bem.info/methodology/quick-start/#%D0%92%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C-1

или через рендер-проп и экспортом служебных компонентов

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

ну тут не элемент элемента, но мысль я понял, спасибо)

ну вот в случае с Dialog хз, как по-другому сделать. там есть сам Dialog, DialogContent, DialogTitle, DialogActions. может, еще что-то

В бэме допускается любая вложенность элементов, это в доке не первых страницах написано https://prnt.sc/v9cpxr

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

Под вложенностью я имел ввиду вложенность внутри компонента, а не в доме, понятно, что там она любой может быть.

ага, полностью согласен

И компоненты становятся всё более и более жирными, тот случай, что ты описал прям идеально ложится на то, что надо просто отдельную кнопку делать.

зачем?

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