Sikre sammenkoblede designtokens med stilordbok

Mestring av kunsten med sammenkoblede designtokens

Når du arbeider med designsystemer, er det avgjørende å oppnå en sømløs forbindelse mellom designtokens for konsistens på tvers av plattformer. 🧩 Men hva skjer når tokenene dine mister hierarkiet under kompilering? Dette er en utfordring mange utviklere står overfor.

Tenk deg at du strukturerer designsymbolene dine omhyggelig i tre nivåer – primitiv, semantisk og spesifikk – bare for å finne ut at etter behandling med Style Dictionary, mister de sin gjensidige avhengighet. Resultatet? Dine semantiske og spesifikke tokens ender opp med primitive verdier, og bryter det tiltenkte hierarkiet.

I min egen erfaring møtte jeg nettopp dette problemet mens jeg forberedte designtokens for flere operativsystemer. Jeg trengte en løsning som beholdt den sammenkoblede strukturen til JSON-filene mine samtidig som jeg sørget for at utdataene var optimalisert for implementering. 🚀

I denne veiledningen vil jeg lede deg gjennom hvordan du konfigurerer Style Dictionary for å opprettholde disse relasjonene, og sørger for at tokenene dine forblir så sammenkoblet som tiltenkt. Enten du er ny til å designe tokens eller feilsøke et lignende problem, vil denne innsikten være uvurderlig. La oss dykke inn! 😊

Mestring av hierarkisk designtokeneksport

I de oppgitte skriptene er hovedmålet å opprettholde den hierarkiske strukturen til designtokens på tvers av flere nivåer – primitive, semantiske og spesifikke. Ved å bruke Styleordbok introduserer vi tilpassede transformasjoner og formater for å sikre at relasjoner mellom tokens bevares under eksportprosessen. For eksempel tilpasser «registerTransform»-metoden hvordan tokennavn genereres, ved å bruke et strukturert format basert på deres kategori-, type- og vareattributter. Denne hierarkiske navngivningen sikrer klarhet og konsistens på tvers av token-samlinger. 🛠️

En annen nøkkelfunksjon er `registerFormat`-metoden, som muliggjør eksport av tokens til en strukturert JSON-fil. Dette formatet beholder token-relasjonene som definert i den opprinnelige inngangen, noe som gjør det enklere å implementere dem på ulike plattformer. Tenk deg å jobbe med et stort prosjekt der semantiske tokens som "primærfarge" refererer til primitive tokens som "blue-500" – å bevare dette forholdet under kompilering er avgjørende for å forhindre implementeringsfeil. Ved å utnytte disse funksjonene, blir Style Dictionary et kraftig verktøy for å opprettholde token-integritet.

I det Python-baserte skriptet bruker vi en rekursiv funksjon for å navigere gjennom nestede ordbøker, og bevarer hierarkiet under transformasjonen av designtokens. For eksempel, hvis et "button.primary.background"-token refererer til et "color.primary"-token, sikrer funksjonen at disse relasjonene forblir intakte. Denne metoden er spesielt nyttig for team som trenger å jobbe med designtokens utenfor JavaScript-økosystemet, ettersom Python tilbyr stor fleksibilitet for behandling av JSON-filer. 🚀

Til slutt legger integreringen av enhetstester ved hjelp av Chai i JavaScript-skriptet til et kritisk lag med verifisering. Disse testene sikrer at tokens ikke bare kompileres riktig, men også beholder sine tiltenkte relasjoner. For eksempel verifiserer en test at semantiske tokens refererer til primitive verdier som forventet, mens en annen sikrer at alle tre nivåene – primitive, semantiske og spesifikke – er tilstede i den kompilerte utgangen. Med disse skriptene og praksisene kan designsystemer skaleres effektivt samtidig som de opprettholder konsistens på tvers av plattformer, unngår potensielle fallgruver og sparer utviklingstid. 😊

// 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');
  });
});

Bevaring av tokenforhold på tvers av plattformer

Et oversett aspekt ved å jobbe med designtokens er å sikre deres kompatibilitet med ulike plattformer, som web, iOS og Android. Selv om verktøy som Style Dictionary er kraftige, krever de nøye konfigurasjon for å sikre at tokens beholder sin tiltenkte struktur. For eksempel bør semantiske tokens som "button.primary" referere til primitive tokens som "color.blue" i stedet for å hardkode verdiene deres. Denne sammenkoblingen lar utviklere gjøre endringer på det primitive nivået og se oppdateringer reflektert på tvers av alle avhengige tokens. 🌐

For å oppnå plattformspesifikk kompatibilitet, kan tilpassede transformasjoner og formater skreddersys for hver utgang. Dette sikrer at tokens ikke bare er konsistente, men også optimalisert for plattformens native stilkonvensjoner. For eksempel kan iOS kreve tokens i et `.plist`-format, mens nettutviklere foretrekker JSON- eller CSS-variabler. Ved å bruke disse spesialiserte utgangene opprettholdes token-integriteten samtidig som implementeringen for ulike team effektiviseres. Ved å fokusere på disse aspektene kan team skape skalerbare, plattformagnostiske designsystemer. 🚀

En annen viktig faktor er å integrere versjonskontroll og samarbeidende arbeidsflyter. Ved å lagre token-filer i et versjonskontrollert depot og kombinere dem med CI/CD-pipelines, kan oppdateringer til tokens testes og distribueres automatisk. Dette sikrer at tokens forblir oppdatert på tvers av plattformer uten manuell inngripen, minimerer feil og opprettholder integriteten til designsystemet. Slik automatisering sparer ikke bare tid, men støtter også voksende team som håndterer komplekse token-hierarkier. 😊