Комментарии 34
Вопрос вообще не технический, это вопрос дисциплины команды (а то и нескольких). Увы, но поддерживать такую дисциплину сложно (я нигде такого не видел), так что className скорее нужен, чем нет
У меня такой же опыт, поэтому решил поднять эту тему. Но я, к сожалению, не смог аргументировать использование className в ui kit компонентов компании. Если у вас есть пример обоснованного использования className в такой ситуации, буду очень рад услышать его.
Скорее вопрос дисциплины дизайнеров, чтобы они не рисовали 100500 видов одного и того же.
Понятие "класс-костыль"
Это класс, который переопределяет стили для конкретного компонента в конкретном месте, вместо стилизации его глобально для всего приложения. Например, через тему.
В БЭМ это называется "модификатор". И я не понимаю - зачем от него избавляться? ;)
правильно, лучше избавляться от бэм и переходить на модули или styled)
Какие, нафиг, модули?
Чем БЭМ не угодил? Благодаря нему очень легко и быстро окунаться в нужные места кода. Легче найти уникальный .SomeModule__item_active, чем ломать голову с поиском какого-нибудь .btn или .item.
Вот сейчас работаю над легаси проектом, где чёрт ногу сломит из-за отсутствия БЭМ. Анализируя html блок, вообще никак не понять, что и при каких обстоятельствах его сгенерировало. БЭМ меня спасает в vue компонентах, хотя можно спокойно изолировать классы от остального мира через <style scoped>
Короче, БЭМ рулит.
css map?
Бем прошлый век?
БЭМ работает лишь на 1 уровень вглубь, что не позволяет нормально стилизовать многовложенные компоненты. Гляньте css-in-ts лучше.
БЭМ работает лишь на 1 уровень вглубь
Это как вообще? БЭМ - это лишь методология именования классов. Никаких других ограничений мне это не ставит.
Я бы вот сюда лучше посмотрел ;)
В момент проектирования компонента вы не знаете, где он будет использован. Соответственно, и не знаете какой бэм-элемент внешнего бэм-блока прописать для вложенных компонент. Тут это разобрано подробней.
Ерунда какая-то))
<div class="header">
<div class="block">
<span class="block__el"></span>
</div>
</div>
<style>
.header .block__el{
color: red;
}
</style>
<div class="header">
<div class="header-block block">
<span class="header-block__el header-block__el_red block__el"></span>
</div>
</div>
<style>
.header-block__el.header-block__el_red{
color: red; // каскад, знаете ли, никто не отменял
}
</style>
Вам какой вариант больше нравится?
У вас тут нет ни одного компонента. Бэм зарождался когда верстальщики делали страницы с нуля и ничего не знали про компоненты. Те времена давно прошли. Сейчас актуален иерархический бэм с автогенерацией глобально уникальных семантических классов и тому подобная "ерунда".
Какая, блин, разница? Замените div и span на соответствующие компоненты.
с автогенерацией глобально уникальных семантических классов
Что? Зачем? Для чего?
Где актуально? В Яндексе для борьбы с АдБлоком?
Речь про иерархию владения, а не расположения.
CSS модули генерируют название класса исходя из названия компонента, где он находится. То есть, вместо прописывания руками .SomeModule_item в компоненте SomeItem, просто прописываешь item к нужному элементу. Поэтому найти его в коде так же легко как и бэм класс, а человеческий фактор в нейминге классов сходит на нет
Я говорил о случаях когда ваша или готовая UI библиотека отдаёт - компоненты, а не только стили.
Если вы прямо в месте использования собираете нужный вам класс, то для вас className жизненно необходим. Пример<button className="button button__size_s">Отправить</button>
Но если вы инкапсулируете стилизацию внутри компонентов, то у вас "класс-костыль". Пример<Button className="класс-костыль" size="s" >Отправить</button>
А как быть, если нужно конкретно от этой кнопки задать margin? Указать его явно через style вместо пробрасывания "класса-костыля"?
Если возникла такая ситуация, то это повод задуматься - Почему ваш UI kit компонент требуется докручивать до того дизайна что вам требуется? Вы не должны тратить время на выравнивание стилизации, так как она уже должна быть выровнена согласно дизайну. Иначе вы теряете преимущества использования UI kit.
Звучит идеально, но к этому надо стремиться.
Давайте ненужный пафос и теоретизирования приберём, а перейдём к практическому положению дел...
Почему ваш UI kit компонент требуется докручивать до того дизайна что вам требуется?
Потому что в утверждённом дизайне встречаются два вида компонентов - дефолтный и модифицированный.
Вы не должны тратить время на выравнивание стилизации, так как она уже должна быть выровнена согласно дизайну.
"Уже" - это где именно?
Согласитесь, что любые модификации должны быть предусмотрены в этом компоненте через его набор props (через его api).
Уже - это в UI kit. Вы же его разрабатываете не для того что бы править под каждый случай.
Согласитесь, что любые модификации должны быть предусмотрены в этом компоненте через его набор props (через его api).
Нет, конечно)) Стилевые модификации должны быть предусмотрены в компоненте через css-селекторы ;)
Уже - это в UI kit. Вы же его разрабатываете не для того что бы править под каждый случай.
У вас UI kit сразу учитывает лэйаут страницы на которой надо будет вывести эти ui-комопненты? Серьёзно?))
Очевидно что задать паддинг у внешнего элемента, куда встроена кнопка. Какой-то же грид-лайаут, ячейка таблички, футер или другой тип лайаута есть, куда эта кнопка встроена.
Как бы вам объяснить... Веб-технологии (и CSS в частности) не ограничиваются применением в рамках вашего любимого реактивного фреймворка!
Как вы вообще пришли к "компонентному мышлению" вместо "стилевого"? Вы работали с CSS вне бутстрапов, вьютефайев и т.п.? Просто когда я встречаю стремление полностью собрать веб-приложение из отдельных кирпичиков-компонентов - я искренне недоумеваю... Бог с ней, со стилизацией компонентов. Как вы лэйаут стилизовать собираетесь? Вот где вся головная боль css сосредоточена! Вот для чего до сих пор допиливается css grid и т.п.
Но если вы инкапсулируете стилизацию внутри компонентов, то у вас "класс-костыль".
А иначе у меня "компонент-костыль". Вы предлагаете наплодить компонентов на каждый чих? Ну там отдельный компонент для кнопки каждого цвета и т.п. Серьёзно?)
Хм... Что же здесь действительно избыточно - один модифицирующий класс (как раз полностью в рамках соответствующей парадигмы технологии) или целый компонент со всеми потрохами (частенько даже с обсчётом логики)?
Весь диалог строиться вокруг компонентов фреймворка react - так и пришли. Хотелось бы понять что вы подразумевает под layout? Если это разметка header, body, footer, sidebar и т.д. То это не всегда может быть стандартизировано для всех страниц вашего приложения, но если очень хочется, то можно привести к одному виду и вынести в ui kit. Отступ можно стандартизировать через тему.
Чтобы не плодить компонент на каждый "чих", вы должны продумать api (набор props) вашего компонента так, чтобы через него можно было настраивать внешний вид. Например для цвета можно использовать отдельный prop color.
Последнюю часть не очень понял, не знаю как прокомментировать.
Хотелось бы понять что вы подразумевает под layout?
Разметка страницы.
Отступ можно стандартизировать через тему.
Это какие-то переменные, да? Где и как вы разметку конкретной страницы прописываете? Всё же не ограничивается одними ui-компонентами - есть ещё куча обёрток для этих компонентов.
Чтобы не плодить компонент на каждый "чих", вы должны продумать api (набор props) вашего компонента так, чтобы через него можно было настраивать внешний вид. Например для цвета можно использовать отдельный prop color.
Ну классические "семантические грабли")) Смешивать логику и представление... В итоге часть стилей будет во внутренних стилях компонента, а часть в пропсах вызова этого компонента в рамках какого-то шаблона - очень удобно и "поддерживаемо"))
Т.е. "класс-костыль" - это плохо, а раздербанить стили по пропсам компонентов - это очень быстро и удобно?))
Понятие "класс-костыль"
Это класс, который переопределяет стили для конкретного компонента в конкретном месте, вместо стилизации его глобально для всего приложения. Например, через тему.
Есть проекты, в которых используется подход с изолированными css-стилями (так называемый css-modules). При таком подходе имена стилей генерируются автоматически и при подключении их к проекту не возникает никаких конфликтов (если вдруг однажды не будет сгенерировано имя стиля, который уже встречается в проекте... но, это маловероятно). Считать ли такие стили "костылями", только потому, что они позволяют локально переопределять внешний вид элементов? Очень сомневаюсь. Я бы предложил исправить название этого понятия на "локальный стиль", чтобы не вводить в заблуждение читателей, которые только знакомятся с frontend разработкой.
При использовании готовых решений (библиотек компонентов, например) часто приходится переопределять стили стандартных компонент для того, чтобы они соответствовали дизайну (и это нормально). И да, без className тут не обойтись, если нужна какая-то "сложная" визуализация. Библиотеки UI-компонент предоставляют только "базовый" набор часто используемых компонент, но если нужно добавить свои изменения - тут без инструментов для кастомизации не обойтись. Это именно инструмент кастомизации, а не "баг" или "фича". Можно это даже считать своеобразным компонентным API (думаю, что так даже более корректно).
Я считаю, что если проекту не хватает возможностей UI-библиотеки, то стоит либо свою библиотеку разрабатывать (с нуля), либо создавать свои компоненты на основе уже готовых с переопределением стилей через classNames, и лучше это делать именно с помощью сравнительно безопасного подхода css-modules (или styled-components). И это не должно считаться "костылём". Готовые решения не панацея, в любой момент может потребоваться изменить поведение уже готового компонента, это только вопрос времени.
Если я правильно вас понял, есть UI пакет с css-modules, и вы его подтягиваете для стилизации чего либо. Примерimport { button } from "@ui-kit/css-modules";
<button className={button}>Отправить</button>
В таком случае, мои аргументация построенная вокруг className не работает. Так как ваше решение отдаёт лишь стили, а не заранее стилизованные компоненты.
Мне очень понравился ваш термин "локальный стиль" - он более политкорректный. Но, мне кажется, такая формулировка размывает серьёзность проблемы.
Если вы создаёте систему UI компонентов, то любое переопределение стилей на локальную вариацию - это сигнал о том, что то идёт не так. Если нужна "сложная визуализация", то она должна лежать в ui kit компонентах c ещё большей вероятностью. А не оставаться где то локально в месте использования.
Я согласен с последним тезисом, но не полностью. Вы потратили время на разработку UI Kit, который решает конкретную проблему - переиспользование. И продолжаете модифицировать набор компонентов от случая к случаю. И это значит, что ваш UI Kit не выполняет той функции, которую вы на него возложили. Так почему я должен не называть такие точечные стилизации "костылями"?
className убивает ваш UI kit