Design Systems & Component Libraries · Ders

Bileşenler İçin Adlandırma Kuralları

Bileşenleri ve özelliklerini açık ve tutarlı biçimde adlandırmanın, bir bileşen kitaplığını nasıl keşfedilebilir, öngörülebilir ve sürdürülebilir kıldığını öğrenin.

Bileşenler İçin Adlandırma Kuralları, 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 Names Matter

The hardest problems in component libraries are not technical - they are naming. A poorly named component is hard to find, easy to misuse, and painful to rename later.

Good names act as documentation and reduce the questions teammates ask.

Be Descriptive, Not Clever

Name components by what they are or do, not by clever metaphors.

Good: UserAvatar, PrimaryButton
Avoid: Blob, Sparkle, Thingy

A new teammate should guess the purpose from the name alone.

Consistent Casing

Pick one casing rule and never deviate. The web convention:

Components: PascalCase (CardHeader)
Props: camelCase (isDisabled)
CSS classes: kebab-case (card-header)

Mixing casing styles erodes trust in the library.

Boolean Props

Boolean props read best with an is, has, or should prefix. They sound like questions and default to false.

The snippet below shows the pattern.

function describe(props) {
  return 'disabled=' + props.isDisabled + ', loading=' + props.isLoading;
}

console.log(describe({ isDisabled: true, isLoading: false }));

Prop Naming Patterns

Establish predictable prop names across all components:

variant for visual style (primary, ghost)
size for scale (sm, md, lg)
onChange, onClick for event handlers

If every component uses the same names, learning one teaches you all.

Avoid Implementation Details

Do not bake fragile details into names. BlueButton becomes a lie the moment the brand color changes.

Prefer intent-based names like PrimaryButton. The intent is stable even when the styling evolves.

Namespacing and Prefixes

Many systems prefix components to avoid clashes and signal origin: DsButton, AcmeCard.

This helps when consuming apps already have their own components. Choose a short prefix and apply it everywhere or nowhere - consistency over preference.

Compound Component Naming

Related parts should share a family name: Card, CardHeader, CardBody, CardFooter.

The shared prefix groups them in autocomplete and signals they belong together. This is far clearer than Card, Heading, Content.

Renaming Is Expensive

Once a component name ships, every consuming app depends on it. Renaming becomes a breaking change requiring deprecation cycles.

Invest time in the name up front. A 10-minute naming discussion saves months of migration pain.

Document the Rules

Write your naming conventions down in the contribution guide. New contributors should not have to reverse-engineer your patterns.

A short, enforced naming doc keeps the library coherent as more people contribute.

Names as a Contract

Ultimately, a component's name and prop names form a public API contract. Treat them with the same care as any API.

Predictable names let developers compose your library confidently without reading the source.

Quick Check

Test your naming instincts.

Recap

You learned naming conventions that keep a component library usable:

Be descriptive and intent-based, not clever or color-bound.
Use consistent casing and predictable prop names.
Group compound components with shared prefixes.
Document the rules and remember renaming is costly.

Good names are quiet documentation.

Sıkça Sorulan Sorular

“Bileşenler İçin Adlandırma Kuralları” dersi ücretsiz mi?

Evet — “Bileşenler İçin Adlandırma Kuralları” 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.

“Bileşenler İçin Adlandırma Kuralları” dersinde ne öğreneceğim?

Bileşenleri ve özelliklerini açık ve tutarlı biçimde adlandırmanın, bir bileşen kitaplığını nasıl keşfedilebilir, öngörülebilir ve sürdürülebilir kıldığını öğrenin. 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.

“Bileşenler İçin Adlandırma Kuralları” 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

← Design Systems & Component Libraries Sayfasına Dön