React Server Components Nedir, Nasıl Çalışır?
React Server Components (RSC), bileşenleri doğrudan sunucuda işleyerek istemci tarafındaki JavaScript yükünü azaltan ve SEO performansını artıran modern bir web mimarisidir.

İÇİNDEKİLER
%0 okundu
- React Server Components Mimarisine Kurumsal Bir Bakış
- React Server Components Mimarisi Nasıl Çalışır?
- Kritik Karşılaştırma: RSC ve Geleneksel SSR Arasındaki Farklar
- Server Components ve Client Components Ayrımı
- Kurumsal Projelerde RSC Kullanımının Avantajları
- RSC Entegrasyonunda Dikkat Edilmesi Gereken Riskler ve Kısıtlamalar
- Sonuç: React Server Components ile Geleceğin Web Altyapısına Hazırlık
React Server Components (RSC), modern web mimarisinde istemci tarafındaki JavaScript yükünü azaltarak uygulama performansını optimize etmeyi hedefleyen yenilikçi bir yaklaşımdır. Geliştiricilerin sıklıkla araştırdığı React Server Components Nedir, Nasıl Çalışır? sorusu, hem kullanıcı deneyimini hem de arama motoru optimizasyonunu doğrudan etkileyen teknik bir dönüşüme işaret eder. Bu mimari, bileşenlerin doğrudan sunucuda işlenmesini sağlayarak istemciye yalnızca gerekli minimum kodun gönderilmesini mümkün kılar. Teknik karar vericiler, CTO'lar ve yazılım mimarları için sayfa yüklenme hızlarını iyileştiren, veri çekme süreçlerini optimize eden ve kurumsal web projelerinde altyapı maliyetlerini düşüren bu yapıyı anlamak kritik bir gerekliliktir.
React Server Components Mimarisine Kurumsal Bir Bakış
Geleneksel web uygulamalarında kullanıcı arayüzlerinin oluşturulması büyük ölçüde tarayıcı üzerindeki işlem gücüne dayanmaktaydı. İstemci tarafı oluşturma (CSR) olarak adlandırılan bu yaklaşımda, tarayıcı ilk istekte boş bir HTML sayfası alır ve ardından büyük JavaScript paketlerini (bundle) indirip çalıştırarak sayfayı inşa eder. Bu durum özellikle düşük donanımlı mobil cihazlarda ve zayıf internet bağlantılarında ciddi bir ilk yüklenme gecikmesine (FCP - First Contentful Paint) yol açmaktadır. Büyük ölçekli kurumsal projelerde, artan özellik setleriyle birlikte büyüyen JavaScript payload miktarı, projelerin sürdürülebilirliğini ve performansını olumsuz yönde etkilemektedir.
Sunucu tarafı oluşturma (SSR) ise bu sorunu çözmek adına, sunucuda dinamik olarak oluşturulan HTML çıktısını tarayıcıya göndererek kullanıcının sayfayı hızlıca görmesini sağlar. Ancak SSR mimarisinde de sayfanın etkileşimli hale gelebilmesi için tüm bileşen ağacının tarayıcıda yeniden çalıştırılması, yani hydration süreci gereklidir. Hydration süreci, sunucudan gelen HTML ile istemcideki JavaScript kodunu eşleştirirken tarayıcının ana iş parçacığını (main thread) bloke edebilir. Bu durum, kullanıcının sayfayı görmesine rağmen butonlara tıklayamaması veya formları dolduramaması gibi etkileşim gecikmelerine neden olur.
React Server Components (RSC), bu iki yaklaşımın sınırlarını aşmak üzere geliştirilmiş yeni nesil bir mimaridir. Bu yapıda, bileşenler sunucu tarafında çalıştırılır ve istemciye herhangi bir JavaScript kodu gönderilmeden doğrudan serialize edilmiş (serileştirilmiş) bir veri akışı olarak iletilir. Bu sayede, yalnızca etkileşimli olması gereken küçük bileşenlerin JavaScript kodları tarayıcıya taşınır. Kurumsal ölçekteki e-ticaret platformları, içerik yönetim sistemleri ve yüksek trafikli kurumsal portallar için RSC, hem istemci yükünü hafifleten hem de sunucu kaynaklarını optimize eden dengeli bir mimari sunar.
React Server Components Mimarisi Nasıl Çalışır?
React Server Components mimarisinin çalışma prensibi, sunucu ve istemci ortamlarının yeteneklerini tek bir bileşen ağacı (component tree) üzerinde birleştirmeye dayanır. Bu mimaride, projedeki her bir dosya varsayılan olarak bir "Server Component" olarak kabul edilir. Geliştirici, tarayıcı etkileşimi gerektiren bölümleri ise açıkça "Client Component" olarak işaretler. Sunucu tarafında başlayan bu süreç, tarayıcıya kadar uzanan optimize edilmiş bir veri akışı ile tamamlanır.
Sunucu ve İstemci Arasındaki İş Yükü Dağılımı
Sunucu ve istemci arasındaki iş yükünün dağıtılması, uygulamanın genel performansını belirleyen en önemli unsurdur. Sunucu bileşenleri, arka planda Node.js veya benzeri bir sunucu çalışma ortamında (runtime) yürütülür. Bu bileşenler dosya sistemine doğrudan erişebilir, güvenli mikro servislerle iletişim kurabilir ve veritabanı sorgularını doğrudan çalıştırabilir.
İstemci bileşenleri ise tarayıcıda çalıştırılmak üzere paketlenir. Sunucu bileşenleri, istemci bileşenlerini kendi içlerinde alt bileşen (children) olarak barındırabilir. Bu yapı kurulurken, sunucudan istemciye geçiş sınırları (boundaries) derleyici tarafından tespit edilir. Böylece, yalnızca etkileşimli dinamik düğümler için JavaScript kodu üretilirken, statik veya sunucuda çözümlenmiş düğümler için sıfır istemci kodu (Zero-bundle size) felsefesi uygulanır.
Veri Çekme (Data Fetching) ve Veritabanı Etkileşimi
Veri çekme (data fetching) süreçleri, geleneksel React uygulamalarında genellikle karmaşık durum yönetimleri, useEffect kancaları ve harici API uç noktaları (endpoints) gerektirmekteydi. Bu durum, hem istemci tarafında çok sayıda ağ isteği (network latency) oluşmasına hem de veri çekme mantığının istemci koduna sızarak güvenlik açıkları yaratmasına neden olmaktaydı.
RSC mimarisinde ise veri çekme işlemleri doğrudan bileşen seviyesinde async/await yapısı kullanılarak gerçekleştirilir. Sunucu bileşeni, doğrudan veritabanı sorguları yürütebilir veya yerel ağdaki güvenli mikro servislere istek atabilir. Bu durum, tarayıcı ile sunucu arasındaki gidiş-dönüş (roundtrip) süresini ve ağ gecikmesini ortadan kaldırarak verilerin çok daha hızlı yüklenmesini sağlar. Sunucu ortamı, veritabanına coğrafi olarak çok daha yakın konumlandığı için milisaniyeler mertebesinde veri transferi mümkün hale gelir.
İstemciye İletilen Optimize Edilmiş Veri Formatı
Sunucuda işlenen Server Component'lar, istemciye standart bir HTML dizesi (string) olarak gönderilmez. Bunun yerine, React Virtual DOM yapısını temsil eden özel, serileştirilmiş bir JSON benzeri akış formatı (RSC Payload) kullanılır. Bu akış formatı, aşağıdaki bilgileri içerir:
Sunucu bileşenlerinin işlenmiş çıktısı (HTML etiketleri ve prop değerleri).
İstemci bileşenlerinin yerleştirileceği yer tutucular (placeholders) ve bu bileşenlerin çalıştırılması için gerekli JavaScript dosyalarının referansları.
Sunucudan istemciye aktarılan tüm prop verileri.
Bu akış formatının en büyük avantajı, tarayıcı tarafında mevcut sayfa durumunu (state) bozmadan arayüzün güncellenebilmesidir. Örneğin, bir form alanına yazı yazan bir kullanıcı, sayfa içeriği sunucudan gelen yeni verilerle güncellense dahi yazdığı metni ve odaklanma durumunu (focus state) kaybetmez. HTML tabanlı geleneksel SSR yaklaşımlarında bu düzeyde bir dinamik birleştirme ve durum koruma işlemi gerçekleştirmek oldukça zordur.
Kritik Karşılaştırma: RSC ve Geleneksel SSR Arasındaki Farklar
Web geliştirme ekosisteminde Server-Side Rendering (SSR) ile React Server Components (RSC) kavramları sıklıkla birbirine karıştırılmaktadır. Her iki teknoloji de sunucu kaynaklarını kullansa da, uygulama mimarisindeki rolleri, çalışma zamanı dinamikleri ve istemciye etkileri açısından köklü farklılıklar barındırırlar. SSR bir sayfa yükleme yöntemi iken, RSC bir bileşen yazma ve yürütme modelidir.
Geleneksel SSR modelinde, kullanıcının sayfaya yaptığı ilk istekte sunucu tüm React bileşen ağacını baştan sona çalıştırır ve ham bir HTML belgesi oluşturur. Bu HTML, tarayıcıya gönderilir ve hızlı bir görsel render sağlanır. Ancak, sayfa yüklendikten sonra etkileşimi devralacak olan istemci tarafı JavaScript paketlerinin de tamamen indirilmesi ve hydration sürecinin tamamlanması gerekir. SSR, sonraki sayfa geçişlerinde genellikle istemci tarafı yönlendirmesine (client-side routing) dönüşür ve bu aşamadan sonra sunucu tarafında tekrar bileşen oluşturma işlemi (re-rendering) yapılmaz.
RSC ise uygulamanın yaşam döngüsü boyunca aktiftir. Sunucu bileşenleri, yalnızca ilk yüklemede değil, sayfa içi dinamik yönlendirmelerde ve veri güncellemelerinde de sunucuda çalışmaya devam eder. İstemciye ham HTML yerine serileştirilmiş Virtual DOM verisi gönderildiği için, tarayıcı mevcut DOM ağacını tamamen yıkıp yeniden inşa etmek zorunda kalmaz. Bu durum, özellikle karmaşık formlar, aktif medya oynatıcılar veya kullanıcı etkileşimli arayüzler içeren büyük projelerde sayfa durumunun korunmasını sağlar.
Aşağıdaki tabloda, bu iki mimarinin temel teknik parametreleri ve kurumsal operasyonlara etkileri karşılaştırmalı olarak sunulmuştur:
Server Components ve Client Components Ayrımı
React 18 mimarisi ve sonrasında geliştirilen React 19 standartları, bileşenleri iki temel kategoriye ayırır: Server Components ve Client Components. Geliştirme sürecinde hangi bileşenin hangi kategoride yer alacağını doğru belirlemek, hem uygulamanın performans kalitesini hem de kod mimarisinin temizliğini doğrudan belirler. Yanlış yapılandırmalar, gereksiz kodların istemci paketine dahil edilmesine veya sunucu kaynaklarının israf edilmesine yol açabilir.
Ne Zaman Server Component Tercih Edilmeli?
Server Component'lar, uygulamanın veri yoğunluklu ve statik bölümleri için ideal çözümdür. Varsayılan olarak tüm bileşenler bu kategoride yer aldığı için, geliştiricilerin ekstra bir tanımlama yapmasına gerek yoktur. Aşağıdaki senaryolarda Server Component kullanımı öncelikli tercih olmalıdır:
Veri Çekme İşlemleri: Doğrudan veritabanı sorguları (SQL, ORM) veya dahili API entegrasyonları yapılacağında.
Hassas Bilgi Kullanımı: API anahtarları, özel şifreleme yöntemleri veya sunucu taraflı token doğrulamaları gerektiğinde.
Büyük Bağımlılıklar (Dependencies): Markdown dönüştürücüler, tarih kütüphaneleri veya karmaşık veri formatlayıcılar gibi büyük boyutlu npm paketleri kullanılacağında (Bu paketlerin JavaScript kodları tarayıcıya gönderilmez).
Statik İçerikler: Hakkımızda sayfaları, blog yazıları, ürün listeleme şablonları gibi kullanıcı etkileşimi gerektirmeyen görsel alanlarda.
Ne Zaman Client Component Kullanılmalı?
İstemci bileşenleri, kullanıcı etkileşiminin ve tarayıcı özelliklerinin aktif olarak kullanıldığı durumlarda zorunludur. Bir bileşenin en üst satırına 'use client' yönergesi eklenerek o dosyanın ve onun tüm alt bağımlılıklarının istemci tarafında çalıştırılacağı derleyiciye bildirilir. Aşağıdaki durumlar Client Component kullanımını zorunlu kılar:
Etkileşim ve Olay Dinleyicileri (Event Listeners): @@CODE0@@, @@CODE1@@,
onSubmitgibi kullanıcı aksiyonlarını takip eden fonksiyonların varlığında.Durum ve Yaşam Döngüsü Kancaları: @@CODE0@@, @@CODE1@@, @@CODE2@@, @@CODE3@@ gibi React durum yönetim araçlarının kullanımında.
Tarayıcı API Erişimi: @@CODE0@@, @@CODE1@@, @@CODE2@@, @@CODE3@@,
cookies(istemci tarafı) veya coğrafi konum (geolocation) gibi tarayıcıya özel API'lerin çağrılmasında.Özel Tarayıcı Kütüphaneleri: Sadece tarayıcı ortamında çalışan animasyon motorları veya grafik çizim araçları entegre edildiğinde.
Kurumsal Projelerde RSC Kullanımının Avantajları
Kurumsal ölçekteki dijital ürünlerde performans, güvenlik ve görünürlük doğrudan finansal dönüşüm oranlarını etkileyen parametrelerdir. React Server Components mimarisi, yalnızca teknik bir optimizasyon aracı değil, aynı zamanda iş hedeflerine doğrudan katkı sağlayan stratejik bir altyapı yatırımıdır. Özellikle Next.js App Router gibi modern çatılarla entegre edildiğinde, kurumsal projelerin büyüme ve ölçeklenme hedeflerine katkı sunar.
JavaScript Payload Azaltımı ve Hız Optimizasyonu
Büyük ölçekli web platformlarında en sık karşılaşılan sorunlardan biri, zamanla büyüyen ve yönetilemez hale gelen JavaScript dosyalarıdır. Tarayıcıya gönderilen her kilobaytlık JavaScript kodu, sadece indirme süresini uzatmaz, aynı zamanda mobil cihazların işlemcilerinde de (parse ve compile aşamaları) ek bir yük oluşturur.
RSC mimarisi, sunucuda işlenen bileşenlerin kodlarını istemci paketine dahil etmeyerek sıfır paket boyutu (Zero-bundle size) avantajı sunar. Bu sayede, tarayıcının indirmek ve işlemek zorunda olduğu JavaScript miktarı dramatik bir şekilde düşer. Sayfa yüklenme hızı doğrudan artarken, özellikle düşük donanımlı telefonlar kullanan potansiyel müşterilerin platformda kalma süresi uzar.
Teknik SEO ve Core Web Vitals Metriklerinde İyileşme
Arama motoru botları, web sayfalarını tararken ve dizine eklerken hızlı yüklenen ve içeriği doğrudan HTML yapısında sunan siteleri önceliklendirir. İstemci tarafı oluşturma (CSR) kullanan sitelerde, botlar JavaScript'in çalışmasını beklemek zorunda kaldığından indeksleme süreçlerinde gecikmeler ve hatalar yaşanabilir.
RSC, sunucuda hızlıca hazırlanan zengin içerik yapısı sayesinde SEO performansı için ideal bir zemin hazırlar. Google'ın sıralama kriterleri arasında yer alan Core Web Vitals metriklerinden Largest Contentful Paint (LCP) ve First Contentful Paint (FCP) skorları, sunucudan doğrudan veri yüklü gelen arayüz sayesinde üst seviyelere taşınır. Ayrıca, sayfa yüklenirken yaşanan kaymalar engellendiği için Cumulative Layout Shift (CLS) metriklerinde de olumlu sonuçlar elde edilir.
Hassas Verilerin İzolasyonu ve Güvenlik Standartları
Güvenlik ve KVKK/GDPR uyumluluğu, kurumsal şirketlerin BT altyapılarında en çok dikkat ettiği konuların başında gelir. İstemci tarafında çalışan geleneksel web uygulamalarında, veri çekmek için kullanılan API uç noktaları, veritabanı şema bilgileri ve iş mantığı (business logic) tarayıcı kaynak kodları incelenerek kötü niyetli kişilerce analiz edilebilir.
Server Component'lar, hassas veri güvenliği sağlama noktasında korunaklı bir kalkan görevi görür. Veritabanı bağlantı kodları, özel entegrasyon şifreleri ve şirket içi algoritmalara ait kodlar tamamen sunucu tarafında çalıştırılır ve tarayıcıya asla sızdırılmaz. İstemci yalnızca nihai UI verisini aldığı için, uygulamanın dışarıya açık saldırı yüzeyi (attack surface) minimuma indirilmiş olur.
React Server Components kullanımının avantaj ve dezavantajlarını kurumsal perspektiften değerlendirin. Artılar 2 avantaj Sıfır JavaScript Paket Boyutu Statik bileşenlerin kodları tarayıcıya gönderilmez, yükleme süreleri düşer. Gelişmiş Güvenlik Seviyesi API anahtarları ve veritabanı sorguları sunucu tarafında izole kalır. Eksiler 2 dikkat noktası Artan Sunucu Maliyetleri İş yükünün sunucuya kayması CPU ve bellek tüketimini artırabilir. Karmaşık Öğrenme Eğrisi Geliştirme ekiplerinin sunucu/istemci sınırlarını yönetmeyi öğrenmesi zaman alır.Artılar ve Eksiler
RSC Entegrasyonunda Dikkat Edilmesi Gereken Riskler ve Kısıtlamalar
React Server Components mimarisine geçiş, her ne kadar büyük performans kazanımları vaat etse de, beraberinde belirli teknik zorluklar, tasarım kısıtlamaları ve altyapı riskleri getirmektedir. Kurumsal karar vericilerin ve yazılım mimarlarının, bu mimariyi projelerine dahil etmeden önce mevcut teknik borçları (technical debt) ve ekiplerinin yetkinlik seviyelerini titizlikle analiz etmesi gerekir.
State Yönetimi ve Yaşam Döngüsü (Lifecycle) Kısıtlamaları
Server Component yapısında çalışan bileşenlerin durum (state) bilgisi taşıyamaması, geleneksel React alışkanlıklarını kökten değiştirir. Bir sunucu bileşeni içinde @@CODE0@@ veya @@CODE1@@ gibi durum belirleyiciler kullanılamaz. Bu durum, bileşenlerin dinamik olarak kullanıcı etkileşimine göre kendi içlerinde güncellenemeyeceği anlamına gelir.
Bu kısıtlamayı aşmak için, uygulamanın durum yönetimi mimarisinin yeniden tasarlanması gerekir. Küresel durum yönetim araçları (Redux, Zustand, Recoil vb.) sunucu bileşenlerini doğrudan sarmalayamaz. Geliştiriciler, durum yönetim sınırlarını (state boundaries) çok net belirlemek ve verileri yalnızca istemci yapraklarında (client leaves) veya URL parametreleri (search params) üzerinden yönetmek durumundadır.
Hydration Uyuşmazlıkları ve Hata Ayıklama (Debugging) Zorlukları
Hydration uyuşmazlıkları (hydration mismatches), sunucuda üretilen HTML çıktısı ile istemcide ilk kez oluşturulan Virtual DOM yapısı uyuşmadığında ortaya çıkan kritik hatalardır. Bu hatalar genellikle sunucu ve istemci saat dilimlerinin (timezone) farklı olmasından, dinamik tarih biçimlendirmelerinden veya tarayıcıya özel window nesnesine bağlı mantıksal kontrollerden kaynaklanır.
RSC projelerinde hata ayıklama (debugging) süreçleri de geleneksel SPA projelerine göre daha karmaşıktır. Hata kodları bazen sunucu tarafındaki Node.js loglarında, bazen de tarayıcı konsolunda görünür. Dağıtık bir sistem üzerinde çalışan bu yapının takibi için gelişmiş izleme (telemetry) araçlarının sisteme entegre edilmesi ve geliştiricilerin her iki çalışma ortamına da hakim olması gerekir.
Üçüncü Parti Kütüphane Uyumsuzlukları
React ekosisteminde bulunan binlerce açık kaynaklı kütüphanenin önemli bir kısmı, henüz RSC mimarisiyle tam uyumlu çalışacak şekilde güncellenmemiştir. Birçok UI kütüphanesi (örneğin eski grafik çizim, modal veya kaydırıcı paketleri), kodlarında doğrudan tarayıcı API'lerini çağırır veya içsel durum yönetimi kullanır.
Bu kütüphaneler bir Server Component içinde doğrudan çağrıldığında derleme veya çalışma zamanı hataları meydana gelir. Çözüm olarak, bu kütüphanelerin 'use client' yönergesi içeren ara bileşenlerle (wrapper) sarmalanması gerekir. Ancak bu geçici çözüm, istemci paket boyutunu artırarak RSC'nin getirdiği performans avantajlarını kısmen baltalayabilir.
Sonuç: React Server Components ile Geleceğin Web Altyapısına Hazırlık
React Server Components mimarisi, web teknolojilerindeki gelişim trendinin geçici bir halkası değil; sürdürülebilir, güvenli ve yüksek performanslı web uygulamaları inşa etmek için geliştirilmiş kalıcı bir standarttır. İşlem gücünü ve veri transferini en optimize şekilde dağıtan bu hibrit yaklaşım, kurumsal markaların dijital varlıklarını geleceğe taşımasında kritik bir rol üstlenmektedir.
Özellikle büyük ölçekli ve yüksek trafikli projelerde, ilk yükleme hızlarının milisaniyeler mertebesine çekilmesi ve kullanıcı deneyiminin kesintisiz kılınması, dönüşüm oranlarını doğrudan artırmaktadır. Webizm'in teknik SEO ve modern web mimarileri üzerindeki uzmanlığı, bu karmaşık geçiş süreçlerini kurumsal hedeflerinize en uygun şekilde yönetmenizi sağlar. Doğru yapılandırılmış bir RSC entegrasyonu, hem yazılım ekibinizin geliştirme hızını artıracak hem de sunucu altyapı maliyetlerinizde uzun vadede ciddi tasarruflar sağlayacaktır.
Sıkça Sorulan Sorular
React Server Components (RSC) ile Server-Side Rendering (SSR) arasındaki en temel fark nedir?
SSR, sayfanın ilk yüklenmesi sırasında tüm bileşenleri hızlıca HTML'e dönüştüren bir süreçtir; RSC ise uygulamanın ömrü boyunca belirli bileşenlerin yalnızca sunucuda çalışmasını ve istemciye sıfır JavaScript yükü iletilmesini sağlayan bir bileşen mimarisidir.
Bir Server Component içinde useState veya useEffect kullanabilir miyim?
Hayır, Server Component'lar yalnızca sunucuda çalışıp statik UI yönergeleri ürettiği için tarayıcı etkileşimini yöneten useState, useEffect gibi React kancalarını (hook) veya yaşam döngüsü metotlarını kullanamazlar.
Next.js dışında React Server Components kullanmak mümkün müdür?
Evet, RSC mimarisi React'in çekirdek bir özelliğidir; ancak bunu kullanabilmek için Next.js App Router, Remix veya Expo gibi bu mimariyi destekleyen bir meta-framework ve buna uygun bir derleyici (bundler) altyapısı gereklidir.
Server Component kullanmak API isteklerini tamamen ortadan kaldırır mı?
Hayır, ancak istemci ile API arasındaki ağ trafiğini azaltır. Server Component'lar doğrudan veritabanı sorgusu yapabildiği gibi, arka plandaki mikro servis API'lerine doğrudan sunucu ağı üzerinden çok daha hızlı şekilde bağlanabilir.
Mevcut bir React projesini tamamen RSC mimarisine taşımak zorunlu mudur?
Zorunlu değildir; RSC kademeli olarak uygulanabilir. Mevcut Client Component yapıları korunurken, sadece veri yoğunluğu yüksek olan veya SEO performansı gerektiren yeni sayfalar ve bölümler Server Component olarak tasarlanabilir.
Server Component'ların SEO performansına etkisi nedir?
Server Component'lar arama motoru botlarına önceden işlenmiş ve hızlı yüklenen içerikler sunduğu için Core Web Vitals metriklerini, özellikle LCP ve FCP skorlarını iyileştirerek arama motoru sıralamalarında ciddi bir avantaj sağlar.
RSC kullanımı sunucu maliyetlerini nasıl etkiler?
İstemcideki yükü sunucuya kaydırdığı için işlemci ve bellek kullanımı sunucu tarafında artabilir. Ancak optimize edilmiş önbellekleme (caching) ve CDN stratejileriyle birleştirildiğinde, bu maliyet artışı minimumda tutulabilir ve kullanıcı tarafındaki verimle dengelenir.
'use client' ifadesi bir bileşenin sadece tarayıcıda çalışacağını mı gösterir?
Hayır, 'use client' ifadesi o bileşenin ve alt bileşenlerinin "istemci tarafında etkileşime açık olacağını" ve istemci paketine (bundle) dahil edileceğini belirtir; ancak bu bileşenler de ilk sayfa yüklenmesinde sunucu tarafında (SSR) önceden oluşturulabilir.