Обеспечение взаимосвязанности токенов дизайна с помощью словаря стилей

Овладение искусством взаимосвязанных токенов дизайна

При работе с системами дизайна достижение плавной связи между токенами дизайна имеет решающее значение для обеспечения согласованности между платформами. 🧩 Но что произойдет, если ваши токены потеряют свою иерархию во время компиляции? Это проблема, с которой сталкиваются многие разработчики.

Представьте себе, что вы тщательно структурируете свои дизайнерские токены на три уровня — примитивный, семантический и конкретный — только для того, чтобы обнаружить, что после обработки с помощью словаря стилей они теряют свою взаимозависимость. Результат? Ваши семантические и конкретные токены в конечном итоге получают примитивные значения, нарушая запланированную иерархию.

По моему собственному опыту, я столкнулся с этой самой проблемой при подготовке токенов дизайна для нескольких операционных систем. Мне нужно было решение, которое сохраняло бы взаимосвязанную структуру моих файлов JSON, гарантируя при этом оптимизацию вывода для реализации. 🚀

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

Освоение экспорта токенов иерархического проектирования

В предоставленных скриптах основная цель — поддерживать иерархическую структуру токенов дизайна на нескольких уровнях — примитивном, семантическом и конкретном. Используя Словарь стилей, мы вводим пользовательские преобразования и форматы, чтобы гарантировать сохранение связей между токенами в процессе экспорта. Например, метод RegisterTransform настраивает способ генерации имен токенов, используя структурированный формат на основе их категории, типа и атрибутов элемента. Такое иерархическое именование обеспечивает ясность и согласованность при компиляции токенов. 🛠️

Еще одной ключевой особенностью является метод RegisterFormat, который позволяет экспортировать токены в структурированный файл JSON. Этот формат сохраняет отношения токенов, определенные в исходных входных данных, что упрощает их реализацию на различных платформах. Представьте себе, что вы работаете над большим проектом, в котором семантические токены, такие как «основной цвет», ссылаются на примитивные токены, такие как «blue-500», — сохранение этих отношений во время компиляции важно для предотвращения ошибок реализации. Используя эти функции, Style Dictionary становится мощным инструментом для поддержания целостности токенов.

В сценарии на основе Python мы используем рекурсивную функцию для навигации по вложенным словарям, сохраняя иерархию во время преобразования токенов дизайна. Например, если токен «button.primary.background» ссылается на токен «color.primary», функция гарантирует, что эти отношения останутся неизменными. Этот метод особенно полезен для команд, которым необходимо работать с токенами дизайна за пределами экосистемы JavaScript, поскольку Python предлагает большую гибкость для обработки файлов JSON. 🚀

Наконец, интеграция модульных тестов с использованием Chai в сценарий JavaScript добавляет критический уровень проверки. Эти тесты гарантируют, что токены не только правильно компилируются, но и сохраняют заданные связи. Например, один тест проверяет, что семантические токены ссылаются на примитивные значения, как и ожидалось, а другой гарантирует, что все три уровня — примитивный, семантический и конкретный — присутствуют в скомпилированных выходных данных. Благодаря этим сценариям и практикам дизайн-системы могут эффективно масштабироваться, сохраняя при этом согласованность между платформами, избегая потенциальных ошибок и экономя время разработки. 😊

// Import the Style Dictionary package
const StyleDictionary = require('style-dictionary');

// Define the custom transform to maintain token hierarchy
StyleDictionary.registerTransform({
  name: 'custom/name-hierarchy',
  type: 'name',
  transformer: (token) => {
    return [token.attributes.category, token.attributes.type, token.attributes.item]
      .filter(Boolean)
      .join('.');
  }
});

// Define the custom format for interconnected design tokens
StyleDictionary.registerFormat({
  name: 'custom/json-structured',
  formatter: ({ dictionary }) => {
    return JSON.stringify(dictionary.tokens, null, 2);
  }
});

// Configure Style Dictionary with your custom settings
const StyleDictionaryConfig = {
  source: ['tokens//*.json'],
  platforms: {
    web: {
      transformGroup: 'custom/name-hierarchy',
      buildPath: 'build/web/',
      files: [{
        destination: 'tokens.json',
        format: 'custom/json-structured'
      }]
    }
  }
};

// Extend and build the Style Dictionary
const SD = StyleDictionary.extend(StyleDictionaryConfig);
SD.buildAllPlatforms();

import json

# Load design tokens from a JSON file
with open('tokens.json', 'r') as file:
    tokens = json.load(file)

# Function to recursively maintain hierarchy
def maintain_hierarchy(data):
    structured_tokens = {}
    for key, value in data.items():
        if isinstance(value, dict):
            structured_tokens[key] = maintain_hierarchy(value)
        else:
            structured_tokens[key] = value
    return structured_tokens

# Process tokens to maintain hierarchy
structured_tokens = maintain_hierarchy(tokens)

# Export processed tokens to a new JSON file
with open('structured_tokens.json', 'w') as file:
    json.dump(structured_tokens, file, indent=2)

const fs = require('fs');
const { expect } = require('chai');

// Load the compiled tokens
const tokens = JSON.parse(fs.readFileSync('build/web/tokens.json', 'utf-8'));

describe('Design Token Compilation', () => {
  it('should preserve the hierarchy in tokens', () => {
    expect(tokens.semantic).to.have.property('primary');
    expect(tokens.semantic.primary).to.equal(tokens.primitive.colorBlue);
  });

  it('should include all levels of tokens', () => {
    expect(tokens).to.have.property('primitive');
    expect(tokens).to.have.property('semantic');
    expect(tokens).to.have.property('specific');
  });
});

Сохранение отношений токенов на разных платформах

Одним из упускаемых из виду аспектов работы с дизайнерскими токенами является обеспечение их совместимости с различными платформами, такими как Интернет, iOS и Android. Такие инструменты, как Словарь стилей, эффективны, но требуют тщательной настройки, чтобы токены сохраняли заданную структуру. Например, семантические токены, такие как «button.primary», должны ссылаться на примитивные токены, такие как «color.blue», а не жестко запрограммировать их значения. Эта взаимосвязанность позволяет разработчикам вносить изменения на примитивном уровне и видеть обновления, отраженные во всех зависимых токенах. 🌐

Чтобы обеспечить совместимость с конкретной платформой, для каждого вывода можно настроить собственные преобразования и форматы. Это гарантирует, что токены не только согласованы, но и оптимизированы в соответствии с собственными правилами стиля платформы. Например, iOS может требовать токены в формате «.plist», а веб-разработчики предпочитают переменные JSON или CSS. Использование этих специализированных выходных данных обеспечивает целостность токенов и упрощает реализацию для различных команд. Сосредоточив внимание на этих аспектах, команды могут создавать масштабируемые, не зависящие от платформы системы проектирования. 🚀

Еще одним ключевым моментом является интеграция контроля версий и совместных рабочих процессов. Сохраняя файлы токенов в репозитории с контролем версий и объединяя их с конвейерами CI/CD, обновления токенов можно тестировать и развертывать автоматически. Это гарантирует, что токены будут актуальными на всех платформах без ручного вмешательства, сводя к минимуму ошибки и сохраняя целостность системы проектирования. Такая автоматизация не только экономит время, но и поддерживает растущие команды, работающие со сложной иерархией токенов. 😊