UI Bileşeni (Component) Nedir?

Bir bileşenin anatomisi

"Buton" dediğimiz şey, bileşen olarak ele alındığında tek bir görselden çok daha fazlasıdır:

• Arayüz (props): Bileşeni kullanan kişinin değiştirebildiği şeyler; örneğin variant, size, disabled.
• Durumlar: Varsayılan, üzerine gelme, klavye odağı, basılı, devre dışı, yükleniyor, hata. Tasarım dosyasında çizilmeyen her durum, kodda geliştiricinin tahminine kalır.
• Varyantlar: Birincil, ikincil, metin butonu gibi aynı işlevin görsel çeşitleri.
• Slotlar: İçine başka içerik (ikon, metin, alt bileşen) yerleştirilebilen alanlar.
• Erişilebilirlik sözleşmesi: Doğru HTML öğesi, görünür odak halkası, ekran okuyucu için anlamlı ad.

Koddaki karşılığı: React ile bir buton

type ButtonProps = {
  variant?: "primary" | "secondary";
  loading?: boolean;
  children: React.ReactNode;
} & React.ButtonHTMLAttributes<HTMLButtonElement>;

export function Button({ variant = "primary", loading = false, children, ...rest }: ButtonProps) {
  return (
    <button
      type="button"
      {...rest}
      className={"btn btn-" + variant}
      aria-busy={loading || undefined}
      disabled={loading || rest.disabled}
    >
      {children}
    </button>
  );
}

Bu küçük bileşen birkaç kararı herkes adına bir kez verir: gerçek <button> öğesi kullanılır (klavye ve ekran okuyucu desteği hazır gelir), form içinde istemeden gönderim yapmasın diye type="button" varsayılandır, yükleme durumu ARIA ile duyurulur. Renk ve boşluk gibi değerler ham sayılar yerine design token'lardan gelir. Bileşeni kullanan ekip bu ayrıntıları bilmek zorunda kalmaz.

İyi bir bileşen arayüzü nasıl olur?

Bileşenin props listesi küçük bir API gibidir; kötü tasarlanırsa her kullanımda sorun çıkarır. Genel ilkeler:

• Az ve anlamlı parametre. isBig, isRed, hasIcon, isRounded gibi birbirinden bağımsız onlarca boolean, test edilmemiş yüzlerce kombinasyon üretir. Birbirini dışlayan seçenekler tek bir variant değerinde toplanmalıdır.
• Yapılandırma yerine kompozisyon. Her yeni ihtiyaç için prop eklemek yerine, içeriği children veya slotlarla dışarıdan almak bileşeni sade tutar.
• Stilin dışarı sızmaması. Bileşenin görünümü, kullanıldığı sayfanın CSS'ine bağlı olmamalıdır; aksi hâlde aynı bileşen iki sayfada farklı görünür.
• Belgelenmiş durumlar. Her durumun nasıl göründüğü ve ne zaman kullanılacağı yazılmalıdır.

Framework bileşeni ve Web Components

Bileşen fikri bir framework'e ait değildir. React, Vue, Svelte ve Angular kendi bileşen modellerini sunar; React'te bileşenler bir sonraki render'da ne çizileceğini tarif eder, kütüphane de değişiklikleri sanal DOM karşılaştırmasıyla sayfaya uygular. Tarayıcıların yerleşik Web Components standartları (custom elements, shadow DOM, template) ise framework'ten bağımsız, her sayfada çalışabilen bileşenler yazmaya izin verir. Hangisi seçilirse seçilsin, bileşenin değeri sözleşmesinin tutarlılığından gelir.

Bileşen kütüphanesinden tasarım sistemine

Tek tek bileşenler bir kütüphanede toplanır; bu kütüphane, token'lar, kullanım yönergeleri ve sahiplik süreciyle birleştiğinde bir tasarım sistemi ortaya çıkar. Bileşenlerin hangi büyüklük seviyesinde düşünüleceğini sınıflandırmak için sık kullanılan bir zihinsel model de atomik tasarımdır. Sık görülen bir hata, div'lerle "buton görünümlü" öğeler üretmek ya da aynı işi yapan üç farklı kart bileşenini yan yana yaşatmaktır; ikisi de bileşen yaklaşımının sağladığı tutarlılığı ortadan kaldırır.