Забезпечення взаємопов’язаних дизайнерських токенів зі словником стилю

Освоєння мистецтва взаємопов’язаних дизайнерських токенів

Під час роботи з системами проектування досягнення безперебійного зв’язку між маркерами дизайну має вирішальне значення для узгодженості між платформами. 🧩 Але що станеться, якщо ваші токени втратять свою ієрархію під час компіляції? Це проблема, з якою стикаються багато розробників.

Уявіть собі, що ви ретельно структуруєте свої лексеми дизайну на три рівні — первинний, семантичний і специфічний — і виявите, що після обробки словником стилю вони втрачають свою взаємозалежність. Результат? Ваші семантичні та специфічні токени в кінцевому підсумку мають примітивні значення, порушуючи намічену ієрархію.

З власного досвіду я зіткнувся з цією проблемою під час підготовки маркерів дизайну для кількох операційних систем. Мені потрібне було рішення, яке зберегло б взаємопов’язану структуру моїх файлів JSON, забезпечивши при цьому оптимізований результат для реалізації. 🚀

У цьому посібнику я розповім вам, як налаштувати словник стилів, щоб підтримувати ці зв’язки, гарантуючи, що ваші лексеми залишатимуться взаємопов’язаними, як це передбачено. Незалежно від того, чи ви новачок у розробці маркерів чи вирішенні подібної проблеми, ця інформація буде безцінною. Давайте зануримося! 😊

Освоєння експорту токенів ієрархічного дизайну

Основна мета наданих сценаріїв — підтримувати ієрархічну структуру маркерів дизайну на кількох рівнях — примітивному, семантичному та специфічному. Використовуючи Style Dictionary, ми запроваджуємо спеціальні перетворення та формати, щоб забезпечити збереження зв’язків між маркерами під час процесу експорту. Наприклад, метод `registerTransform` налаштовує спосіб генерації імен токенів, використовуючи структурований формат на основі їх категорії, типу та атрибутів елемента. Це ієрархічне іменування забезпечує ясність і узгодженість між компіляціями токенів. 🛠️

Іншою ключовою функцією є метод registerFormat, який дозволяє експортувати токени у структурований файл JSON. Цей формат зберігає зв’язки маркерів, як визначено у вихідному введенні, що полегшує їх реалізацію на різних платформах. Уявіть собі, що ви працюєте над великим проектом, де семантичні маркери, такі як «основний колір», посилаються на примітивні маркери, такі як «синій-500» — збереження цього зв’язку під час компіляції є важливим для запобігання помилкам реалізації. Використовуючи ці функції, Словник стилів стає потужним інструментом для підтримки цілісності маркера.

У сценарії на основі 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. Хоча такі інструменти, як Style Dictionary, є потужними, вони вимагають ретельної конфігурації, щоб переконатися, що маркери зберігають заплановану структуру. Наприклад, семантичні лексеми на кшталт "button.primary" мають посилатися на примітивні лексеми на зразок "color.blue", а не жорстко кодувати їхні значення. Цей взаємозв’язок дозволяє розробникам вносити зміни на початковому рівні та бачити оновлення, відображені в усіх залежних токенах. 🌐

Щоб досягти сумісності з певною платформою, користувацькі трансформації та формати можна налаштувати для кожного виводу. Це гарантує, що токени є не тільки узгодженими, але й оптимізованими для стандартів рідного стилю платформи. Наприклад, iOS може вимагати маркерів у форматі `.plist`, тоді як веб-розробники віддають перевагу змінним JSON або CSS. Використання цих спеціалізованих виходів зберігає цілісність маркера, одночасно оптимізуючи впровадження для різних команд. Зосереджуючись на цих аспектах, команди можуть створювати масштабовані системи проектування, що не залежать від платформи. 🚀

Іншим ключовим фактором є інтеграція контролю версій і спільних робочих процесів. Зберігаючи файли токенів у репозиторії з контрольованими версіями та поєднуючи їх із конвеєрами CI/CD, оновлення токенів можна тестувати та розгортати автоматично. Це гарантує, що токени залишаються актуальними на всіх платформах без ручного втручання, мінімізуючи помилки та зберігаючи цілісність системи дизайну. Така автоматизація не тільки економить час, але й підтримує зростаючі команди, які обробляють складні ієрархії маркерів. 😊