[Research] токены onDark / onLight / Inverse

[neretin-trike]

Ссылка на прототип подхода.

На что не надо обращать внимание в примере

• <div className="plasma-combobox"> -> этот класс должен висеть на самом компоненте Combobox, но из-за бага сейчас это ломается.
• На некоторые токены (типа --plasma-dropdown-item-color-selected), т.к. в Combobox используются другие токены цвета

Как использовать

1. Обернуть нужные компоненты в контейнер (или использовать существующий)
2. Импортировать applyOnLight / applyOnDark / applyInverse из plasma-web / plasma-b2c и т.д.
3. Применить нужный миксин внутри контейнера и выбрать компоненты, которые нужно стилизовать (по дефолту стилизуются все компоненты)

Спецификация

• applyOnLight - применяется всегда на светлом фоне независимо от выбранного режима темы (dark / light)
• applyOnDark - применяется всегда на тёмном фоне независимо от выбранного режима темы (dark / light)
• applyInverse - применяется для фонов, которые меняются в зависимости от выбранного режима темы (dark / light)

Шаги для реализации такого подхода

1. Провести ревизию всех токенов цветов в конфигах компонент для библиотек plasma-web / plasma-b2c / plasma-asdk
2. В каждый компонент добавить уникальный class-name на самый верхний уровень (plasma-button, plasma-badge) и т.д. (подумать на каком уровне то нужно сделать - ядро или библиотека)
3. Для каждого компонента из new-hope необходимо смапить токены для режимов onLight, onDark и inverse
4. Положить смапленные токены на уровень конфига компонента
5. Считаем, что наши значения - эталонные, то есть пользователи должны будут учитывать эти соответствия при создании своих токенов и используя их в маппере
6. Автоматически сформировать список доступных компонент для типизации
7. Создать уникальные для каждой библиотеки (plasma-web / plasma-b2c) миксины applyOnLight / applyOnDark / applyInverse, в которых будут использоваться уникальные классы компонент

Дополнительный функционал

• Реализовать компоненты <LightContainer /> / <DarkContainer /> / <InverseContainer /> или <ColoredContainer mode="onLight | onDark | inverse"/> с зашитой внутри логикой по переопределению токенов цвета
• Добавить возможность использовать css-модули. То есть заранее сгенерировать файлы: on-light.module.css, on-dark.module.css, inverse.module.css, в которых будут лежать классы, которые пользователь сможет точечно добавлять на контейнеры.

Достоинства и недостатки метода

+ Нет необходимости указывать для каждо компонента режим отображения. Т.к. частый кейс - это именно использования группы компонент в контейнере
+ Так жесть возможность точечного указания компонент, которые необходимо модифицировать
+ Работает в билд тайме, т.к. при сборке библиотеки сформируется только те css правила, которые были выбраны

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

[Yakutoc]

<ColoredContainer mode="onLight | onDark | inverse"/>

Я за этот вариант.

Необходимо произвести большую работу по ревизии всех используемых токенов в компонентах

ИМХО это скорее плюс.

• актуализируем знания
• ревизия кода

[neretin-trike]

ИМХО это скорее плюс.

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

[TitanKuzmich]

Я правильно понимаю, что будет кастомный миксин, в котором вшит набор токенов по каждому компоненту из либы. Этот миксин будет применятся в стилях контейнера LightContainer, к примеру?

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

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

[neretin-trike]

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

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

А вот если вкладывать, то надо проверять и вообще понять, хотим ли мы и такой кейс поддерживать

[neretin-trike]

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

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