Вот такого вида стили надо перекидывать в файл компонента, к которому они применяются (Avatar.css). Мы не знаем, в каком порядке стили подключаются, и не можем его гарантировать — следовательно, не можем контролировать каскад. Эта проблема уходит, если мы положим все стили про Avatar в Avatar.css.

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

А это реальный пример, кстати?...

Для Avatar мы выставляем 10px отступ, а для Icon 8px

Такая тема затрудняет, конечно, реализацию решений, которые я в рабочем чате предложил

Да, у нас есть такие компоненты. Counter сам по себе и Counter внутри Button можно чекнуть, например.

Глянул
Хм, а что если через реактовский контекст рулить такие вещи?
У меня сейчас есть такая идея для ButtonGroup

Вот такого вида стили надо перекидывать в файл компонента, к которому они применяются (Avatar.css). Мы не знаем, в каком порядке стили подключаются, и не можем его гарантировать — следовательно, не можем контролировать каскад. Эта проблема уходит, если мы положим все стили про Avatar в Avatar.css.

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

Если на .Avatar в Avatar.css не будет собственного margin, то по сути неважно, где размещать эти стили.

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

С учетом что мы пока не движемся туда, куда там написано, то этот раздел правда не нужен.

Окей, согласен, унесу в другое место.

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

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

@NekR про размер, возможно, это экономия на спичках, тут нужны цифры до и после, а вот то, что это исключит манию завязаться на тот или иной класс, хорошо

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

Сейчас кастомизация таким образом специально сделана. Вряд ли оно поддаётся однозначному хорошо или плохо

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

Усложнится миграция из одной версии на другую, т.к. вероятность изменения стилей выше, чем токена

Это нормально что юзерам нужно будет подправлять компоненты, так как библиотека никогда не угонится за дизайном и точно не покроет все продуктовые кейсы. Соответственно, когда разработчик в продукте пытается кастомизировать, он не должен бороться с библиотекой, а уметь максимально гибко поправить всё что ему нужно. Если это будет "полностью на токенах", то нужен будет токен на всё, даже на те css-свойсва которые мы не используем.

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

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

Переезд на css-modules и отказ от БЭМ-нотации уже включает в себя пункт Хэширование

Подумала и поняла, что мне не нравится пункт про отказ от БЭМ-нотации. Мы, по идее, будем продолжать писать внятные классы (если не уйдем на некий css-in-js, видимо), хотелось бы текущую нотацию оставить.

Зачем писать тяжеловесный .ModalCard__long-inner-element, если пропадает риск коллизиий? Можно просто оставить .long-inner-element и мы вроде ничего не потеряем и нигде не огребем.

@ArthurStam формулировка "отказ от БЭМ-нотаций" звучит радикально
Так или иначе даже при подходе CSS Modules или CSS-in-JS, для DX, надо будет придерживаться соглашения по именования

Например, БЭМ нормально дружит в CSS Modules, просто исчезнет необходимость писать название компонента ручками

Я вот так делал

/* Корневой элемент */
.host { }

.host_color_accent { }

/* Потомки */
.someItem { } /* camelCase для составных имен */

.someItem_fullWidth { }

.someItem_disabled { }

.icon { }

.icon_size_small { }

.host_color_accent .icon { }

import classes from './Example.module.pcss';

const hostColorClasses = {
  accent: classes.host_color_accent,
};

const iconSizeClasses = {
  small: classes.icons_size_small,
};

const Example = ({ className, color = 'accent', iconSize = 'small', disabled, ...restProps }) => {
  return (
    <div className={className(classes.host, hostColorClasses[color], className)} {...restProps}>
     <div className={classNames(classes.someItem, disabled && classes.someItem_disabled)}></div>
     <img src="" className={className(classes.icon, iconSizeClasses[iconSize])} />
   </div>
  );
};

Я не предлагал сеять хаос в именах классов. Речь шла только об отказе от необходимости дописывать всем селекторам имена блоков и элементов.

Может для составных имён всегда использовать camelCase, а kebab-case использовать для <key>-<value> модификаторов?

Вот так описать