Laravel 5.4 ve Blade ile bileşen düşünmek

Bir süre sonra her Laravel projesinde şu manzarayla karşılaşıyorsunuz: onlarca Blade dosyası var, hepsi benzer HTML blokları taşıyor, bir yerde ufak bir değişiklik yapınca diğer yerleri gözden kaçırıyorsunuz. Kopyala-yapıştır ile büyüyen görünüm katmanı, uygulamanın en bakımsız köşesi haline geliyor.

Laravel 5.4 bu duruma bir çözüm getirdi: @component direktifi. Bunu ilk gördüğümde “zaten @include vardı, ne farkı var?” diye düşündüm. Ama kullandıkça aradaki farkın önemli olduğunu anladım.

@include ile @component arasındaki fark

@include bir Blade dosyasını olduğu gibi içine alır; değişken aktarmak için ikinci parametre olarak dizi verir ya da üst şablonun değişkenlerini kullanırsınız. Basit tekrarlar için yeterli.

@component ise bir component kavramı getirir. İçerik, bileşene @slot ile iletilir; bileşen bu içeriği {{ $slot }} ile yerleştirir. Ayrıca adlandırılmış slot’lar tanımlayabilirsiniz — başlık, eylem butonu, alt bilgi gibi bölgeler ayrı slot’lara gider.

{{-- resources/views/components/card.blade.php --}}
<div class="card">
    <div class="card-header">
        {{ $header }}
    </div>
    <div class="card-body">
        {{ $slot }}
    </div>
</div>

Kullanımı:

@component('components.card')
    @slot('header')
        Kullanıcı Bilgileri
    @endslot

    <p>Ad: {{ $user->name }}</p>
    <p>E-posta: {{ $user->email }}</p>
@endcomponent

Şablonun neye benzeyeceğini, neyin nereye gideceğini okurken kolayca anlıyorsunuz. HTML parçası artık bir “kapsayıcı” değil, belirli bir sözleşmesi olan küçük bir birim.

@include ile aynı işi yapmaya çalışsaydınız, üst şablonun tüm değişkenlerine bileşenin erişimi olurdu ve hangi değişkenin “bileşenin kendi verisi” hangisinin “üst sayfa bağlamından sızan veri” olduğu muğlaklaşırdı. @component bu sınırı net çiziyor: bileşen yalnızca kendine açıkça verileni biliyor.

Neden bu yaklaşım işe yarıyor?

Gerçek projede bir uyarı (alert) bileşeni oluşturduğumda farkı net gördüm. Uygulamanın onlarca yerinde “başarı”, “hata”, “bilgi” uyarı kutularına ihtiyaç var. Renk, ikon, stil hepsi aynı — yalnızca mesaj ve tip değişiyor.

{{-- resources/views/components/alert.blade.php --}}
<div class="alert alert-{{ $type ?? 'info' }}">
    {{ $slot }}
</div>

Artık her yerde şunu yazıyorum:

@component('components.alert', ['type' => 'success'])
    Profiliniz başarıyla güncellendi.
@endcomponent

CSS sınıfı değişecekse tek dosyayı açıyorum. Yeni bir tip ekleyeceksem yine tek yer. Bakım yükü gerçekten azalıyor.

Bunu ilk kez denediğimde küçük ama somut bir şeyi fark ettim: “uyarı kutusunu değiştireceğim, kaç yerde kullandım?” sorusunu sormak zorunda kalmadım. Bileşen, sorunun cevabını gereksiz kılıyor.

Bileşen mi, include mi?

Her yerde bileşen kullanmak gerekmiyor. Basit, parametresiz kısmi görünümler için @include hâlâ daha net. Ama bir HTML bloğu şu koşulları taşıyorsa bileşene taşımak mantıklı:

• Birden fazla sayfada kullanılıyor.
• İçeriği dışarıdan geliyor (değişken metin, eylem).
• Farklı bağlamlarda farklı görünüm alıyor (tip parametresi gibi).

Bu soruları sormak, görünüm katmanını daha bilinçli bölmeme yardımcı oldu.

Bir tuzak da var: her şeyi bileşen yapmak. Yalnızca bir yerde kullanılan, parametresiz bir parça için bileşen oluşturmak, yeni bir dosya açıp ek bir soyutlama katmanı getiriyor; okunabilirliği kolaylaştırmak yerine zorlaştırıyor. Bileşen kararını “birden fazla yerde mi kullanılıyor?” sorusuna bağlamak, bu aşırılığı önlüyor.

Tasarım sistemi tohumları

Düzgün adlandırılmış ve belgelenmiş birkaç bileşen, zamanla küçük bir tasarım sistemi çekirdeği oluşturuyor. card, alert, modal, form-group gibi bileşenler bir kez iyi yazılınca uygulamanın görsel tutarlılığını neredeyse otomatik olarak koruyor.

Bu alışkanlık, zamanla şablon dosyalarını okurken de farklı bir bakış açısı getirdi. Bir Blade dosyasına baktığımda artık “bu HTML ne işe yarıyor?” değil, “bu bileşenler nasıl birleşiyor?” diye soruyorum. Küçük bir zihin kayması ama görünüm katmanını daha uzun süre bakımı kolay tutuyor.

Laravel 5.4 ile gelen bu direktifin büyük bir yenilik olduğunu söylemek istemiyorum — Vue tarafında bileşen mantığı çok daha güçlü. Ama sunucu taraflı Blade şablonlarında, fazla karmaşıklık getirmeden yeniden kullanılabilirlik kazanmanın en temiz yolu bu oldu benim için.