Comments 2
В целом хорошо, но взгляд на токены устаревший. Если продукт требует дизайн-систему, то он достаточно масштабен и не конечен. В этом случае мы токенами покрываем все элементы цепочки «атом – ⋯ – страница», как в статике, так и в динамике. Масштаб покрытия ограничивается только ресурсами и целесообразностью. Я называю это облаком токенов, в котором существуют все элементы системы :). В итоге получается инструмент, с помощью которого разработчики быстро и просто создают продукт, а дизайнер (или DesignOps) может управлять продуктом напрямую, мимо разработчиков, просто редактируя значения токенов.
Спасибо за комментарий.
Токены в этой части упоминаются в рамках классического понимания, для общего представления, т.к. эта часть про архитектуру структурного построения дизайн-системы по её сущностям. В третей части мы как раз раскроем тему про токены более подробно, не в таком устаревшем и простом понимании, как упоминается в данной части.
Архитектура дизайн-системы. Критикуем и предлагаем