Savstarpēji saistītu dizaina žetonu nodrošināšana ar stila vārdnīcu

Savstarpēji saistītu dizaina žetonu mākslas apguve

Strādājot ar projektēšanas sistēmām, ir ļoti svarīgi panākt vienmērīgu savienojumu starp dizaina marķieriem, lai nodrošinātu konsekvenci dažādās platformās. 🧩 Bet kas notiek, ja jūsu marķieri kompilācijas laikā zaudē savu hierarhiju? Tas ir izaicinājums, ar ko saskaras daudzi izstrādātāji.

Iedomājieties, ka savus dizaina marķierus rūpīgi strukturējat trīs līmeņos — primitīvajā, semantiskajā un specifiskajā —, lai atklātu, ka pēc apstrādes ar Style Dictionary tie zaudē savstarpējo atkarību. Rezultāts? Jūsu semantiskie un specifiskie marķieri nonāk ar primitīvām vērtībām, pārkāpjot paredzēto hierarhiju.

Pēc savas pieredzes es saskāros ar šo problēmu, gatavojot dizaina pilnvaras vairākām operētājsistēmām. Man bija nepieciešams risinājums, kas saglabāja manu JSON failu savstarpēji saistīto struktūru, vienlaikus nodrošinot izvades optimizāciju ieviešanai. 🚀

Šajā rokasgrāmatā es jums pastāstīšu, kā konfigurēt Style Dictionary, lai uzturētu šīs attiecības, nodrošinot, ka jūsu marķieri paliek tik savstarpēji saistīti, kā paredzēts. Neatkarīgi no tā, vai esat iesācējs marķieru izstrādē vai līdzīgas problēmas novēršanā, šīs atziņas būs nenovērtējamas. Iegremdējamies! 😊

Hierarhiskā dizaina marķiera eksporta apgūšana

Piedāvātajos skriptos galvenais mērķis ir saglabāt dizaina marķieru hierarhisko struktūru vairākos līmeņos — primitīvajā, semantiskajā un specifiskajā. Izmantojot Stila vārdnīcu, mēs ieviešam pielāgotas transformācijas un formātus, lai nodrošinātu to, ka eksportēšanas procesa laikā tiek saglabātas attiecības starp marķieriem. Piemēram, metode "registerTransform" pielāgo to, kā tiek ģenerēti pilnvaru nosaukumi, izmantojot strukturētu formātu, pamatojoties uz to kategoriju, veidu un vienuma atribūtiem. Šis hierarhiskais nosaukums nodrošina tokenu kompilāciju skaidrību un konsekvenci. 🛠️

Vēl viena svarīga funkcija ir 'registerFormat' metode, kas ļauj eksportēt marķierus strukturētā JSON failā. Šis formāts saglabā marķiera attiecības, kas definētas sākotnējā ievadē, tādējādi atvieglojot to ieviešanu dažādās platformās. Iedomājieties, ka strādājat pie liela projekta, kurā semantiskie marķieri, piemēram, "primārā krāsa", atsaucas uz primitīviem marķieriem, piemēram, "blue-500" — šīs attiecības saglabāšana kompilācijas laikā ir būtiska, lai novērstu ieviešanas kļūdas. Izmantojot šīs funkcijas, Style Dictionary kļūst par spēcīgu rīku marķiera integritātes uzturēšanai.

Python balstītajā skriptā mēs izmantojam rekursīvu funkciju, lai pārvietotos pa ligzdotām vārdnīcām, saglabājot hierarhiju dizaina marķieru pārveidošanas laikā. Piemēram, ja marķieris "button.primary.background" atsaucas uz marķieri "color.primary", funkcija nodrošina, ka šīs attiecības paliek neskartas. Šī metode ir īpaši noderīga komandām, kurām jāstrādā ar dizaina marķieriem ārpus JavaScript ekosistēmas, jo Python piedāvā lielu elastību JSON failu apstrādei. 🚀

Visbeidzot, vienību testu integrācija, izmantojot JavaScript skriptu Chai, pievieno kritisku verifikācijas līmeni. Šie testi nodrošina, ka marķieri ne tikai tiek pareizi apkopoti, bet arī saglabā paredzētās attiecības. Piemēram, viens tests pārbauda, ​​vai semantiskie marķieri atsaucas uz primitīvām vērtībām, kā paredzēts, bet otrs nodrošina, ka apkopotajā izvadē ir visi trīs līmeņi — primitīvais, semantiskais un specifiskais. Izmantojot šos skriptus un praksi, projektēšanas sistēmas var efektīvi mērogot, vienlaikus saglabājot konsekvenci dažādās platformās, izvairoties no iespējamām kļūmēm un ietaupot izstrādes laiku. 😊

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

Token attiecību saglabāšana dažādās platformās

Viens no aizmirstajiem aspektiem darbā ar dizaina marķieriem ir to saderības nodrošināšana ar dažādām platformām, piemēram, tīmekli, iOS un Android. Lai gan tādi rīki kā Stila vārdnīca ir spēcīgi, tiem nepieciešama rūpīga konfigurācija, lai nodrošinātu, ka marķieri saglabā paredzēto struktūru. Piemēram, semantiskiem marķieriem, piemēram, “button.primary”, ir jāatsaucas uz primitīviem marķieriem, piemēram, “color.blue”, nevis jākodē to vērtības. Šī savstarpējā saistība ļauj izstrādātājiem veikt izmaiņas primitīvā līmenī un redzēt atjauninājumus, kas atspoguļoti visos atkarīgajos marķieros. 🌐

Lai panāktu platformai specifisku savietojamību, katrai izvadei var pielāgot pielāgotas transformācijas un formātus. Tas nodrošina, ka marķieri ir ne tikai konsekventi, bet arī optimizēti platformas vietējā stila konvencijām. Piemēram, operētājsistēmā iOS var būt nepieciešami marķieri .plist formātā, savukārt tīmekļa izstrādātāji dod priekšroku JSON vai CSS mainīgajiem. Izmantojot šos specializētos rezultātus, tiek saglabāta marķiera integritāte, vienlaikus racionalizējot ieviešanu dažādām komandām. Koncentrējoties uz šiem aspektiem, komandas var izveidot mērogojamas, platformu agnostiskas dizaina sistēmas. 🚀

Vēl viens svarīgs apsvērums ir versiju kontroles un sadarbības darbplūsmu integrēšana. Saglabājot marķieru failus versijas kontrolētā repozitorijā un apvienojot tos ar CI/CD konveijeriem, tokenu atjauninājumus var pārbaudīt un izvietot automātiski. Tas nodrošina, ka marķieri paliek atjaunināti visās platformās bez manuālas iejaukšanās, samazinot kļūdas un saglabājot dizaina sistēmas integritāti. Šāda automatizācija ne tikai ietaupa laiku, bet arī atbalsta augošās komandas, kas apstrādā sarežģītas marķieru hierarhijas. 😊