Sharq UI System. Часть 4

SUS дошел до этапа внедрения так сказать. Есть необходимый минимальный набор инструментов для создания иерархии компонентов. Обозначились места управления элементами UI, обозначились правила оформления компонентов.
Реализована система тем для разрешений. Пока одна точка переключения - 1600 px. То есть разделение такое: пока все, что выше 1600 или то, что ниже 1600.
Целевое разрешение проектирования 1920px. То есть я визуально собираю под это разрешение, а все остальные автоматически подгоняются.
Реализовано 2 типа переключения разрешений: один - красивый, а второй - быстрый.

Красивый - это когда переменные размеров подгоняются по правилам дизайн-системы.

В красивом варианте 2 реализации:

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

Вот так это выглядит:

border-radius: var(--btn-brdr-rds-normal);

Второй. Подставляется автоматизированная переменная. Которая может использоваться и в других компонентах.

Так выглядит атрибут uss-класса кнопки:

padding-left: var(--base-padding-horiz-n4-normal);

Тут используется автоматизированная переменная. Но в свою очередь она зависит от другой переменной, которая объявляется в другом месте:

--base-padding-horiz-n4-normal: var(--base-n4-normal);

А эта новая переменная уже объявлена в 2 файликах:

__high-resolution.uss:

--base-n4-normal: 4px;

__low-resolution.uss:

--base-n4-normal: 2px;

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

Второй способ - быстрый. Я его честно говоря подсмотрел у одного человека.
Есть 2 файлика:
__high-resolution-pixels.uss

--1px: 1px;
--2px: 2px;
--3px: 3px;
--4px: 4px;
--5px: 5px;
...

__low-resolution-pixels.uss

--1px: 1px;
--2px: 1px;
--3px: 2px;
--4px: 2px;
--5px: 3px;
...

Оба файлика заполнены переменными, которые содержат размер в семантике.
У меня сделано пока до 600px, минусовые переменные и выше 600 я уже вношу по надобности руками.
В результате используем не пиксели, а переменные:

border-radius: var(--30px);

Такой подход резко ускоряет прототипирование, верстку и отправку в "продакшн".
Прототип делается для 1 целевого разрешения. Верстка с большой долей вероятности не сломается, т.к. будет выглядеть почти идентично целевому разрешению.
И это позволяет даже иногда не проверять дополнительные разрешения в угоду скорости выкатывания UI-фичи. Кроме того такой способ позволяет избегать полупикселей, что сохраняет контроль за тем как выглядят элементы UI.

Реализована система цветовых тем. Пока сделано 2 темы светлая и темная.
Для этого были сформированы наборы цветов и их инвертирование. Но сделано это только для реализации встроенных в SUS компонентов.

Реализована система добавления кастомных цветовых тем. То есть присутствуют и встроенные цвета и цвета для игры. Их можно использовать вместе. Можно дополнять новыми темами.

Теперь я приступил к прототипированию игрового интерфейса и его реализации. Но это я покажу в следующем посте.