Belirteç Adlandırma ve Katmanlı Belirteç Mimarisi
Tasarım belirteçlerinizi, değişikliklere dayanıklı adlandırmayla ölçeklenebilir bir katmanlı mimaride (ilkel, anlamsal ve bileşen belirteçleri) yapılandırın.
Belirteç Adlandırma ve Katmanlı Belirteç Mimarisi, CoddyKit'te ücretsiz bir Design Systems & Component Libraries dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Design Systems & Component Libraries öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Design Systems & Component Libraries kursu toplamda 4 dersten oluşur.
Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.
Why Token Architecture Matters
A flat list of color tokens works at first, then collapses as the system grows. A tiered token architecture keeps tokens scalable and meaningful.
This lesson builds on implementing tokens by structuring and naming them well.
Tier 1: Primitive Tokens
Primitive (or global) tokens are raw values: blue-500 = #3b82f6, space-4 = 16px.
They are the full palette of available values, named by what they are, with no opinion about where they are used.
Tier 2: Semantic Tokens
Semantic (or alias) tokens describe intent: color-action-primary, color-text-danger.
They reference primitives but add meaning. Components use semantic tokens, so re-theming means repointing aliases, not editing every component.
Tier 3: Component Tokens
Component tokens scope values to a specific component: button-background-color, card-padding.
They reference semantic tokens. The chain below shows the three tiers resolving down to a raw value.
const primitive = { 'blue-500': '#3b82f6' };
const semantic = { 'color-action-primary': 'blue-500' };
const component = { 'button-bg': 'color-action-primary' };
function resolve(token) {
let v = component[token] || semantic[token] || token;
v = semantic[v] || v;
return primitive[v] || v;
}
console.log(resolve('button-bg'));The Power of Indirection
Why three tiers? Indirection. Change color-action-primary from blue to green once, and every button, link, and focus ring updates.
Without semantic tokens you would hunt down every hardcoded blue. Tiers turn sweeping changes into one edit.
Naming That Survives Change
Name semantic tokens by role, never by value. color-success survives a palette change; color-green becomes a lie.
The same rule applies to primitives - prefer blue-500 over brand-blue if the brand might shift.
A Consistent Naming Schema
Adopt a predictable pattern: category-property-variant-state, e.g. color-text-link-hover.
When every token follows the same grammar, developers can guess token names instead of searching docs. Consistency is the goal.
Avoiding Over-Tokenization
Not everything needs a token. Tokenizing every one-off value creates noise and maintenance burden.
Tokenize values that repeat or carry meaning. A truly unique magic number can stay inline with a comment.
Themes Live at the Semantic Tier
Light, dark, and brand themes differ at the semantic layer. Primitives stay constant; semantic aliases repoint per theme.
This is why the tier structure makes multi-theme support nearly free - you swap one mapping table.
Documenting the Hierarchy
Show the token chain in your docs: which primitive a semantic token points to, and which components consume it.
This transparency helps contributors choose the right tier and understand the ripple effect of a change.
Architecture That Scales
A tiered, well-named token system scales from one product to dozens of themed, white-labeled apps without rework.
The structure is the difference between tokens that empower and tokens that become technical debt.
Quick Check
Test your token architecture knowledge.
Recap
You structured design tokens into a scalable architecture:
- Primitive tokens hold raw values.
- Semantic tokens add intent; components reference these.
- Component tokens scope values per component.
- Name by role, follow a consistent schema, and avoid over-tokenizing.
Tiered tokens make sweeping design changes a single edit.
Sıkça Sorulan Sorular
“Belirteç Adlandırma ve Katmanlı Belirteç Mimarisi” dersi ücretsiz mi?
Evet — “Belirteç Adlandırma ve Katmanlı Belirteç Mimarisi” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Design Systems & Component Libraries kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Design Systems & Component Libraries kursu toplamda 4 dersten oluşur.
“Belirteç Adlandırma ve Katmanlı Belirteç Mimarisi” dersinde ne öğreneceğim?
Tasarım belirteçlerinizi, değişikliklere dayanıklı adlandırmayla ölçeklenebilir bir katmanlı mimaride (ilkel, anlamsal ve bileşen belirteçleri) yapılandırın. Design Systems & Component Libraries ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.
Design Systems & Component Libraries öğrenmeye başlamak için deneyim gerekli mi?
Önceden deneyim gerekmez. CoddyKit'te Design Systems & Component Libraries, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.
“Belirteç Adlandırma ve Katmanlı Belirteç Mimarisi” dersi ne kadar sürer?
Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.
Bu Design Systems & Component Libraries dersinde kod yazıp çalıştırabilir miyim?
Evet. Her Design Systems & Component Libraries dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.
Bu kursun tüm dersleri
- Tasarım Belirteçleri Nedir
- Tasarım Belirteçlerini Uygulama
- Tasarımdan Koda İş Akışlarını Otomatikleştirme
- Belirteç Adlandırma ve Katmanlı Belirteç Mimarisi