Aynı sayfada iki farklı görev
Bir yazı sayfası düşünelim. Başlık, tarih ve paragraflar ziyaretçi bir şey yapmadan okunabilir. Yanındaki tema düğmesi ise tıklanınca değişmeli, tercihi hatırlamalı ve ekranı güncellemelidir. İkisi aynı sayfada bulunur ama aynı araçlara ihtiyaç duymaz. Next.js’in App Router yapısındaki Server ve Client Component ayrımı bu görevleri birlikte tasarlamamızı sağlar.
Sayfalar ve layout’lar varsayılan olarak Server Component’tir. İçeriği hazırlayan bu bileşenlerin kodu tarayıcıya gönderilmez. Bir yazı listesini oluşturmak için ziyaretçinin cihazında ayrıca bir veri işleme katmanı çalıştırmanız gerekmeyebilir. Bu yaklaşımın amacı her sayfayı karmaşık bir sunucu uygulamasına çevirmek değil, işi uygun yerde yapmaktır.
Etkileşim gereken yere küçük bir sınır çizin
React durumu, tıklama olayları veya tarayıcı API’leri gereken bileşenin dosyasına use client yönergesi eklenir. Tema düğmesi buna iyi bir örnektir. Yazının tamamını bu sınırın içine almak yerine, düğmeyi ayrı bir bileşen olarak tutabilirsiniz. Sınır, bileşenin doğrudan içe aktardığı modülleri de istemci tarafına taşıdığı için dosyanın neyi import ettiği önemlidir.
Bu, ekranda bir Client Component’in altında görünen her şeyin otomatik olarak istemci koduna dönüşmesi demek değildir. Sunucuda hazırlanmış içerik, children gibi bir prop üzerinden etkileşimli bir kapsayıcıya verilebilir. Dosyanın içe aktardığı kod ile ekranda kapsadığı içerik arasındaki farkı görmek, sınırı gereksiz yere büyütmeyi önler.
Client Component yalnızca tarayıcıda çalışmaz
İlk ziyaret sırasında Next.js, Client Component’ler için de önceden HTML üretebilir. Sonrasında tarayıcıdaki React bu HTML’e etkileşimi bağlar; bu adıma hydration denir. Dolayısıyla use client yazmak, bileşenin ilk render’ında window veya localStorage kullanmayı kendiliğinden güvenli hale getirmez. Kodun sunucuda da değerlendirilebileceğini hesaba katmak gerekir.
Örnekteki tema düğmesi, tarayıcıdaki tercihi bir effect içinde okuyabilir. Ancak ilk çizimle sonraki görünüm arasındaki farkı da düşünmelisiniz: Sayfa kısa bir an yanlış temada görünüyor mu? İlk HTML ile tarayıcının ilk çıktısı uyuşuyor mu? Küçük bir düğme üzerinden bu soruları denemek, ayrımı ezberlemekten daha öğreticidir.
Server demek her istekte sunucu demek mi?
Hayır. Statik dışa aktarımda Server Component’ler derleme sırasında çalışır. Üretilen HTML ve diğer dosyalar, çalışan bir Next.js sunucusu gerekmeksizin statik hosting üzerinden sunulabilir. Bu sitedeki yazılar da bu şekilde hazırlanır. Bir Server Component görmek, o sayfanın her ziyarette yeniden üretildiği anlamına gelmez.
Buna karşılık ziyaretçiye özel çerez okumak veya istek sırasında sunucuda işlem yapmak farklı bir yayın modeli gerektirir. Statik export, uygulamanıza sonradan bir API sunucusu eklemez. Bir iletişim formu tasarlarken de aynı soruyu sorun: Bu form yalnızca e-posta taslağı mı açacak, yoksa bir servise gerçekten veri mi gönderecek? Arayüz birbirine benzese de altyapı ihtiyacı değişir.
Tarayıcıya ne gönderdiğinizi kontrol edin
Ortam değişkenlerine NEXT_PUBLIC_ öneki vermek, ilgili değerin tarayıcıya gönderilen JavaScript’e eklenebilmesini sağlar. Bu nedenle gizli erişim bilgilerini bu önekle tanımlamayın. Bir değişkenin .env dosyasında bulunması tek başına gizlilik sağlamaz; nerede kullanıldığına da bakmak gerekir.
Sunucuda okunan bir bilgiyi Client Component’e prop olarak verirseniz o veri tarayıcıya taşınabilir. Aynı şekilde gizli bir değeri sayfa metnine yazdırmak, kod sunucuda çalışsa da onu görünür kılar. Yazı sayfası örneğinde yalnızca başlık, tarih ve gövde gerekir. Veriyi hazırlarken arayüzün ihtiyaç duyduğu alanları seçmek, hem bu sınırı hem de kodu anlaşılır tutar.
- Okunan içerikle etkileşimli davranışı ayrı düşünün.
- use client sınırını ihtiyacı olan bileşende başlatın.
- Doğrudan sayfa açılışını ve sayfalar arası geçişi birlikte deneyin.
- Yayın modelini, ihtiyaç duyduğunuz sunucu işlemleriyle birlikte seçin.
Kaynaklar ve devamı
Konuyu biraz daha kurcalamak istersen, bu yazıda yararlandığımız resmî dokümanlar burada.