Single Page Application (SPA) Sistemlerinde Yönlendirme (Routing) Mantığı

Single Page Application projelerinde routing, yalnızca bir component'ten başka bir component'e geçmek anlamına gelmez. URL, browser history, uygulama state'i, veri yükleme, erişim kontrolü, SEO, accessibility ve server configuration aynı navigasyon sürecinin farklı parçalarıdır. Bir kullanıcı uygulama içindeki bağlantıya tıkladığında sayfanın tamamen yeniden yüklenmemesi bu parçaların browser içinde koordineli biçimde çalışması sayesinde mümkün olur. React Router, Vue Router veya Angular Router gibi araçlar geliştiricinin bu mekanizmaları daha rahat kullanmasını sağlar fakat temel davranış Browser History API ve URL modeli üzerine kuruludur. Bu rehberde SPA routing mantığını framework API'lerini ezberlemek yerine tarayıcının gerçekten ne yaptığını anlayabileceğiniz bir model üzerinden inceleyeceğiz.

SPA (Single Page Application) Nedir?

Single Page Application, ilk uygulama kabuğu yüklendikten sonra önemli kullanıcı geçişlerini tam sayfa yenilemesi olmadan gerçekleştiren web uygulaması yaklaşımıdır. Kullanıcı farklı bir ekrana geçtiğinde JavaScript mevcut doküman içindeki görünümü günceller. Yeni veriler gerektiğinde genellikle API istekleri yapılır ve alınan sonuç ilgili arayüz bölümüne aktarılır. Bu yaklaşım uygulama benzeri akıcı etkileşimler sağlayabilir fakat routing, state restoration ve server fallback gibi ek sorumluluklar getirir. SPA'yı yalnızca “tek HTML dosyası” şeklinde düşünmek yerine browser içinde yaşayan bir uygulama yaşam döngüsü olarak görmek daha doğru olur.

Geleneksel Multi-Page Application Nasıl Çalışır?

Geleneksel Multi-Page Application modelinde kullanıcı yeni bir URL'ye gittiğinde browser çoğunlukla sunucuya yeni bir document isteği gönderir. Sunucu ilgili URL için HTML üretir veya hazır HTML dosyasını döndürür. Browser mevcut document'i kapatır ve gelen yeni document'i parse ederek sayfayı baştan oluşturur. JavaScript, CSS ve diğer kaynaklar cache durumuna göre tekrar değerlendirilebilir veya indirilebilir. Bu modelde URL ile server route arasında doğal bir ilişki bulunduğu için direct navigation ve refresh davranışı çoğunlukla doğrudan sunucu tarafından yönetilir.

SPA Nasıl Çalışır?

SPA ilk açılışta uygulama için gerekli HTML kabuğunu ve JavaScript kodunu yükler. Bundan sonraki client navigation işlemlerinde aynı document korunabilir. Router URL'yi değiştirir, yeni route'u belirler ve uygun view veya component ağacını render eder. Gerekli veriler document isteği yerine API çağrılarıyla alınabilir. Kullanıcı farklı bir sayfaya geçmiş gibi hissederken browser açısından aynı document üzerinde farklı application state'leri görüntüleniyor olabilir.

Tek HTML Dokümanı

SPA mimarisinde başlangıç document'i çoğu zaman bir index.html dosyasından gelir. Bu document uygulamanın mount edileceği kök alanı ve JavaScript bundle bağlantılarını içerir. Client routing sırasında aynı HTML document'i korunabilir. Route değiştikçe uygulama bu document içindeki belirli DOM bölümlerini yeniden üretir. Direct URL isteğinde ise server'ın ilgili SPA route'unu yine bu başlangıç document'ine yönlendirebilmesi gerekir.

JavaScript ile Dinamik İçerik Güncelleme

SPA'nın ekranda ne göstereceğine büyük ölçüde JavaScript karar verir. Router mevcut URL'yi değerlendirerek hangi view'ın aktif olması gerektiğini belirler. Framework render sistemi önceki view ile yeni view arasındaki farkı DOM'a uygular. Header veya ana navigation gibi ortak alanlar sabit kalırken içerik alanı değişebilir. Böylece her navigation için bütün document'in yeniden oluşturulmasına ihtiyaç kalmaz.

API Üzerinden Veri Alma

Route değişikliği ile veri isteği aynı işlem değildir fakat çoğu uygulamada birbirini takip eder. Örneğin /products/42 route'u ürün detay component'ini seçerken component veya route loader ürün verisini API üzerinden alabilir. Router URL ile görünüm ilişkisini yönetir. API client ise network verisinin alınmasından sorumludur. Bu ayrım doğru kurulduğunda navigation davranışı ile business data katmanı birbirine gereksiz biçimde bağlanmaz.

SPA ile MPA Arasındaki Temel Farklar

MPA navigation sırasında yeni document yüklemeye dayanırken SPA birçok geçişi aynı document üzerinde gerçekleştirir. MPA'da route çözümleme temel olarak server tarafında gerçekleşebilir. SPA'da ise kullanıcı uygulama içindeyken client router URL eşleşmesini üstlenir. Bununla birlikte direct navigation sırasında SPA da önce server ile iletişim kurmak zorundadır. Bu nedenle iki model arasındaki fark yalnızca performans değil routing sorumluluğunun hangi aşamada ve hangi katmanda gerçekleştiğiyle ilgilidir.

SPA İçinde Neden Routing Gerekir?

Tek bir JavaScript uygulaması farklı ekranlar gösterecekse bu ekranların adreslenebilir olması gerekir. Routing, URL ile uygulamanın hangi görünümü sunacağı arasında sözleşme oluşturur. Kullanıcı bir ürün detayını paylaşabilir, bir dashboard alt ekranını bookmark edebilir veya browser back tuşuyla önceki duruma dönebilir. URL olmadan bütün navigasyon yalnızca memory state'e bağlı kalır ve refresh sonrasında bağlam kaybolabilir. Router bu nedenle SPA'nın sadece menü sistemi değil browser navigasyon modeliyle entegrasyon katmanıdır.

Routing Nedir?

Routing bir URL'nin hangi uygulama görünümü, data requirement veya davranışla eşleşeceğini belirleyen süreçtir. Web sunucusunda routing request'i bir handler'a yönlendirebilirken SPA içinde routing çoğunlukla URL'yi bir component ağacıyla eşleştirir. Route parameter, query parameter ve nested path gibi bilgiler de bu eşleştirmenin parçası olabilir. Router navigation sırasında history stack ve application state arasında koordinasyon kurar. İyi route tasarımı URL'yi hem kullanıcı hem browser hem de uygulama için anlamlı bir navigasyon sözleşmesine dönüştürür.

URL ile Uygulama Görünümü Arasındaki İlişki

URL kullanıcının uygulamada nerede bulunduğunu ifade eden en görünür state kaynaklarından biridir. /products ürün listesini, /products/42 ise belirli bir ürünü gösterebilir. Router pathname bilgisini route configuration ile eşleştirir. Eşleşme sonucunda ilgili component veya view render edilir. URL ile görünüm arasında açık ilişki kurulması paylaşılabilir ve tekrar üretilebilir kullanıcı deneyimi sağlar.

Route Nedir?

Route bir URL pattern'i ile bu pattern eşleştiğinde gerçekleşecek uygulama davranışını tanımlar. Basit route yalnızca path ve component ilişkisi içerebilir. Daha gelişmiş route data loader, authorization metadata, error boundary veya nested child route tanımlayabilir. Dynamic segment route'un belirli kısmını parametre haline getirir. Route tablosu uygulamanın navigasyon haritası olarak düşünülebilir.

Router Nedir?

Router mevcut URL'yi izleyen ve onu tanımlı route'larla eşleştiren uygulama katmanıdır. Kullanıcı navigation başlattığında URL değişikliğini organize eder. Ardından uygun route ağacını seçer ve framework'e hangi görünümün render edilmesi gerektiğini bildirir. Back ve forward navigation sırasında history değişikliklerini dinler. Gelişmiş router'lar data loading, pending state, redirect ve error handling gibi görevleri de üstlenebilir.

Navigation Nedir?

Navigation kullanıcının veya uygulama kodunun bir route durumundan başka bir route durumuna geçmesidir. Bir link tıklamak navigation oluşturabilir. Kod içinden redirect yapmak da aynı navigasyon sistemini kullanabilir. Back ve forward butonları geçmiş history kayıtlarına geçiş yaptığı için navigation kapsamındadır. Başarılı routing tasarımı bütün bu geçiş biçimlerinde tutarlı URL ve UI üretmelidir.

Client-Side Routing Nedir?

Client-side routing route eşleşmesinin browser içinde JavaScript tarafından yapılmasıdır. Navigation sırasında yeni document alınmadan History API ile URL değiştirilebilir. Router yeni URL'yi eşleştirerek ilgili view'ı render eder. API istekleri ayrıca yapılabilir fakat bunlar document navigation olmak zorunda değildir. SPA kullanıcı deneyiminin temelinde bu davranış bulunur.

Server-Side Routing Nedir?

Server-side routing HTTP request URL'sinin sunucu üzerinde ilgili handler veya kaynağa yönlendirilmesidir. Gelen /products/42 isteği server tarafından doğrudan HTML response'a dönüştürülebilir. API route'ları da server-side routing kullanır. SPA direct navigation sırasında server route davranışı hâlâ önemlidir. Client route ile server route aynı URL alanını kullanıyorsa fallback ve API ayrımı dikkatle tasarlanmalıdır.

SPA Routing Mantığı Nasıl Çalışır?

SPA routing tipik olarak kullanıcı etkileşimi, URL değişimi, route matching ve render aşamalarından oluşur. Router aynı origin içindeki uygun link click'ini yakalayabilir ve browser'ın normal document navigation davranışını durdurabilir. History API kullanılarak adres çubuğundaki URL yeni değere geçirilir. Router route tablosunda bu URL'ye karşılık gelen yapılandırmayı bulur. Framework yalnızca yeni route için gerekli UI parçalarını render ederek navigation'ı tamamlar.

Kullanıcı Bir Linke Tıkladığında Ne Olur?

Router destekli link tıklaması normal anchor navigation'a benzer bir kullanıcı niyeti taşır. Client router click event'i uygun koşullarda yakalar. Modifier key, external URL veya download gibi durumlarda native browser davranışı korunabilir. Internal navigation ise History API üzerinden işlenebilir. Yeni URL eşleştirildikten sonra application view güncellenir.

Link Tıklamasının Yakalanması

Router component'i veya event delegation mekanizması link click event'ini dinleyebilir. Tıklanan link'in aynı application içinde yönetilen bir route olup olmadığı kontrol edilir. External domain veya yeni sekmede açılma isteği varsa router genellikle devreye girmez. Uygun internal link client navigation'a dönüştürülür. Bu kontrol native web link davranışlarını gereksiz yere bozmamak açısından önemlidir.

Varsayılan Browser Navigation'ın Engellenmesi

Normal anchor click browser'ın yeni URL için document request başlatmasına neden olur. SPA router uygun internal geçişte preventDefault() benzeri mekanizmayla bu davranışı durdurabilir. Böylece mevcut document korunur. Router URL değişikliğini kendi navigation pipeline'ı üzerinden gerçekleştirir. Bu müdahale yalnızca router'ın gerçekten yönetebileceği navigation'larda yapılmalıdır.

URL'nin Güncellenmesi

Browser history tabanlı router yeni URL'yi pushState() veya uygun durumlarda replaceState() ile güncelleyebilir. Address bar değişmesine rağmen yeni document request'i başlatılmaz. URL aynı origin sınırları içinde tutulur. History kaydı kullanıcının daha sonra back veya forward butonuyla erişebileceği navigasyon geçmişine eklenebilir. Bu işlem UI render'ından ayrı fakat onunla senkron yürütülmelidir.

Route Matching Yapılması

Yeni location bilgisi route configuration ile karşılaştırılır. Static segment'ler doğrudan eşleşirken dynamic segment'ler parametre olarak çıkarılabilir. Wildcard route kalan path bölümlerini yakalayabilir. Nested router'lar aynı location için parent ve child route zinciri oluşturabilir. Elde edilen route match sonucu render ve data loading sürecini belirler.

İlgili Component veya View'ın Render Edilmesi

Route match belirlendiğinde router framework'e ilgili component ağacını sunar. Parent layout korunurken child outlet değişebilir. Component mount sırasında ihtiyaç duyduğu data'yı alabilir veya data router daha önce loader çalıştırmış olabilir. Error veya pending state route seviyesinde gösterilebilir. Kullanıcının gördüğü yeni ekran böylece URL ile uyumlu hale gelir.

Neden Sayfa Baştan Yüklenmez?

Client navigation normal document request'i başlatmadığı için browser mevcut document'i kapatmaz. History API adres çubuğunu ve session history kaydını document reload olmadan değiştirebilir. JavaScript router aynı runtime içinde çalışmaya devam eder. Framework sadece gerekli UI update'lerini uygular. Ancak kullanıcı address bar'a URL yazıp Enter tuşuna basarsa bu doğrudan document request'i olur ve server fallback tekrar önem kazanır.

DOM'un Hangi Bölümü Değişir?

Değişen DOM bölümü uygulamanın component ve layout yapısına bağlıdır. Global header, sidebar veya footer parent layout içinde kaldığı için korunabilir. Route outlet içindeki child content yeni route'a göre değiştirilir. Framework reconciliation veya benzer render mekanizması gerçekten değişmesi gereken node'ları günceller. Routing bu nedenle bütün DOM'un değiştirilmesini gerektirmez.

API İstekleri Routing'den Nasıl Ayrılır?

Router'ın görevi URL ve view ilişkisini yönetmektir. API request ise application data katmanının network üzerinden bilgi almasını sağlar. Route change API çağrısını tetikleyebilir fakat iki işlem aynı şey değildir. Aynı route farklı query ile yeni data yükleyebilir veya cached data sayesinde hiç request yapmayabilir. Bu sorumlulukların ayrılması testing, caching ve error handling tasarımını kolaylaştırır.

SPA Routing'in Kalbi: Browser History API

Modern browser tabanlı SPA routing'in temelinde session history üzerinde çalışan History API bulunur. pushState() yeni history entry ekleyebilir ve URL'yi document reload olmadan değiştirebilir. replaceState() mevcut kaydı yeni state veya URL ile günceller. Kullanıcı history içinde back veya forward yaptığında popstate olayı router'ın UI durumunu yeniden kurmasına yardım eder. Framework router'ları bu browser davranışlarını daha yüksek seviyeli API'lerle soyutlar.

window.history Nedir?

window.history mevcut tab veya window için session history ile etkileşim sağlayan browser nesnesidir. Kullanıcı ziyaret ettiği history entry'ler arasında hareket edebilir. Uygulama back(), forward() ve go() gibi navigation method'larını kullanabilir. SPA ayrıca pushState() ve replaceState() ile current document için history entry yönetebilir. Router kullanırken bu API çoğunlukla doğrudan değil library abstraction üzerinden tüketilir.

History Stack Nasıl Çalışır?

Browser session history kullanıcı navigasyonlarını sıralı kayıtlar olarak tutar. Yeni normal navigation veya pushState() mevcut konumdan sonra yeni entry oluşturabilir. Kullanıcı back yaptığında önceki entry aktif hale gelir. Daha sonra yeni navigation yapılırsa ileri history zincirinin bir kısmı değişebilir. Router'ın bu davranışı doğru anlaması back tuşunun kullanıcı beklentisine uygun kalması için önemlidir.

pushState() Nedir?

pushState() mevcut document bağlamında yeni session history entry ekleyen History API method'udur. Method state nesnesi ve isteğe bağlı URL bilgisi alabilir. URL değişse bile browser otomatik olarak yeni document yüklemez. Daha sonra kullanıcı bu entry'ler arasında history navigation yapabilir. Router internal link geçişlerinde yeni anlamlı sayfa durumu oluşturmak için bu semantiği kullanır.

Yeni History Kaydı Oluşturma

Bir ürün listesinden ürün detayına geçiş kullanıcı açısından yeni bir navigasyon adımıdır. Bu durumda yeni history entry oluşturmak mantıklı olabilir. Kullanıcı back tuşuna bastığında ürün listesine dönebilir. Her küçük UI değişikliğini history'ye eklemek ise geri tuşunu yorucu hale getirebilir. History kaydı oluşturma kararı kullanıcı tarafından “yeni konum” olarak algılanan durumlara göre verilmelidir.

URL'yi Reload Olmadan Değiştirme

History API'nin SPA routing için en önemli özelliği URL'nin document reload olmadan değiştirilebilmesidir. Browser address bar yeni path'i gösterir. JavaScript runtime ve mevcut document çalışmaya devam eder. Router URL'ye karşılık gelen view'ı ayrıca render eder. Bu iki işlem senkronize edilmezse kullanıcı adres çubuğunda başka, ekranda başka state görebilir.

replaceState() Nedir?

replaceState() yeni history entry eklemek yerine mevcut entry'yi değiştirir. URL veya associated state güncellenebilir. Kullanıcı back yaptığında replace edilen ara durum ayrı bir history adımı olarak karşısına çıkmaz. Canonicalization, redirect veya geçici navigation state düzeltmelerinde faydalıdır. Router API'lerinde çoğu zaman replace seçeneğiyle temsil edilir.

pushState ile replaceState Arasındaki Fark

pushState() yeni geçmiş noktası oluşturur. replaceState() ise kullanıcıyı aynı geçmiş noktasında tutarak mevcut kaydı değiştirir. Bir ürün detayına gitmek çoğu zaman push semantiğidir. Login redirect sonucu veya hatalı query normalization işlemi replace kullanabilir. Doğru seçim back button davranışını doğrudan etkiler.

Login ve Redirect Senaryoları

Kullanıcı korunan route'a giderken login ekranına yönlendirilebilir. Login başarılı olduktan sonra eski route'a geri dönmek istenebilir. Bazı uygulamalar login sayfasını history'de ayrı adım olarak tutmak istemez. Bu durumda redirect'in belirli aşamalarında replace semantiği uygun olabilir. Ancak history davranışı kullanıcı akışına göre test edilmelidir.

popstate Event'i Nedir?

popstate kullanıcının session history içindeki başka bir entry'ye geçtiği durumlarda önemli rol oynar. Back ve forward butonları tipik örneklerdir. Router event geldiğinde current location'ı tekrar okuyabilir. Ardından route matching yaparak UI'ı geçmiş URL ile uyumlu hale getirir. pushState() çağrısının kendisinin aynı anda doğrudan popstate üretmesini beklemek doğru bir routing modeli değildir.

Browser Back Butonu

Back butonu kullanıcıların web üzerindeki en temel navigasyon beklentilerinden biridir. SPA bu davranışı özel bir uygulama butonu gibi ele almamalıdır. History entry değiştiğinde router URL'deki önceki route'u yeniden render etmelidir. Gerekli state URL veya persistent kaynaklardan tekrar kurulabilir. Back tuşunun bozuk olduğu SPA kullanıcıya web sayfası yerine kapalı bir arayüz hissi verir.

Browser Forward Butonu

Forward butonu daha önce geri gidilmiş history entry'ye yeniden geçiş sağlar. Router bu navigation'ı da current location üzerinden çözmelidir. Uygulama yalnızca kendi navigation function'ını dinliyorsa forward geçişini kaçırabilir. History event'lerinin ayrı şekilde ele alınması bu nedenle gereklidir. Forward sonrası data cache veya scroll state gibi deneyimler de mümkünse geri kurulmalıdır.

UI State'in Yeniden Oluşturulması

History değiştiğinde uygulama yalnızca URL text'ini güncellemekle yetinemez. Route'a bağlı component tree yeniden belirlenmelidir. Query parametreleri filter veya pagination state'ini tekrar oluşturabilir. Gerekirse API data yeniden alınır veya cache'den getirilir. URL'nin reproducible state taşıması history navigation güvenilirliğini artırır.

history.back(), forward() ve go()

history.back() session history içinde önceki entry'ye hareket etmeyi talep eder. history.forward() sonraki entry'ye geçer. history.go() göreli bir history offset ile daha esnek hareket sağlar. Router navigation API'leri bu davranışları sayı tabanlı navigation şeklinde sunabilir. Kullanıcı history'sinin uygulamanın kontrolü dışında entry'ler de içerebileceği unutulmamalıdır.

Bir SPA Router İçeride Nasıl Çalışır?

Basit bir SPA router'ın yaptığı iş aslında birkaç temel adıma ayrılabilir. Router location değişikliklerini izler, URL'yi parse eder ve route tablosunda eşleşme arar. Eşleşen route dynamic parametreler ve nested route bilgileriyle birlikte route state üretir. Framework bu state'e göre uygun view'ı render eder. Production router'lar buna cancellation, data loading, redirects, error handling ve transition state gibi daha gelişmiş özellikler ekler.

URL Değişikliğinin Dinlenmesi

Router kendi navigation API'si üzerinden yapılan URL değişikliklerini zaten bilir. Bunun yanında browser back ve forward gibi dış history navigation'larını da dinlemelidir. History API tabanlı yapıda popstate bu görev için önemlidir. Hash routing kullanıldığında hashchange event'i devreye girebilir. Tek bir location state kaynağı kullanmak farklı navigation kanallarının aynı render pipeline'ına girmesini sağlar.

Path Parse İşlemi

URL yalnızca pathname'den oluşmaz. Search parameters ve hash bilgisi de ayrı anlam taşıyabilir. Router pathname'i route matching için segment'lere ayırabilir. URL decoding ve trailing slash politikası tutarlı uygulanmalıdır. Parse katmanı raw URL bilgisini application routing modeline dönüştürür.

Route Tablosunda Eşleşme Arama

Route configuration uygulamanın desteklediği path pattern'lerini içerir. Router mevcut pathname için uygun route veya route zincirini arar. Static ve dynamic pattern'ler arasında öncelik stratejisi bulunabilir. Bazı router'lar route specificity hesabı yaparken bazı sistemler configuration sırasını daha doğrudan kullanabilir. Wildcard fallback yalnızca daha spesifik eşleşmeler bulunmadığında kullanılmalıdır.

Route Matching Algoritması

Route matcher path segment'lerini configuration pattern'leriyle karşılaştırır. Static segment exact değer bekler. Dynamic segment o noktadaki değeri parametre olarak kabul eder. Wildcard kalan segment'leri yakalayabilir. Nested yapı parent ve child match'lerini birlikte değerlendirerek render ağacını oluşturabilir.

Static Route

Static route sabit path parçalarından oluşur. /about veya /products buna örnek verilebilir. Eşleşme için ilgili segment'in aynı değeri taşıması gerekir. Static route genellikle okunabilir ve tahmin edilebilir URL sağlar. Dynamic route ile conflict bulunduğunda router'ın matching stratejisi bilinmelidir.

Dynamic Route

Dynamic route path'in belirli bölümünü değişken kabul eder. /products/:productId benzeri pattern farklı ürün URL'lerini tek route tanımıyla yönetebilir. Matched value parametre olarak application'a verilir. Parametre string olarak geliyorsa domain validation ayrıca yapılmalıdır. Route eşleşmesi parametrenin gerçek ürünü temsil ettiğini kanıtlamaz.

Wildcard Route

Wildcard route daha spesifik hiçbir route eşleşmediğinde kalan URL'leri yakalamak için kullanılabilir. Client-side 404 sayfası en yaygın kullanım alanıdır. File browser veya deep nested content gibi senaryolarda kalan path'i parametre olarak almak için de kullanılabilir. Wildcard'ın fazla erken eşleşmesi geçerli route'ları görünmez hale getirebilir. Router'ın route ordering davranışı bu nedenle önemlidir.

Eşleşen View'ın Render Edilmesi

Matcher route sonucunu ürettikten sonra rendering katmanı devreye girer. Basit router doğrudan root container içine HTML basabilir. Framework router ise component element veya route tree oluşturur. Nested match parent layout ve child content'i birlikte render edebilir. View render edilirken navigation'ın hâlâ current olup olmadığı async senaryolarda kontrol edilmelidir.

Framework State'i ile Router State'in Senkronizasyonu

Router state current location ve match bilgisini taşırken framework state UI render sürecini yönetir. İki state birbirinden koparsa stale screen görülebilir. Navigation transaction yeni route ve component state update'ini koordineli şekilde yürütmelidir. Modern router'lar pending navigation bilgisini de framework'e aktarabilir. Uygulama aynı URL bilgisini farklı local state değişkenlerine kopyalamaktan mümkün olduğunca kaçınmalıdır.

Basit Bir Router'ı Vanilla JavaScript ile Nasıl Tasarlarız?

Framework kullanmadan küçük bir router yazmak routing mantığını öğrenmenin iyi yollarından biridir. Önce path ve render function ilişkisini tutan route tablosu oluşturulur. Internal link click'leri yakalanarak browser'ın normal document navigation davranışı gerektiğinde durdurulur. pushState() ile URL güncellenir ve aynı render function tekrar çalıştırılır. Ayrıca popstate dinlenerek browser back ve forward davranışı desteklenir.

Route Tablosu Oluşturma

Route tablosu uygulamanın hangi path için hangi view'ı göstereceğini tanımlar. Basit örnekte key-value object yeterli olabilir. Dynamic route gerektiğinde pattern matcher veya segment tabanlı fonksiyon gerekir. Wildcard 404 route son fallback olarak tanımlanabilir. Route metadata zamanla title veya data loader gibi ek bilgileri de taşıyabilir.

Link Click Event'lerini Yakalama

Document seviyesinde event delegation kullanılarak internal anchor click'leri izlenebilir. Click'in left button ile yapıldığı, modifier key bulunmadığı ve URL'nin same-origin olduğu kontrol edilmelidir. Anchor target veya download davranışı varsa native navigation korunmalıdır. Uygun click için default behavior engellenir. Ardından router navigation function'ı çağrılır.

pushState Kullanma

Navigation function hedef URL için history.pushState() çağırabilir. Bu işlem browser address bar'ı günceller ve yeni history entry oluşturur. Ardından route render function doğrudan çalıştırılmalıdır. Çünkü pushState çağrısının kendisi router'a otomatik render yaptırmaz. Navigation işlemini tek bir function içinde toplamak URL ve UI senkronizasyonunu kolaylaştırır.

popstate Dinleme

Back veya forward navigation sırasında popstate handler current pathname'i yeniden okuyabilir. Bu handler tekrar route matching ve render işlemini çalıştırır. Yeni history entry eklememelidir çünkü kullanıcı zaten history içinde hareket etmektedir. Aksi durumda back loop veya beklenmeyen history zinciri oluşabilir. Initial load da aynı render function üzerinden geçirilirse router davranışı daha tutarlı olur.

URL'ye Göre View Render Etme

Render function window.location.pathname bilgisini alabilir. Route tablosunda eşleşme bulunur ve ilgili view oluşturulur. Dynamic parameter varsa parse edilerek view'a aktarılır. Search parameter ayrıca URLSearchParams ile okunabilir. Hiçbir route eşleşmezse 404 view render edilir.

404 Route Oluşturma

Client-side 404 route uygulamanın bilinmeyen path için anlamlı UI göstermesini sağlar. Router matcher hiçbir normal route bulamadığında bu fallback'i seçer. Kullanıcıya ana navigasyona dönme imkanı verilmelidir. SEO açısından server'ın direct request'e verdiği HTTP status ile client-side 404 davranışının aynı konu olmadığı unutulmamalıdır. Public indexlenebilir içerikte gerçek 404 stratejisi server veya rendering katmanıyla birlikte tasarlanmalıdır.

URL Yapısı ve Route Tasarımı

URL routing'in kullanıcıya görünen API'sidir. İyi URL yapısı kısa, anlamlı, tutarlı ve paylaşılabilir olmalıdır. Path hierarchical konumu, route parameter belirli kaynağı, query parameter ise çoğunlukla görünüm varyasyonunu veya filtre durumunu temsil eder. Hash document içi hedef veya hash-routing amacıyla kullanılabilir. Hangi state'in URL'ye yazılacağı bookmark, privacy ve history davranışları dikkate alınarak seçilmelidir.

Pathname Nedir?

Pathname URL'nin domain sonrasında ve query başlangıcından önce bulunan path bölümüdür. /products/42 tipik pathname örneğidir. Router'ın ana route matching işlemi çoğunlukla bu değer üzerinden yapılır. Trailing slash ve case sensitivity politikası uygulama genelinde tutarlı olmalıdır. Pathname business navigasyon hiyerarşisini gereksiz teknik ayrıntılardan uzak tutmalıdır.

Route Parametreleri

Route parameter URL path içinde belirli bir resource veya alt görünümü tanımlayan dynamic değerdir. Product ID, username veya content slug sık kullanılan örneklerdir. Router parameter value'yu path'ten çıkarır. Application bu değerin formatını ve gerçekten geçerli resource'a karşılık gelip gelmediğini ayrıca doğrular. Parametre isimleri domain anlamını açıkça ifade etmelidir.

/users/

Kullanıcı detay route'u örneğin /users/42 biçiminde tasarlanabilir. Buradaki 42 user identifier görevini görür. Router pattern'i /users/:userId şeklinde tanımlanabilir. URL direct olarak açıldığında aynı kullanıcı ekranı yeniden oluşturulabilmelidir. Hassas kullanıcı bilgileri path içine yazılmamalıdır.

/products/

Ürün detay route'u /products/42 veya anlamlı slug içeren başka bir yapı kullanabilir. Route parameter ürünün hangi kaynaktan yükleneceğini belirler. Product detail component parametreyi alıp data layer'a iletebilir. Geçersiz ürün ID'si client veya server 404 akışına gitmelidir. URL kalıcı olarak paylaşılacaksa identifier değişim politikası da düşünülmelidir.

Query Parameters

Query parameters aynı temel resource görünümünün filtre, sıra veya sayfa gibi varyasyonlarını taşımak için uygundur. ?page=2 veya ?sort=price buna örnektir. Kullanıcı bu URL'yi paylaşınca aynı görünüm state'i yeniden oluşturulabilir. Query parametreleri order-independent ve parse edilebilir şekilde yönetilmelidir. Default değerleri URL'de tutup tutmama kararı canonicalization ve readability açısından belirlenmelidir.

Filtreleme

Kategori filtreleri URL query içinde tutulduğunda kullanıcı filtrelenmiş sonucu paylaşabilir. Refresh sonrasında aynı filtre state'i yeniden oluşturulabilir. Birden fazla filter value için tekrar eden parameter veya standard encoding kullanılabilir. UI filter state'i URL ile çift yönlü senkronize edilmelidir. Çok uzun filter payload'ları URL'yi okunamaz hale getirmemelidir.

Sıralama

Sort seçimi çoğu zaman query parameter için uygun bir state'tir. ?sort=price-asc gibi değer görünümü açıklayabilir. Unsupported sort değeri güvenli default'a normalize edilebilir. URL update her seçimde yeni history entry oluşturmalı mı sorusu UX'e göre değerlendirilmelidir. Sık değişen sort kontrolünde replace semantiği bazı deneyimlerde daha uygun olabilir.

Pagination

Pagination query parameter ile temsil edildiğinde belirli sonuç sayfasına direct navigation mümkün olur. ?page=3 refresh sonrasında aynı sayfayı tekrar oluşturabilir. Page değeri number olarak parse edilip sınır kontrolünden geçirilmelidir. Geçersiz değer default page'e yönlendirilebilir. SEO kullanılan content türüne göre pagination canonical ve index politikası ayrıca planlanmalıdır.

Arama

Search query URL'de tutulduğunda sonuç ekranı paylaşılabilir hale gelir. ?q=router gibi değer kullanıcının arama niyetini temsil eder. Input her key press'te history push yaparsa back stack gereğinden fazla büyüyebilir. Debounce ve replace semantiği bu sorunu azaltabilir. Hassas veya kişisel arama değerlerinin URL'de görünmesinin privacy etkisi değerlendirilmelidir.

URL Fragment ve Hash

Hash URL'nin # sonrasındaki bölümüdür. Geleneksel olarak document içindeki belirli element veya bölüm hedeflemek için kullanılır. Hash routing yaklaşımında client route bilgisi hash içinde tutulabilir. Hash değişimi server'a gönderilen request path'ini aynı şekilde değiştirmez. Accessibility ve anchor navigation ihtiyaçları hash router tasarımında ayrıca düşünülmelidir.

URLSearchParams Kullanımı

URLSearchParams query string'i parse etmek ve üretmek için browser tarafından sağlanan kullanışlı API'dir. Raw string split işlemleri yerine encoding davranışını daha güvenli yönetir. Aynı key birden fazla value taşıyabilir. Number ve boolean değerler yine string'den domain type'a dönüştürülmelidir. Query serialization ve parsing mümkünse merkezi utility üzerinden yapılmalıdır.

Hangi State URL'de Tutulmalı?

URL'de tutulacak state için en iyi soru kullanıcının bu durumu paylaşmak, bookmark etmek veya refresh sonrasında korumak isteyip istemediğidir. Filter, pagination ve seçili content ID çoğu zaman iyi adaydır. Geçici hover veya animation state URL'ye taşınmamalıdır. Hassas token veya kişisel bilgi URL içinde tutulmamalıdır. URL application state'in tamamı değil, navigasyon açısından anlamlı bölümüdür.

Paylaşılabilir State

Başka kullanıcıya gönderildiğinde aynı anlamlı görünümü üretmesi gereken state URL için güçlü adaydır. Ürün, makale, kategori veya filtrelenmiş arama buna örnek olabilir. Backend veya API permission farkları aynı URL'de farklı sonuç üretse bile navigasyon niyeti korunur. URL schema zaman içinde mümkün olduğunca stabil tutulmalıdır. Shareable state memory-only variable'a bağlanmamalıdır.

Bookmark Edilebilir State

Kullanıcı daha sonra dönmek istediği görünümü browser bookmark ile kaydedebilmelidir. Dashboard alt ekranı veya belirli rapor filtresi buna örnek olabilir. Bookmark açıldığında uygulama gerekli state'i URL'den yeniden oluşturmalıdır. Session-only data gerekiyorsa graceful fallback sağlanmalıdır. Bookmark'ın çalışması direct navigation server configuration'ına da bağlıdır.

Geçici UI State

Tooltip açık mı veya input focus nerede gibi geçici bilgiler genellikle URL için uygun değildir. Bu state'ler component memory içinde kalabilir. Bazı modal'lar paylaşılabilir business anlam taşıyorsa route yapılabilir. Her modal'ı route yapmak ise history deneyimini yorabilir. State'in kullanıcı tarafından bağımsız konum olarak algılanıp algılanmadığı karar kriteridir.

Hassas Bilgileri URL'den Uzak Tutma

URL browser history, analytics, referrer ve server log gibi birçok yerde görülebilir. Access token, password veya hassas kişisel veri query parameter olarak taşınmamalıdır. Routing convenience güvenlik ve privacy requirement'ının önüne geçmemelidir. Temporary authorization code gibi protocol-specific değerler bile gerekli işlemden sonra URL'den temizlenebilir. Hassas state güvenli storage veya server-side session yaklaşımıyla yönetilmelidir.

Browser Routing ve Hash Routing Arasındaki Fark

Browser routing temiz path'leri History API üzerinden yönetirken hash routing route bilgisini URL fragment içinde taşır. Browser routing /products/42 gibi doğal URL üretir fakat server'ın direct request fallback davranışını doğru yapılandırmasını gerektirir. Hash routing'te server genellikle hash sonrasını görmediği için aynı document'i sunmaya devam eder. Bu özellik static hosting kısıtlarında kurulumu kolaylaştırabilir. Public content, SEO ve standart URL ihtiyacının yüksek olduğu projelerde browser history modeli çoğunlukla daha doğal bir seçimdir.

BrowserRouter Mantığı

BrowserRouter benzeri modeller normal pathname üzerinde client-side routing gerçekleştirir. History API URL değişikliğini reload olmadan yapmayı sağlar. Kullanıcı direct olarak aynı URL'yi açtığında request server'a gerçek pathname ile gider. Bu nedenle server SPA fallback bilmelidir. Framework adı değişse de browser routing'in altında aynı web platformu prensibi bulunur.

History API Kullanımı

Browser routing yeni navigation için push veya replace semantiğini kullanabilir. Back ve forward history traversal ile çalışır. Router popstate gibi browser sinyallerinden current location'ı takip eder. URL same-origin kurallarına uymalıdır. Library bu low-level davranışları daha kullanışlı navigation API'sine dönüştürür.

Temiz URL Yapısı

Browser routing URL'de hash route prefix'i gerektirmez. Bu durum URL'nin resource hierarchy gibi okunmasını kolaylaştırır. Server, analytics ve SEO sistemleri route'u doğrudan pathname olarak görebilir. Path standard web link davranışlarıyla uyumludur. Deployment configuration yanlışsa direct URL 404 riski doğar.

HashRouter Mantığı

Hash router route state'ini URL fragment bölümünde tutar. Örneğin application route /#/products/42 gibi görünebilir. Hash değişimi aynı server document path'ine bağlı kaldığı için static server ek fallback olmadan çalışabilir. Router hash değerini parse edip uygun view'ı render eder. Bu yaklaşım teknik kısıtlı deployment ortamlarında yararlı olabilir.

hashchange Event'i

Browser URL hash bölümü değiştiğinde hashchange event'i kullanılabilir. Basit hash router bu eventi dinleyip route matching çalıştırır. History API kullanmadan da navigation history davranışı elde edilebilir. Hash'in document anchor davranışıyla conflict ihtimali değerlendirilmelidir. Modern router library'leri bu detayları abstraction içinde yönetebilir.

# İşaretinin Rolü

# fragment başlangıcını belirtir. Fragment HTTP request sırasında normal pathname gibi server route'a gönderilmez. Bu nedenle server her hash route için ayrı resource aramaz. Client JavaScript hash sonrasındaki kısmı application route olarak yorumlayabilir. URL modelinin public content ve analytics üzerindeki etkisi proje ihtiyaçlarına göre değerlendirilmelidir.

BrowserRouter Avantajları ve Dezavantajları

Browser routing insan tarafından okunabilir normal path yapısı sağlar. SEO, analytics ve server log modeline daha doğal uyum gösterebilir. History ve direct link davranışı web'in standart URL beklentisine yakındır. Dezavantajı server veya CDN rewrite yapılandırmasının gerekli olabilmesidir. Yanlış fallback deployment sonrasında yalnızca refresh veya direct link sırasında ortaya çıkan 404 problemleri doğurabilir.

HashRouter Avantajları ve Dezavantajları

Hash routing'in önemli avantajı server rewrite gereksinimini azaltmasıdır. Basit static hosting üzerinde kolay çalışabilir. Bunun karşılığında URL'de hash tabanlı application path bulunur. Fragment'ın geleneksel anchor kullanımını da paylaşması tasarım kısıtı oluşturabilir. Public indexlenebilir içerik ve temiz URL gereksiniminde browser routing genellikle daha uygun olur.

Hangi Projede Hangisi Kullanılmalı?

Modern web hosting üzerinde rewrite kontrolünüz varsa browser routing çoğu application için güçlü varsayılandır. Legacy static hosting yalnızca tek dosya sunuyor ve fallback tanımlamaya izin vermiyorsa hash routing pratik çözüm olabilir. Internal tool veya embedded application'larda URL estetiği daha düşük öncelik taşıyabilir. Public content platformunda SEO ve shareable URL davranışı daha ağır basar. Seçim framework preference yerine deployment ve product requirement üzerinden yapılmalıdır.

Hard Refresh ve Direct URL Problemi

SPA içindeki client navigation ile browser'a doğrudan URL yazmak aynı network davranışını oluşturmaz. Client navigation sırasında router mevcut document içinde URL ve UI'ı değiştirir. Hard refresh veya direct navigation ise server'a gerçek document request gönderir. Server /dashboard/settings path'inde fiziksel dosya arıyorsa 404 dönebilir. SPA deployment bu nedenle application route'ları için doğru index.html fallback stratejisini gerektirir.

SPA İçinde Linke Tıklayınca Neden Çalışır?

Uygulama içindeki router link click'i browser'ın default document navigation davranışını durdurabilir. Router URL'yi History API ile günceller. Mevcut JavaScript application zaten yüklüdür. Route matcher yeni path için view render eder. Server'a yeni HTML document isteği yapılmadığı için server'ın o path'i bilmesine ihtiyaç duyulmaz.

URL Doğrudan Açıldığında Neden 404 Oluşabilir?

Direct URL açıldığında browser server'a GET /products/42 gibi request gönderir. Server bu path için gerçek file veya route bulamazsa 404 üretir. Client router henüz yüklenmediği için müdahale edemez. Server'ın SPA application route'larını başlangıç HTML document'ine rewrite etmesi gerekir. API veya gerçek static asset route'ları bu fallback dışında tutulmalıdır.

Sunucu ile Client Router Arasındaki Fark

Server router HTTP request'e hangi response'un verileceğini belirler. Client router yüklenmiş document içinde hangi view'ın gösterileceğini belirler. Aynı pathname iki katman tarafından farklı zamanlarda işlenebilir. Initial request server üzerinden, sonraki soft navigation client üzerinden gerçekleşebilir. Sağlam architecture her iki katmanın route sınırlarını açıkça tanımlar.

index.html Fallback Mantığı

Fallback yaklaşımında bilinmeyen application path server tarafından SPA başlangıç document'ine yönlendirilir. Browser JavaScript bundle'ı yükledikten sonra client router gerçek pathname'i okur. Ardından uygun route view'ı render edilir. Bu davranış API 404'larını yanlışlıkla index.html'e çevirmemelidir. Fallback yalnızca client application namespace'i için uygulanmalıdır.

Web Sunucusu Nasıl Yapılandırılmalı?

Web sunucusu static asset, API ve SPA application route'larını birbirinden ayırmalıdır. Mevcut file varsa doğrudan sunulabilir. API prefix'i backend handler'a gitmelidir. Kalan client route'lar index.html fallback alabilir. Hosting platformunun rewrite veya fallback syntax'ı farklı olsa da temel prensip aynıdır.

Nginx

Nginx deployment'ında SPA path için file bulunamadığında index document'e fallback uygulanabilir. Static assets mümkünse gerçek file olarak sunulmalıdır. API reverse proxy route'u fallback kuralından daha spesifik tutulmalıdır. Cache header'ları hashed asset ve index document için farklı strateji gerektirebilir. Configuration direct URL, refresh ve 404 senaryolarıyla test edilmelidir.

Apache

Apache ortamında rewrite kuralları client route'ları başlangıç document'ine yönlendirebilir. Existing file ve directory istekleri normal biçimde bırakılmalıdır. API endpoint'leri fallback'ten hariç tutulmalıdır. Rewrite scope application'ın base path'ine göre ayarlanmalıdır. Deployment öncesi nested route direct navigation test edilmelidir.

Node.js

Node.js server static bundle'ı sunarken application fallback handler ekleyebilir. API route'ları genellikle fallback'ten önce tanımlanır. Kalan browser route request'leri index.html ile cevaplanabilir. Gerçek bilinmeyen asset request'ini yanlışlıkla HTML ile cevaplamak debug sorunlarına yol açabilir. Content type ve route namespace kontrolü bu nedenle önemlidir.

CDN ve Static Hosting

CDN veya static hosting hizmetinin rewrite capability'si kontrol edilmelidir. Bazı platformlar bütün bilinmeyen path'leri belirli document'e yönlendirmeye izin verir. Bazıları özel 404 fallback üzerinden benzer davranış sağlar. Edge cache direct route response'larını doğru content type ile saklamalıdır. Platform fallback sunmuyorsa hash routing bir alternatif olabilir.

API Route'ları ile SPA Route'larının Ayrılması

API endpoint'lerini /api gibi açık namespace altında tutmak server routing'i kolaylaştırır. SPA fallback hiçbir zaman gerçek API 404 response'unu HTML document'e çevirmemelidir. Client API code JSON beklerken index.html alırsa anlaşılması zor parse error oluşabilir. Static assets de benzer şekilde ayrı namespace veya gerçek file kontrolüyle korunmalıdır. Route ownership sınırı deployment architecture'ın temel parçalarından biridir.

Dynamic Routes Nasıl Çalışır?

Dynamic route aynı page pattern'inin farklı resource identifier'larıyla kullanılmasını sağlar. Route tanımındaki dynamic segment mevcut URL'den value çıkarır. Router bu value'yu component, loader veya route context'e aktarabilir. Application parameter formatını ve resource existence bilgisini ayrıca doğrular. Böylece tek ürün detay component'i yüzlerce farklı ürün URL'sini işleyebilir.

Dynamic Segment Nedir?

Dynamic segment route path içinde sabit olmayan bölümdür. Router syntax'ında çoğunlukla özel marker ile tanımlanır. /users/:userId pattern'inde son segment dynamic olarak düşünülebilir. Matched value current URL'den alınır. Segment yalnızca string eşleşmesi sağlar, domain doğruluğu ayrıca kontrol edilmelidir.

URL Parametresinin Parse Edilmesi

Router parameter value'yu decode ederek application'a verir. Number bekleniyorsa explicit conversion yapılmalıdır. Invalid number veya unsupported slug formatı early validation ile reddedilebilir. URL encoding nedeniyle raw string üzerinde elle split yapmak yerine router API'si tercih edilmelidir. Parsed parameter data fetching için güvenli input modeline dönüştürülmelidir.

Ürün Detay Sayfası Örneği

/products/42 URL'si product detail route ile eşleşebilir. Router 42 değerini product ID olarak çıkarır. Data layer ilgili ürün kaydını API'den veya cache'den alır. Ürün bulunamazsa page-level not-found davranışı uygulanır. Route değişip /products/43 olduğunda component aynı kalsa bile data dependency değiştiği için yeni yükleme yapılabilir.

Kullanıcı Profil Sayfası Örneği

User profile route username veya stable identifier kullanabilir. /users/ayse paylaşılabilir profil URL'si oluşturabilir. Kullanıcının erişim permission'ı ayrı authorization katmanında kontrol edilmelidir. Username değişebiliyorsa redirect veya canonical URL politikası gerekebilir. Public ve private profile aynı route modelinde farklı data sonucu üretebilir.

Slug mı ID mi Kullanılmalı?

ID genellikle database resource için stabil ve unique değer sağlar. Slug kullanıcı ve SEO açısından daha anlamlı URL oluşturabilir. Slug değişebiliyorsa eski URL'lerden yeni canonical URL'ye redirect stratejisi gerekebilir. Bazı sistemler ID ve slug'ı birlikte kullanır. Seçim resource lifecycle, public visibility ve URL stability ihtiyacına göre yapılmalıdır.

Geçersiz Parametrelerin Yönetimi

Route matcher dynamic segment bulundu diye parametrenin geçerli olduğunu varsaymamalıdır. Format invalid ise data request yapmadan hata route'una geçilebilir. Resource bulunmuyorsa API 404 sonucu page not-found state üretir. Public indexlenebilir sayfalarda gerçek HTTP status stratejisi rendering architecture ile birlikte düşünülmelidir. Kullanıcıya boş ekran yerine anlamlı recovery link'leri verilmelidir.

Nested Routes Nedir?

Nested routes URL ve component layout hiyerarşisini birlikte ifade etmeyi sağlar. Parent route ortak layout veya data scope oluşturabilir. Child route yalnızca iç content bölgesini değiştirebilir. Dashboard, account settings ve documentation gibi bölümlerde bu yapı oldukça kullanışlıdır. Gereğinden fazla nesting ise route dependency ve relative link davranışını zorlaştırabileceği için hierarchy gerçek information architecture'ı yansıtmalıdır.

Parent Route ve Child Route

Parent route daha geniş bir application bölümünü temsil eder. Child route bu bölümün belirli alt ekranını tanımlar. Parent component child route için outlet alanı sunabilir. Parent data veya navigation menüsü child ekranlar arasında korunabilir. Route tree URL tree ile tamamen aynı olmak zorunda değildir fakat aralarında anlaşılır ilişki bulunmalıdır.

Layout Mantığı

Layout route shared header, sidebar veya page shell gibi parçaları tekrar kullanmayı sağlar. Nested child değiştiğinde layout component'i korunabilir. Bu davranış gereksiz remount ve data reload işlemlerini azaltabilir. Layout route path segment eklemeden yalnızca component hierarchy sağlayan router modellerinde de bulunabilir. Layout state'in hangi child navigation'da korunacağı açık şekilde test edilmelidir.

Nested URL Hiyerarşisi

/dashboard/settings URL'si dashboard altında settings görünümünü doğal şekilde ifade eder. Breadcrumb ve relative navigation bu hiyerarşiden faydalanabilir. Her UI component hierarchy'sini URL path'ine taşımak gerekmez. Yalnızca navigasyon anlamı taşıyan yapılar route segment olmalıdır. URL depth kullanıcıya information architecture hakkında anlaşılır sinyal vermelidir.

Dashboard Örneği

Dashboard genellikle ortak sidebar ve header taşıyan bir parent route için iyi örnektir. Ana dashboard route özet ekranını gösterebilir. Profile ve settings child route olarak aynı layout içinde render edilebilir. Parent level authorization bütün child route'lara ortak uygulanabilir. Data loader strategy parent ve child ihtiyaçlarını ayrı veya paralel yönetebilir.

/dashboard

/dashboard parent bölümün index ekranını temsil edebilir. Kullanıcı genel özet veya başlangıç widget'larını görür. Parent layout aynı URL'de kendi index child'ını render edebilir. Direct navigation authentication kontrolünden geçmelidir. Back ve refresh davranışı dashboard başlangıç state'ini doğru şekilde oluşturmalıdır.

/dashboard/profile

/dashboard/profile kullanıcı profil ayarlarını aynı dashboard shell içinde gösterebilir. Parent sidebar korunur. Child route profile component'ini outlet alanında render eder. Profile form state navigation sırasında yanlışlıkla başka child route'a taşınmamalıdır. Unsaved changes gerekiyorsa navigation guard veya confirmation behavior ayrıca tasarlanabilir.

/dashboard/settings

/dashboard/settings account veya application settings ekranını temsil edebilir. Route permission profile ekranından farklı olabilir. Parent authorization tek başına bütün child permission'larını karşılamayabilir. Settings data child loader üzerinden alınabilir. URL doğrudan açıldığında aynı layout ve permission pipeline tekrar çalışmalıdır.

Nested Route Tasarımında Yapılan Hatalar

Her component'i route hierarchy içine koymak gereksiz nesting oluşturabilir. URL yapısı internal component tree'nin aynası olmak zorunda değildir. Relative path davranışı fazla derin route ağacında geliştiriciler için zorlaşabilir. Parent loader'ın bütün child'lar için gereksiz data yüklemesi performans problemi oluşturabilir. Nesting yalnızca shared layout, path hierarchy veya navigation semantics gerçek değer sağladığında kullanılmalıdır.

Programatik Yönlendirme

Her navigation kullanıcı link tıklamasıyla başlamaz. Form submission, authentication veya business workflow sonucunda kod üzerinden route değişikliği gerekebilir. Router bu kullanım için programmatic navigation API sunar. Yeni history entry oluşturmak ile current entry'yi replace etmek arasında bilinçli seçim yapılmalıdır. Programmatic redirect link semantics taşıyan normal kullanıcı navigasyonunun yerine gereksiz biçimde kullanılmamalıdır.

Link ile Navigation

Kullanıcı belirli URL'ye gitmeyi seçiyorsa semantic anchor veya framework Link component'i doğru araçtır. Link keyboard, context menu ve open-in-new-tab gibi native browser davranışlarını korur. Router link client navigation optimizasyonunu ekleyebilir. Button yalnızca navigation için kullanılmamalıdır. Semantics hem accessibility hem kullanıcı beklentisi açısından önemlidir.

Kod Üzerinden Navigation

Programmatic navigation business event tamamlandıktan sonra route değiştirmek için uygundur. Örneğin kayıt işlemi başarılı olduğunda detay ekranına geçilebilir. Router'ın navigation function'ı kullanılmalıdır. Doğrudan window.location kullanmak full document reload oluşturabilir. External destination veya bilinçli hard navigation gerektiğinde native location API yine uygun olabilir.

Form Gönderildikten Sonra Redirect

Create form başarıyla gönderildiğinde yeni kaydın detail route'una yönlendirme yapılabilir. Navigation yalnızca server mutation gerçekten başarılı olduktan sonra gerçekleşmelidir. Validation error durumunda kullanıcı form üzerinde kalmalıdır. Duplicate submit ve pending state ayrıca yönetilmelidir. Redirect target server tarafından yeni oluşturulan stable ID üzerinden üretilebilir.

Login Sonrası Redirect

Kullanıcı protected route'tan login ekranına gönderildiyse target route bilgisi güvenli biçimde korunabilir. Authentication tamamlandıktan sonra kullanıcı başlangıçta gitmek istediği route'a yönlendirilir. Redirect target open redirect riskine karşı same-origin veya allowlist kontrolünden geçmelidir. Login page history behavior push ve replace seçimiyle kullanıcı beklentisine uygun hale getirilebilir. Authorization yine destination data request'inde backend tarafından doğrulanmalıdır.

push ve replace Semantiği

Push kullanıcı history'sine yeni bir navigasyon adımı ekler. Replace mevcut adımı yeni location ile değiştirir. Kullanıcının back ile önceki ekrana dönmesi mantıklıysa push genellikle uygundur. Otomatik normalization veya geçici redirect state'ini history'de tutmak istenmiyorsa replace seçilebilir. Seçim teknik convenience yerine back button deneyimine göre yapılmalıdır.

Geri Butonunun Beklenen Davranışını Korumak

Kullanıcı geri tuşunun yaptığı şeyi tahmin edebilmelidir. Her filter değişikliğinde push kullanmak onlarca history entry üretebilir. Her navigasyonda replace kullanmak ise anlamlı sayfa geçmişini silebilir. Product flow üzerinden history senaryoları açıkça test edilmelidir. Browser navigation web uygulamasının ana UX parçalarından biri olarak ele alınmalıdır.

Protected Routes ve Authentication

Protected route authenticated veya belirli yetkiye sahip kullanıcılar için UI erişimini kontrol eder. Client router authentication state'e göre route'u render edebilir veya login ekranına redirect yapabilir. Bu behavior kullanıcı deneyimi sağlar fakat gerçek güvenlik sınırı değildir. Browser'daki JavaScript kullanıcı tarafından değiştirilebilir ve network request doğrudan yapılabilir. Hassas data ve işlemlerin authorization kontrolü backend üzerinde mutlaka uygulanmalıdır.

Protected Route Nedir?

Protected route belirli condition karşılanmadan görünümü açmayan route modelidir. En yaygın condition kullanıcının giriş yapmış olmasıdır. Role veya permission bilgisi de route access kararını etkileyebilir. Router component render etmeden önce auth state kontrolü yapabilir. Bu mekanizma backend authorization'ın yerine geçmez.

Authentication Kontrolü

Authentication kullanıcının kimliğinin doğrulanmış olup olmadığını belirler. Client application session veya token state'inden bunu anlayabilir. Initial load sırasında auth state henüz bilinmiyorsa loading state gerekir. Yanlışlıkla protected content'in kısa süre görünmesini önlemek için auth hydration tamamlanmadan route kararı verilmemelidir. Backend her protected API request'i ayrıca authenticate etmelidir.

Authorization ve Role-Based Routing

Authentication kullanıcının kim olduğunu, authorization ise ne yapabileceğini belirler. Admin route yalnızca role veya permission bilgisi uygun kullanıcıya gösterilebilir. Client route guard navigation ve menu görünürlüğünü düzenler. API endpoint aynı permission kuralını server tarafında uygulamalıdır. Role string'lerini UI'ın her noktasına dağıtmak yerine permission abstraction kullanmak daha sürdürülebilir olabilir.

Kullanıcı Giriş Yapmamışsa Ne Olmalı?

Protected route'a unauthenticated kullanıcı geldiğinde login ekranına redirect yapılabilir. Uygulama istenen target URL'yi geri dönüş için saklayabilir. Public landing veya permission explanation göstermek product requirement'a bağlıdır. Redirect loop oluşmaması için login route'un kendisi doğru şekilde istisna tutulmalıdır. Session expire senaryosu direct navigation kadar ayrıca test edilmelidir.

Login Sonrası Kullanıcıyı Eski Route'a Döndürmek

Login öncesindeki location state veya güvenli query parameter target route'u saklayabilir. Authentication sonrası router bu URL'ye navigation yapar. External URL kabul edilmemelidir. Target artık erişilebilir değilse default dashboard fallback kullanılabilir. History davranışı login ekranını back stack'te tutup tutmama kararına göre düzenlenmelidir.

Client-Side Route Guard Güvenlik Sağlar mı?

Client-side guard tek başına güvenlik sağlamaz. Kullanıcı browser JavaScript'ini manipüle edebilir veya API request'i router'ı tamamen atlayarak gönderebilir. Guard yalnızca UI navigation kontrolü ve daha iyi kullanıcı deneyimi sağlar. Hassas işlemin gerçek authorization kararı server üzerinde verilmelidir. Bu ayrım security architecture'da temel prensiptir.

UI Erişim Kontrolü

UI route guard yetkisiz kullanıcının kullanamayacağı ekranı görmesini engelleyebilir. Menu item veya button da aynı permission modeline göre gizlenebilir. Bu davranış gereksiz confusion'ı azaltır. Ancak DOM veya client bundle içinde bulunan bilgilerin gizlenmesi security boundary değildir. Secret data backend response'a hiç dahil edilmemelidir.

Gerçek Yetkilendirmenin Backend'de Yapılması

Backend her protected resource için authenticated identity ve permission kontrolü yapmalıdır. Client'ın gönderdiği role bilgisine güvenilmemelidir. Route guard bypass edilse bile API unauthorized request'i reddetmelidir. Error response client tarafından uygun login veya forbidden ekranına dönüştürülebilir. UI ve backend aynı authorization modelini farklı sorumluluklarla desteklemelidir.

URL'yi Uygulama State'inin Bir Parçası Olarak Kullanmak

URL yalnızca navigation adresi değil yeniden oluşturulabilir application state kaynağıdır. Route parameter hangi entity'nin açık olduğunu, search parameter hangi filter'ın seçildiğini gösterebilir. Kullanıcı URL'yi paylaşınca aynı state'in önemli bölümü başka session'da tekrar kurulabilir. Bu özellik SPA'yı browser'ın temel web modeliyle uyumlu hale getirir. URL ile local state arasında duplicate source of truth oluşturmak yerine ownership açık belirlenmelidir.

URL Neden Bir State Kaynağıdır?

URL browser tarafından persist edilen ve kullanıcı tarafından görülen bir state temsilidir. Refresh sırasında memory state kaybolsa bile URL korunur. Browser history her URL durumunu navigation geçmişine bağlayabilir. Bookmark ve link sharing aynı state'i başka zamanda veya başka cihazda açabilir. Bu özellik URL'yi navigasyonla ilgili state için güçlü kaynak yapar.

Shareable State

Shareable state başka bir kullanıcı aynı link'i açtığında anlamlı sonuç üretmelidir. Product ID ve public filter iyi örneklerdir. Session-specific object reference URL'de anlam taşımaz. Access permission sonucu farklı olsa bile route intention korunabilir. Shareability testleri copy-paste edilmiş direct URL üzerinden yapılmalıdır.

Bookmarkable State

Bookmark kullanıcının daha sonra aynı location'a dönmesini sağlar. URL yeterli bilgiyi taşıyorsa uygulama state'i yeniden kurabilir. Temporary memory ID veya previous page state'e bağımlı route bookmark için kötü deneyim yaratır. Resource artık bulunmuyorsa anlamlı not-found state gösterilmelidir. Long-lived application'da eski URL version'ları redirect ile desteklenebilir.

Refresh Sonrası State Restoration

Refresh bütün JavaScript memory state'ini sıfırlar. Uygulama current URL'yi okuyup route ve query state'ini yeniden oluşturmalıdır. Persistent auth ve preferences storage veya server session üzerinden geri alınabilir. Data tekrar API'den yüklenebilir. Route yalnızca önceki in-memory state varsa çalışıyorsa deep-linkable değildir.

URL'yi Single Source of Truth Olarak Kullanmak

Filter hem URL hem local state'te ayrı ayrı tutulursa senkronizasyon problemi çıkabilir. Mümkünse UI değeri doğrudan URL search params'ten türetilebilir. User interaction URL'yi günceller ve render aynı kaynaktan beslenir. Performance veya controlled input ihtiyacı local draft state gerektiriyorsa commit noktası açık belirlenmelidir. Bir state'in hangi katmana ait olduğu net olmalıdır.

URL → UI Senkronizasyonu

Direct URL veya back navigation olduğunda UI current location'dan türetilmelidir. Filter controls search params'i okumalıdır. Dynamic route component parametreye göre doğru entity'yi göstermelidir. URL invalid value içeriyorsa normalization veya fallback uygulanmalıdır. UI'ın eski local state'i URL'den daha güçlü kaynak olmamalıdır.

UI → URL Senkronizasyonu

Kullanıcı filter veya pagination değiştirdiğinde URL gerekliyse güncellenmelidir. Update serializer tek bir canonical parameter format üretmelidir. Default değerlerin URL'den kaldırılması daha temiz link sağlayabilir. Push veya replace seçimi interaction türüne göre yapılmalıdır. UI update ve URL update aynı transaction mantığıyla ilerlemelidir.

Refresh Sonrası State Nasıl Kurtarılır?

Refresh sırasında JavaScript runtime yeniden başladığı için memory içinde tutulan state kaybolur. Router current URL'den navigation state'ini yeniden kurar. Auth ve preferences gibi persistent bilgiler güvenli storage veya backend session'dan alınabilir. Route'a bağlı business data tekrar API'den yüklenir veya persistent cache kullanılabilir. İyi SPA mimarisi refresh'i özel hata durumu değil desteklenen navigation senaryosu olarak görür.

In-Memory State Neden Kaybolur?

JavaScript variable ve framework store mevcut document runtime'ına bağlıdır. Hard refresh eski document'i sonlandırır. Yeni document yeni JavaScript execution context oluşturur. Memory state doğal olarak baştan başlar. Persist edilmesi gereken state URL, storage veya server tarafında tutulmalıdır.

URL'den State Yeniden Oluşturma

Router pathname ve search parametrelerini başlangıç state'i olarak okuyabilir. /products/42?tab=reviews hem entity hem selected tab bilgisini taşıyabilir. Component bu bilgi üzerinden aynı UI'ı yeniden kurar. Data server'dan tekrar yüklenebilir. URL'nin yeterli navigasyon bilgisi taşıması restoration işlemini basitleştirir.

State Hydration Nedir?

Hydration kelimesi farklı frontend context'lerinde farklı detaylara sahip olabilir. Routing açısından persisted veya server-provided state'in yeni application runtime'a yeniden aktarılması anlamında kullanılabilir. SSR framework'lerinde server-rendered HTML'nin client-side behavior ile birleştirilmesi için de özel teknik anlam taşır. Auth session, initial data ve router location bu başlangıç sürecinin parçaları olabilir. Terminoloji kullanılırken hangi hydration türünden söz edildiği açık tutulmalıdır.

API Verisi ile URL Parametrelerini Eşleştirme

Route parameter data request için key görevi görebilir. API sonucu parametredeki resource'a karşılık gelmelidir. Request tamamlanmadan kullanıcı başka route'a geçerse eski response yeni UI'a yazılmamalıdır. Query cache key current parameter ile ilişkilendirilmelidir. Invalid veya missing entity sonucu route-level not-found davranışına dönüştürülebilir.

Geçersiz URL'lerde Fallback

Kullanıcı elle unsupported query value yazabilir. Eski bookmark artık bulunmayan path içerebilir. Router veya parser bu durumları güvenli şekilde ele almalıdır. Default route, redirect veya 404 davranışı domain anlamına göre seçilir. Uygulama invalid URL yüzünden white screen vermemelidir.

Race Condition Problemleri

Refresh veya hızlı navigation sırasında birden fazla async request aynı anda çalışabilir. Eski route request'i daha sonra tamamlanıp yeni route state'ini bozabilir. AbortController veya request identity kontrolü bu riski azaltır. Data library current query key'e göre stale result yönetebilir. Router cancellation semantics varsa loader seviyesinde de kullanılabilir.

Back ve Forward Butonları Nasıl Yönetilir?

Browser history kontrolü SPA'nın web platformuyla uyumunun önemli göstergesidir. Kullanıcı back yaptığında yalnızca URL değil ilgili UI da geçmiş state'e dönmelidir. Router history navigation event'ini dinleyip current location'a göre render yapar. Query-based modal veya filter gibi state'ler history'ye yazılıyorsa geri tuşu bunları da etkileyebilir. Gereksiz history kayıtları oluşturmak kullanıcıyı defalarca geri basmaya zorlayabileceği için push ve replace semantiği bilinçli kullanılmalıdır.

Browser History Beklentisi

Kullanıcı yeni sayfa görünümüne geçtiğinde back ile önceki görünümü bekler. SPA bu mental modeli korumalıdır. Internal implementation component swap olsa bile kullanıcı bunu navigation olarak algılar. History design teknik state değişikliklerine değil kullanıcı algısına göre yapılmalıdır. Mobil browser gesture navigation da aynı history modelini kullanabilir.

popstate ile UI Güncelleme

History traversal current entry'yi değiştirdiğinde router yeni location'ı okumalıdır. Route matcher tekrar çalışır. UI previous route'a göre render edilir. Bu akış pushState navigation'dan farklı trigger ile başlasa da aynı rendering pipeline'ını kullanabilir. Duplicate logic state divergence riskini artırır.

State ile URL'nin Ayrışması Problemi

URL back ile değişirken local filter state değişmezse kullanıcı çelişkili ekran görür. Bu problem URL state'inin local state'e kopyalanıp yalnızca initial render'da okunmasından kaynaklanabilir. Location değişikliği dependency olarak izlenmelidir. Mümkünse UI current URL'den türetilmelidir. State ownership açık olmadığında routing bug'ları kolay oluşur.

Modal ve Filtrelerin History'ye Eklenmesi

Paylaşılabilir ürün modal'ı ayrı route state'i olarak history'ye eklenebilir. Kullanıcı back ile modal'ı kapatabilir. Küçük tooltip veya dropdown için aynı davranış gereksizdir. Filtre değişimleri bazen replace, önemli filtre snapshot'ları ise push isteyebilir. Product ekibi beklenen history UX'ini gerçek kullanıcı senaryolarıyla belirlemelidir.

Gereksiz History Kayıtlarını Önlemek

Search input'ta her karakter için push entry oluşturmak kötü deneyimdir. Kullanıcı back tuşuna bastığında aynı sayfada karakter karakter geri gider. Debounced replaceState veya submit sonrası tek push daha mantıklı olabilir. Scroll gibi çok sık değişen state history URL entry'si olmamalıdır. History yalnızca anlamlı navigation checkpoint'leri taşımalıdır.

Route-Based Data Fetching

Route tabanlı data fetching navigasyon için gerekli veriyi route lifecycle ile ilişkilendirir. Component-based fetching component mount olduktan sonra request başlatabilir. Route loader yaklaşımı ise data requirement'ını route configuration'a daha yakın tanımlayabilir. Parent ve child data paralel başlatılırsa waterfall süresi azaltılabilir. Navigation değiştiğinde artık gerekmeyen request'lerin iptal edilmesi stale data problemlerini önlemeye yardımcı olur.

Route Değiştiğinde Veri Ne Zaman Yüklenmeli?

Data yükleme zamanı uygulamanın rendering strategy ve router modeline bağlıdır. Component mount sonrası fetching basit ve lokal bir yaklaşımdır. Route loader navigation başlamadan veya sırasında data request'ini başlatabilir. Kritik above-the-fold data daha erken yüklenmekten fayda görebilir. Prefetch ise kullanıcı route'a gitmeden request başlatabilir.

Component-Based Fetching

Component kendi ihtiyaç duyduğu data'yı mount veya parameter değişiminde yükler. Bu yaklaşım component ownership açısından anlaşılırdır. Nested component'ler sırayla mount olursa network waterfall oluşabilir. Error ve pending state her component'te tekrar edebilir. Data caching library bu modelin birçok dezavantajını azaltabilir.

Route Loader Yaklaşımı

Route loader data requirement'ını route tanımıyla birleştirir. Router navigation sırasında hangi loader'ların gerekli olduğunu bilir. Redirect veya 404 kararı component render edilmeden önce verilebilir. Nested loader'lar router'a bağlı olarak paralel çalıştırılabilir. Modern data router'lar pending ve error state'i navigation lifecycle'ın parçası haline getirebilir.

Parallel Data Loading

Bir page için user, product ve recommendation verisi birbirinden bağımsızsa request'ler paralel başlatılabilir. Sequential component mount her request'in önceki response'u beklemesine yol açabilir. Route tree data dependency'yi önceden bildiğinde parallelization daha kolay olur. Gerçek dependency varsa ikinci request ilk sonuca bağlı kalabilir. Performance optimization dependency graph'i doğru anlamaya dayanmalıdır.

Waterfall Problemi

Waterfall bir request tamamlandıktan sonra gereksiz yere diğer request'in başlaması durumudur. Nested component fetching bu pattern'i kolayca üretebilir. Network latency toplam navigation süresini büyütür. Route-level data planning veya prefetch request'leri daha erken başlatabilir. Browser network trace waterfall tespiti için kullanılabilir.

Navigation Sırasında Loading State

Yeni route data beklerken kullanıcıya navigation'ın devam ettiğini gösteren feedback verilmelidir. Tüm ekranı spinner ile kapatmak her zaman en iyi yöntem değildir. Eski content korunup belirli alanlarda pending indicator gösterilebilir. Skeleton veya progress indicator context'e göre kullanılabilir. Accessibility açısından loading değişikliği gerektiğinde assistive technology'ye de bildirilebilir.

Önceki Request'lerin İptal Edilmesi

Kullanıcı hızlı biçimde route değiştirirse önceki request artık gerekli olmayabilir. Request iptal edilmezse network kaynağı tüketebilir. Daha önemlisi eski response yanlış state'e uygulanabilir. Cancellation ve stale-result check birlikte kullanılabilir. Router veya data library cancellation sinyali sağlıyorsa request layer bunu desteklemelidir.

AbortController

AbortController fetch gibi desteklenen API'lere cancellation signal sağlayabilir. Route değiştiğinde önceki controller abort edilebilir. Abort sonucu normal application error gibi kullanıcıya gösterilmemelidir. Request wrapper abort reason'ı ayrı değerlendirebilir. Cancellation yalnızca performance değil state correctness açısından da faydalıdır.

Race Condition Önleme

Request'i iptal etmek her durumda mümkün olmayabilir. Current request ID veya route key response geldiğinde tekrar kontrol edilebilir. Stale response active state'i değiştirmemelidir. Data cache library query identity üzerinden bu davranışı merkezi yönetebilir. Integration test hızlı navigation senaryolarını simüle etmelidir.

Route Bazlı Lazy Loading ve Code Splitting

Route-based code splitting kullanıcı ilk kez uygulamayı açtığında bütün ekranların JavaScript kodunu indirmek yerine gerekli bölümleri daha sonra yüklemeyi sağlar. Büyük dashboard veya admin modülü ayrı chunk olabilir. Kullanıcı route'a gitmek üzereyken prefetch ile modül daha erken indirilebilir. Aşırı küçük chunk'lar çok sayıda request ve scheduling overhead oluşturabilir. Split sınırları route kullanım sıklığı ve bundle analizi üzerinden belirlenmelidir.

Route-Based Code Splitting Nedir?

Her route veya route grubu ayrı JavaScript module chunk'ına ayrılabilir. Initial application shell yalnızca başlangıçta gerekli kodu yükler. Kullanıcı başka route'a geçtiğinde ilgili module dinamik olarak import edilir. Router pending UI gösterebilir. Bu pattern özellikle nadiren ziyaret edilen ağır feature'larda etkili olur.

İlk JavaScript Bundle'ını Küçültmek

Büyük initial bundle parse ve execution süresini artırabilir. Route split ilk ekranda gerekmeyen feature kodunu sonraya bırakır. Bu yaklaşım düşük donanımlı cihazlarda daha belirgin fayda sağlayabilir. Shared dependency yanlış split edilirse duplicate chunk riski oluşabilir. Bundle analyzer hangi kodun initial path'e girdiğini gösterebilir.

Route Açıldığında Modülü Yüklemek

Dynamic import route match sonucunda başlatılabilir. Module henüz cache'de değilse network request gerekir. İndirme tamamlanana kadar fallback UI gösterilebilir. Module cache'e girdikten sonraki navigation daha hızlı olur. Load failure network error olarak route-level error handling'e bağlanmalıdır.

Loading Fallback

Lazy module beklenirken kullanıcıya boş ekran gösterilmemelidir. Fallback route'un boyutuna ve beklenen load süresine uygun olmalıdır. Çok hızlı yüklemede spinner flash görünmesi rahatsız edebilir. Minimum delay veya skeleton design değerlendirilebilir. Focus ve announcement behavior accessibility açısından da düşünülmelidir.

Route Prefetching

Prefetch kullanıcı route'a gitmeden kod veya data'yı düşük öncelikle yükleyebilir. Link hover, viewport visibility veya predicted navigation trigger olarak kullanılabilir. Her link'i prefetch etmek mobil network kullanımını artırabilir. User data saver ve connection quality dikkate alınabilir. Prefetch strategy gerçek navigation analytics üzerinden optimize edilmelidir.

Çok Fazla Code Split Yapmanın Dezavantajları

Her component'i ayrı chunk yapmak network ve module scheduling overhead oluşturabilir. Shared dependency parçalanması cache verimliliğini düşürebilir. Kullanıcı bir route'ta ardışık çok sayıda küçük chunk bekleyebilir. Build manifest ve deployment cache invalidation daha zor hale gelebilir. Split sınırı teknik olarak mümkün olan en küçük parça değil kullanıcı açısından anlamlı feature boundary olmalıdır.

404 ve Hata Yönetimi

Routing sisteminde bilinmeyen URL, geçersiz dynamic parameter, API not-found ve module load failure birbirinden farklı hata türleridir. Client-side wildcard route bilinmeyen SPA path için UI sağlayabilir. Server direct request için gerçek HTTP 404 davranışını ayrıca yönetmelidir. Route-level error boundary belirli route subtree'sindeki runtime veya loader hatasını izole edebilir. Public content uygulamalarında 200 response içinde “bulunamadı” ekranı göstermek soft 404 riskini de gündeme getirir.

Client-Side 404

Router hiçbir route pattern bulamazsa not-found component render edebilir. Kullanıcıya ana sayfa veya arama bağlantısı verilebilir. Client-side navigation sırasında bu davranış hızlı ve anlaşılır recovery sağlar. Ancak HTTP response initial document için daha önce 200 gelmiş olabilir. SEO açısından server ve rendering modelinin ayrıca doğru status üretmesi gerekebilir.

Server-Side 404

Gerçek bulunmayan resource için server'ın 404 status döndürmesi web semantics açısından önemlidir. SPA fallback bütün bilinmeyen URL'lere 200 index.html döndürürse public crawler tarafında soft 404 oluşabilir. SSR veya edge routing gerçek route existence bilgisini HTTP response'a yansıtabilir. Tam client-side architecture'da ayrıca noindex veya dedicated not-found stratejisi gerekebilir. Hata yönetimi hosting ve SEO requirement'ıyla birlikte tasarlanmalıdır.

Wildcard Routes

Wildcard route client router'ın son eşleşme seçeneğidir. Specific route'ların önüne konulmamalıdır. Unknown path kullanıcıya not-found ekranı gösterebilir. Bazı file veya documentation route'larında wildcard gerçek feature path'i de temsil edebilir. Bu iki kullanım açık route configuration ile birbirinden ayrılmalıdır.

Geçersiz Dinamik Route Parametreleri

/products/not-a-valid-id route pattern olarak eşleşebilir fakat business olarak geçersiz olabilir. Parametre formatı loader veya page boundary'de validate edilmelidir. Invalid format için request yapılmadan 404 veya redirect kararı verilebilir. Valid formatlı fakat bulunmayan resource API 404 üretebilir. İki hata kullanıcıya benzer ekran gösterse de logging ve monitoring açısından ayrılabilir.

Route-Level Error Boundary

Route-level boundary bir bölümde oluşan render veya data hatasının bütün application shell'i bozmasını önleyebilir. Parent navigation ve global recovery seçenekleri çalışmaya devam edebilir. Error component retry veya safe navigation sağlayabilir. Hassas stack trace production kullanıcıya gösterilmemelidir. Monitoring route ve error context bilgisini kayıt altına almalıdır.

API 404 ile Page 404 Arasındaki Fark

API 404 belirli data resource'un bulunmadığını ifade eder. Page 404 ise requested navigasyon URL'sinin geçerli içerik üretmediğini ifade eder. Product detail route var olabilir fakat product ID bulunmadığında API 404 page-level not-found sonucuna dönüştürülebilir. API endpoint URL'si browser page route'uyla aynı değildir. Error mapping katmanı network semantics'i kullanıcı navigation semantics'ine çevirmelidir.

Routing ve SEO İlişkisi

Public içerik barındıran SPA projelerinde routing SEO'nun temel teknik katmanlarından biridir. Her önemli içerik keşfedilebilir ve tutarlı bir URL'ye sahip olmalıdır. JavaScript tabanlı rendering crawler tarafından işlenebilse bile server-side rendering, static rendering veya prerendering kullanıcı ve crawler için initial content erişimini kolaylaştırabilir. Title, meta description ve canonical gibi metadata route'a göre doğru güncellenmelidir. Gerçek olmayan sayfaların 200 status ile indekslenebilir biçimde sunulması soft 404 sorunlarına yol açabileceği için hata route'ları ayrıca planlanmalıdır.

Her İçeriğin Benzersiz URL'si Olmalı mı?

Arama sonucunda bağımsız olarak bulunması ve paylaşılması anlamlı olan içerikler genellikle benzersiz URL'den fayda görür. Aynı URL altında JavaScript state'iyle tamamen farklı içerik göstermek keşfedilebilirliği ve paylaşımı zorlaştırabilir. Modal veya geçici dropdown gibi her UI durumu ayrı indexable route olmak zorunda değildir. URL bilgi mimarisini yansıtmalıdır. Duplicate içerik oluşturan query kombinasyonlarında canonical stratejisi ayrıca değerlendirilmelidir.

SPA'larda Crawl ve Index Problemleri

JavaScript rendering kullanan sayfalar crawler'ın script çalıştırmasına ve gerekli kaynaklara erişmesine bağımlı olabilir. App shell response içinde temel içerik bulunmuyorsa rendering aşaması daha önemli hale gelir. Broken JavaScript veya blocked resource içerik keşfini etkileyebilir. Normal anchor bağlantıları crawler'ın route URL'lerini keşfetmesine yardım eder. Search-critical projelerde server veya static rendering risk ve performans açısından güçlü seçenekler sunabilir.

Dynamic Metadata Yönetimi

Her route aynı title ve description ile bırakılmamalıdır. Route data veya loaded content metadata üretmek için kullanılabilir. Navigation tamamlandığında document head current content'i yansıtmalıdır. SSR kullanılıyorsa aynı metadata initial HTML response içinde de bulunmalıdır. Client ve server metadata üretimi mümkünse ortak source of truth üzerinden yürütülmelidir.

title

Document title hem kullanıcı browser tab'ında hem search result context'inde önemlidir. Route değiştiğinde title yeni içeriği açıklamalıdır. “Loading” gibi geçici title navigation tamamlandıktan sonra doğru değere dönmelidir. Duplicate page title'lar içerik ayrımını zorlaştırabilir. Accessibility açısından screen reader kullanıcıları route değişikliğini title değişiminden de anlayabilir.

meta description

Meta description route içeriği hakkında kısa ve ilgili özet sağlayabilir. Client-side application navigation sırasında description element'i doğru şekilde güncellenmelidir. Public page server-rendered ise description initial HTML içinde bulunabilir. Aynı generic description bütün route'lara kopyalanmamalıdır. Description doğrudan ranking garantisi değil search result presentation için yararlı metadata'dır.

Canonical URL

Canonical URL aynı veya çok benzer içeriğin tercih edilen adresini belirtmeye yardımcı olur. Filter ve sort parametreleri duplicate content varyasyonları oluşturabilir. Client rendering kullanılıyorsa canonical bilgisinin tutarlı ve mümkünse initial HTML'de açık olması tercih edilir. JavaScript ile farklı conflicting canonical değerleri üretilmemelidir. URL normalization ve internal linking canonical stratejiyle aynı yönde olmalıdır.

Hash URL'lerin SEO Etkisi

Hash fragment server request path'inin normal parçası değildir. Public content navigation'ını yalnızca hash state'e bağlamak standard pathname modeline göre daha sınırlı olabilir. Search-critical route'larda normal crawlable URL yapısı tercih edilmesi daha anlaşılır architecture sağlar. Hash document section navigation için doğal kullanım alanını korur. Legacy hash router migration'ında redirect ve canonical strategy dikkatle planlanmalıdır.

SSR, SSG ve Prerendering

SSR route için HTML'i request sırasında server üzerinde oluşturur. SSG build sırasında önceden HTML üretir. Prerendering belirli route'ların crawler ve kullanıcıya hazır HTML ile sunulmasını sağlayabilir. Bu yaklaşımlar client hydration veya navigation ile SPA deneyimini devam ettirebilir. Public içerik miktarı, freshness ihtiyacı ve hosting architecture hangi yöntemin uygun olduğunu belirler.

Soft 404 Problemi

Soft 404 browser'a 200 success response verilirken sayfanın gerçekte bulunamadığını gösteren durumdur. SPA fallback bütün bilinmeyen URL'leri index.html ile 200 döndürdüğünde bu risk oluşabilir. Search engine gerçek content olmadığını farklı sinyallerden anlamaya çalışabilir. Public not-found route için anlamlı HTTP status veya uygun indexing stratejisi uygulanmalıdır. Client-only uygulamada error page'in yanlışlıkla indexlenmesini önlemek ayrıca kontrol edilmelidir.

Routing ve Accessibility

SPA navigation full page load oluşturmadığı için browser'ın normal document navigation sırasında sağladığı bazı accessibility sinyalleri otomatik gerçekleşmeyebilir. Screen reader kullanıcısı içerik değiştiğini fark etmeyebilir. Route değişiminde document title güncellemek, focus'u anlamlı konuma taşımak ve loading state'i erişilebilir biçimde bildirmek gerekir. Navigation için semantic anchor kullanımı keyboard ve assistive technology behavior'ını korur. Accessibility routing component'ine sonradan eklenen özellik değil navigation architecture'ın başlangıç requirement'ı olmalıdır.

SPA Navigation Neden Screen Reader İçin Sorun Oluşturabilir?

Normal document load screen reader'a yeni page context'i hakkında çeşitli sinyaller sağlar. Client-side view değişiminde document aynı kaldığı için bu sinyaller daha sınırlı olabilir. Kullanıcı link'e bastıktan sonra focus eski link üzerinde kalabilir. Yeni content görünse bile assistive technology bunu otomatik olarak anlamayabilir. Router-level accessibility strategy bu geçişi açık hale getirmelidir.

Route Değiştiğinde Document Title Güncelleme

Title yeni route'un bağlamını açıklamalıdır. Screen reader kullanıcıları page değişikliğini title üzerinden fark edebilir. Browser history listesi de anlamlı title'dan faydalanabilir. Async data gerekiyorsa final title data geldikten sonra güncellenmelidir. Title üretimi route metadata system'inin parçası haline getirilebilir.

Focus Management

Navigation sonrası focus'un nerede olacağı bilinçli seçilmelidir. Ana heading veya main content başlangıcı çoğu page transition için anlamlı hedef olabilir. Her route değişiminde focus'u body'ye bırakmak kullanıcıya yeterli context vermeyebilir. Modal route ise focus trap ve return-focus behavior gerektirir. Back navigation için önceki focus state'in restore edilmesi bazı deneyimlerde faydalı olabilir.

Klavye Navigasyonu

Router link'leri gerçek anchor semantics'ini korumalıdır. Enter ile aktivasyon ve tab sırası browser tarafından doğal şekilde desteklenir. Navigation amacı taşıyan div click handler keyboard kullanıcıları için sorun oluşturur. Active navigation state gerektiğinde uygun ARIA bilgisi kullanılabilir. Custom keyboard shortcut normal browser navigation davranışlarını bozmamalıdır.

Loading ve Route Değişikliklerini Kullanıcıya Bildirme

Uzun navigation sırasında görsel spinner tek başına yeterli olmayabilir. Accessible live region loading durumunu gerekli olduğunda duyurabilir. Çok hızlı state değişimlerinde aşırı announcement kullanıcıyı yorabilir. Completion message veya yeni heading focus'u context sağlayabilir. Loading feedback user testing ile gerçek assistive technology üzerinde doğrulanmalıdır.

Semantik Link Kullanımı

Başka bir location'a götüren control için anchor doğru HTML element'idir. Button bir action gerçekleştirir. Router Link component'i sonunda semantic anchor üretmelidir. Bu ayrım open-in-new-tab, copy-link ve screen reader role behavior'larını korur. Styling gereksinimi element semantics'ini değiştirmemelidir.

Scroll Yönetimi

Full page navigation browser tarafından doğal scroll behavior'larıyla gelirken SPA navigation bunu daha açık yönetmek zorunda kalabilir. Yeni route'a geçildiğinde çoğu kullanıcı içeriğin üstünden başlamayı bekler. Back navigation ise önceki scroll position'a dönmek isteyebilir. Query param değişikliği her zaman scroll reset gerektirmez. Router ve browser scroll restoration özellikleri birlikte düşünülmelidir.

Route Değiştiğinde Scroll Nereye Gitmeli?

Yeni bağımsız page route genellikle top konumuna geçebilir. Aynı page filter değişiminde scroll'u korumak daha iyi deneyim olabilir. Hash anchor belirli section'a scroll gerektirebilir. Modal route background scroll position'ını korumalıdır. Tek genel kural yerine navigation type'a göre scroll policy belirlenebilir.

Scroll to Top

Basit router route pathname değişiminde window.scrollTo ile üst konuma geçebilir. Ancak browser back davranışını aynı şekilde override etmek previous position restoration'ı bozabilir. New navigation ve history traversal birbirinden ayrılmalıdır. Reduced motion preference varsa smooth scrolling behavior dikkatle kullanılmalıdır. Nested scroll container varsa window scroll tek başına yeterli olmayabilir.

Browser Back Sonrası Scroll Restoration

Kullanıcı ürün listesinde aşağı indikten sonra detay sayfasına geçebilir. Back yaptığında liste üzerindeki eski konumuna dönmek beklenen davranıştır. Browser normal document history'de bu davranışı destekleyebilir. SPA router manual scroll management yapıyorsa ilgili position'ı history entry veya router cache ile ilişkilendirebilir. Infinite list data restoration ile scroll restoration birlikte ele alınmalıdır.

Nested Scroll Container Problemleri

Dashboard layout içinde scroll window yerine iç container üzerinde olabilir. Browser'ın built-in restoration davranışı bu container'ı otomatik yönetmeyebilir. Router hangi scroll area'nın route'a ait olduğunu bilmelidir. Nested child navigation parent scroll'u korurken child panel scroll'unu sıfırlayabilir. Layout-specific scroll policy test edilmelidir.

History scrollRestoration

Browser History API scrollRestoration özelliği üzerinden automatic veya manual yaklaşım sunabilir. Router manual restoration yapacaksa browser'ın kendi behavior'ıyla çakışmaması gerekir. Manual mode seçmek bütün scroll responsibility'yi application'a bırakabilir. Back ve forward scenario'ları farklı browser'larda test edilmelidir. Gereksiz custom logic built-in davranışı bozabilir.

Routing Performansı

Client navigation full document reload maliyetini azaltabilir fakat her SPA navigation otomatik olarak hızlı değildir. Büyük route bundle, sequential data fetching veya gereksiz parent render performansı düşürebilir. Lazy loading ve prefetch doğru kullanıldığında navigation latency azalır. Route cache yeniden data fetch ihtiyacını düşürebilir fakat stale data politikası gerektirir. Gerçek kullanıcı navigation süresi performance measurement ile izlenmelidir.

Full Page Reload ile Client Navigation Karşılaştırması

Full reload yeni document lifecycle başlatır. Client navigation mevcut application runtime'ını korur ve yalnızca gerekli data ile code'u yükleyebilir. Bu durum tekrar kullanılan layout ve cached resources için avantaj sağlayabilir. Büyük JavaScript runtime veya memory problemine sahip SPA yine yavaş olabilir. Architecture performansı yalnızca navigation türü üzerinden değerlendirilmemelidir.

Gereksiz Render'ları Önleme

Route değiştiğinde bütün global state'in yeniden üretilmesi gereksiz render oluşturabilir. Layout ve provider hierarchy dikkatli tasarlanmalıdır. Router location object'ini geniş context üzerinden her component'e dağıtmak geniş update tetikleyebilir. Component yalnızca ihtiyaç duyduğu route state'i tüketmelidir. Performance profiling gerçek bottleneck bulunmadan premature optimization yapmayı önler.

Route Lazy Loading

Lazy loading initial bundle'ı küçültebilir. Nadir kullanılan route kodu ihtiyaç anında indirilebilir. Chunk load latency prefetch ile azaltılabilir. Çok sık kullanılan core route'u aşırı split etmek ters etki yaratabilir. Bundle size ve route frequency birlikte analiz edilmelidir.

Prefetch ve Preload

Preload browser'a kaynağın yakın zamanda gerekli olacağını daha güçlü biçimde bildirirken prefetch daha düşük öncelikli gelecekteki kullanım için tercih edilebilir. Framework veya bundler bu davranış için farklı API sunabilir. Gereğinden fazla preload initial critical resource'larla rekabet edebilir. Hover prefetch desktop'ta faydalı olabilir fakat touch device'ta farklı trigger gerekir. Resource hint strategy real-user performance data ile ayarlanmalıdır.

Route Cache Stratejileri

Route data cache back navigation'ı hızlandırabilir. Cache key URL parameter ve relevant search state ile uyumlu olmalıdır. Stale time business data freshness requirement'ına göre belirlenir. UI component instance'ını cache etmek ile data'yı cache etmek farklı tasarım kararlarıdır. Authentication veya tenant değişiminde cache isolation özellikle önemlidir.

Navigation Performance Ölçümü

Navigation başlangıcı ile meaningful content render arasındaki süre ölçülebilir. Network request waterfall ve code chunk load zamanı ayrıca izlenebilir. Real user monitoring farklı cihaz ve bağlantı kalitesindeki sonuçları gösterir. Route-level percentile değerleri en yavaş ekranları bulmaya yardımcı olur. Sadece initial page Core Web Vitals ölçmek SPA içi navigation deneyiminin tamamını göstermez.

React'te SPA Routing

React kendi başına browser route eşleştirme sistemi sağlamaz. React Router gibi routing library'leri URL, history ve React component ağacını birbirine bağlar. Modern React Router belgelerinde Declarative, Data ve Framework kullanım biçimleri ayrıştırılır. Basit Declarative model component matching ve navigation sağlarken Data mode loader, action ve pending state gibi ek router lifecycle özellikleri sunabilir. React öğrenirken API isimlerinden önce location, history ve route matching mantığını anlamak library değişikliklerine daha kolay uyum sağlar.

React Router'ın Rolü

React Router current location ile React view tree arasında routing katmanı oluşturur. URL pattern matching yapar. Link ve programmatic navigation API'leri sunar. Nested route'ları parent layout içine render edebilir. Data-oriented kullanımda loader, action ve navigation pending state gibi ek sorumlulukları da yönetebilir.

BrowserRouter

BrowserRouter browser History API üzerinde declarative client routing sağlar. İçindeki route component'leri current location'a göre eşleştirilir. Deployment server'ı direct pathname isteklerinde SPA fallback sunmalıdır. Basit application'lar için anlaşılır başlangıç sağlar. Data router özelliklerine ihtiyaç arttığında farklı top-level router API'leri değerlendirilebilir.

Routes ve Route

Routes current location için child route configuration'larını değerlendirir. Route belirli pattern eşleştiğinde hangi element veya component'in gösterileceğini tanımlar. Nested Route yapısı URL ve layout hierarchy oluşturabilir. Declarative Route tanımları temel matching için uygundur. Data loading gibi bazı özellikler kullanılan React Router moduna bağlı olarak farklı configuration yaklaşımı gerektirebilir.

Link ve NavLink

Link internal client navigation için semantic anchor davranışını router ile birleştirir. NavLink current route ile ilişkisine göre active veya pending state gibi bilgi sağlayabilir. Normal navigation amacı için programmatic button yerine Link tercih edilmelidir. External URL gerektiğinde standard anchor davranışı kullanılabilir. Active navigation accessibility bilgisinin doğru üretilmesi önemlidir.

useNavigate

useNavigate component kodundan programmatic navigation başlatmaya yarar. Form success veya belirli workflow event'i tipik kullanım alanıdır. Hedef URL, history delta ve replace behavior gibi seçenekler kullanılabilir. Data routing senaryolarında bazı redirect işlemleri loader veya action seviyesinde daha uygun olabilir. Normal link navigation için yine Link semantics'i tercih edilmelidir.

useParams

useParams current route tarafından eşleştirilen dynamic parameter değerlerine erişim sağlar. /posts/:postId route'unda postId component içinde okunabilir. Child route parent parameter'larını da miras alabilir. Parameter string olduğu için domain validation ayrıca yapılmalıdır. Data fetching cache key parameter değişimine duyarlı olmalıdır.

useLocation

useLocation current location object'ini component'e verir. Pathname, search ve history state gibi routing bilgileri bu model üzerinden kullanılabilir. Analytics page-view tracking location değişimine bağlanabilir. Search parsing için ayrı router veya web API helper'ları kullanılabilir. Location object'ini gereksiz local state'e kopyalamak stale state riski doğurabilir.

Nested Routes ve Outlet

React Router child route'ları parent route configuration içinde tanımlayabilir. Parent component Outlet kullanarak matched child'ın render edileceği alanı belirler. Dashboard gibi shared layout yapıları bu modelden faydalanır. Child path parent path'i doğal olarak devam ettirebilir. Layout route bazı configuration biçimlerinde URL segment eklemeden nesting sağlayabilir.

Modern React Router'da Data Routing

Data routing route configuration'ı data requirement ve mutation behavior ile daha yakın ilişkilendirir. Loader route render edilmeden veya navigation sırasında data sağlayabilir. Action form veya mutation workflow'unu router lifecycle'a dahil edebilir. Navigation state pending UI üretmek için kullanılabilir. Bu model component mount sonrası dağınık fetch pattern'lerini bazı projelerde daha merkezi hale getirir.

Vue'da SPA Routing

Vue ekosisteminde Vue Router component tabanlı uygulamalarda URL navigation yönetimi sağlar. Route configuration static ve dynamic path'leri component'lerle eşleştirir. RouterLink client navigation için link abstraction'ı sunar. RouterView current route component'inin render edileceği alanı belirler. Navigation guard ve farklı history mode seçenekleri authorization UX ve deployment requirement'larına göre kullanılabilir.

Vue Router'ın Rolü

Vue Router URL ile Vue component hierarchy arasında bağlantı kurar. Static, dynamic ve nested route tanımları desteklenir. Browser history, hash veya farklı history modları seçilebilir. Programmatic navigation router instance üzerinden yapılabilir. Route state component içinde ilgili composable veya instance API üzerinden okunabilir.

RouterLink

RouterLink internal navigation için link component'idir. Hedef route string veya location object üzerinden belirtilebilir. Client-side navigation yaparken semantic link davranışı korunabilir. Active state navigation menülerinde kullanılabilir. External navigation için normal anchor daha uygun olabilir.

RouterView

RouterView current matched route component'inin görüntülendiği placeholder görevi görür. Nested RouterView child route hierarchy'sini destekler. Parent layout aynı kalırken child view değişebilir. Named view gibi daha gelişmiş yapıların gerçekten gerekli olup olmadığı architecture seviyesinde değerlendirilmelidir. View hierarchy route configuration ile uyumlu tutulmalıdır.

Dynamic Routes

Vue Router dynamic segment üzerinden parametreli route'lar tanımlayabilir. Aynı component farklı parameter ile tekrar kullanılabilir. Parameter değiştiğinde component instance behavior ve data refetch dikkatle yönetilmelidir. Runtime'da route ekleme veya kaldırma gibi ileri kullanım senaryoları da mümkündür. Normal application route'ları çoğunlukla başlangıç configuration'ında açıkça tutulmalıdır.

Navigation Guards

Navigation guards route geçişini redirect edebilir veya durdurabilir. Global, route-specific veya component lifecycle'a yakın guard modelleri kullanılabilir. Async authentication kontrolü navigation'ı pending durumda tutabilir. Client guard gerçek backend authorization'ın yerine geçmez. Unsaved form veya UI permission gibi navigation davranışları için etkili olabilir.

Angular'da SPA Routing

Angular Router framework içinde navigation yönetiminin temel parçalarından biridir. Route configuration URL path'lerini component veya lazy feature yapılarıyla eşleştirir. RouterLink declarative navigation, RouterOutlet ise matched component'in render alanını sağlar. Route parameters ve guards application flow kontrolünü destekler. Angular dokümantasyonunun da vurguladığı gibi client guard güvenlik için tek başına yeterli değildir ve server authorization ayrıca uygulanmalıdır.

Angular Router'ın Rolü

Angular Router SPA içindeki current URL'ye göre application view'ını yönetir. Route recognition, guard, lazy loading ve activation lifecycle event'leri sunar. RouterState aktif route tree bilgisini temsil eder. ActivatedRoute component'e parameter ve query bilgisi sağlayabilir. Routing framework dependency injection ve component lifecycle ile entegre çalışır.

Routes

Routes application route configuration'ını tanımlayan route listesi olarak kullanılır. Her route path, component veya lazy loading bilgisi taşıyabilir. Child route'lar children üzerinden tanımlanabilir. Angular route matching sırasında configuration sırasını dikkate aldığı için daha specific route'ların doğru konumda tutulması önemlidir. Wildcard route fallback olarak en sona yerleştirilir.

RouterLink

RouterLink Angular template içinde declarative navigation sağlar. Standard anchor ile birlikte kullanıldığında link semantics'i korunur. Absolute veya current route'a göre relative navigation tanımlanabilir. RouterLinkActive active navigation styling ve accessibility bilgisini destekleyebilir. Programmatic navigation gerekmediği durumlarda link tabanlı yaklaşım daha doğal web davranışı sunar.

RouterOutlet

RouterOutlet matched route component'inin template içinde yerleştirileceği konumu belirtir. Parent layout header ve navigation'ı korurken child content outlet çevresinde değişebilir. Nested child routes kendi outlet'lerini kullanabilir. Named outlet aynı anda birden fazla route-driven region yönetebilir. Bu özellik gerçek UX ihtiyacı yoksa gereksiz route state oluşturabilir.

Route Parameters

Angular dynamic path segment'leri route parameter olarak sunar. Component ActivatedRoute üzerinden current parameter bilgisine erişebilir. Aynı component üzerinde parameter değişirse observable veya signal-based route data akışı doğru şekilde izlenmelidir. Parameter formatı business layer'a geçmeden doğrulanmalıdır. Snapshot yalnızca navigation lifecycle ihtiyacına uygun olduğunda tercih edilmelidir.

Route Guards

Angular route guards navigation öncesi veya çıkış sırasında karar verebilir. Authentication, unsaved form ve conditional feature matching kullanım alanlarıdır. Guard redirect için uygun URL veya redirect result üretebilir. Client-side guard source code kullanıcı cihazında çalıştığı için gerçek authorization sınırı değildir. Backend endpoint permission kontrolü her zaman bağımsız uygulanmalıdır.

React Router, Vue Router ve Angular Router Karşılaştırması

Bu router araçlarının API tasarımları farklı olsa da altında çözmeye çalıştıkları problem aynıdır. Current URL route configuration ile eşleştirilir. Navigation browser history ile koordine edilir ve uygun UI subtree render edilir. Dynamic parameter, nested route, programmatic navigation ve guard benzeri kavramlar farklı isimlerle tekrar karşımıza çıkar. Bir framework'ten diğerine geçerken temel routing modeli öğrenilmişse yeni API'ye uyum daha kolay olur.

Ortak Routing Prensipleri

Her üç yaklaşım da URL'yi application navigation state'i olarak kullanır. Route configuration path ile view ilişkisini tanımlar. Dynamic segment resource identifier taşır. Nested route shared layout oluşturabilir. Browser history back ve forward behavior'ı framework'ten bağımsız temel web beklentisidir.

API Farklılıkları

React Router component ve data router modlarıyla farklı kullanım biçimleri sunar. Vue Router Vue component ve Composition API yapılarıyla bütünleşir. Angular Router dependency injection, RouterOutlet ve route guard lifecycle'ı ile framework'e daha doğrudan entegredir. Syntax ve configuration detayları farklıdır. Bu farklar temel Browser History API davranışını değiştirmez.

Framework Değişse de Değişmeyen Routing Mantığı

URL parsing her framework'te gereklidir. Path match sonucu view seçilir. Back ve forward history state'ini değiştirir. Direct URL server configuration gerektirir. Query state, authorization ve data loading kararları framework değişse bile aynı architectural soruları ortaya çıkarır.

Önce Routing Mantığını mı Framework API'sini mi Öğrenmeli?

Önce URL, History API ve route matching mantığını öğrenmek daha kalıcı bilgi sağlar. Daha sonra framework API'si bu bilgiyi uygulamayı kolaylaştıran abstraction olarak görülebilir. Sadece hook veya directive ezberlemek library update sırasında öğrenme borcu oluşturur. Vanilla router denemesi browser davranışını anlamaya yardımcı olur. Framework documentation bundan sonra daha anlaşılır hale gelir.

SPA Routing Testleri

Routing yalnızca link'e tıklayıp doğru component'in görünmesini test etmekten ibaret değildir. Dynamic parameter, authentication, history traversal, direct URL ve server fallback ayrı senaryolardır. Unit seviyesinde matcher veya route utility test edilebilir. Integration test router ile component behavior'ını birlikte doğrular. E2E test gerçek browser back, refresh ve URL entry davranışını kontrol ederek production'a en yakın güvenceyi sağlar.

Route Matching Testleri

Static route'un doğru component'e eşleştiği doğrulanmalıdır. Wildcard route bilinmeyen path'i yakalamalıdır. Specific ve dynamic route conflict senaryosu test edilmelidir. Trailing slash veya case policy varsa expected behavior açık olmalıdır. Router library kendi matcher'ını zaten test ettiği için uygulama testleri custom configuration risklerine odaklanmalıdır.

Dynamic Parameter Testleri

Valid parameter doğru data request'i üretmelidir. Invalid format gereksiz request yapmadan fallback'e gidebilir. Parameter route içinde değiştiğinde component stale data göstermemelidir. Encoded value scenario'ları test edilebilir. API 404 sonucu page-level not-found behavior'ı doğrulanmalıdır.

Protected Route Testleri

Authenticated kullanıcı route'a erişebilmelidir. Unauthenticated kullanıcı doğru login flow'una yönlendirilmelidir. Login sonrası return URL behavior'ı test edilmelidir. Wrong role forbidden state üretmelidir. Backend authorization ayrı integration veya API testleriyle ayrıca doğrulanmalıdır.

Back ve Forward Navigation Testleri

Birden fazla route navigation sonrası browser back doğru ekranı göstermelidir. Query filter state geçmiş location'a dönmelidir. Forward tekrar sonraki route'u açmalıdır. Programmatic replace kullanılan flow history'ye gereksiz entry eklememelidir. E2E browser API bu davranışı gerçekçi şekilde test eder.

Direct URL ve Refresh Testleri

Nested route doğrudan address bar üzerinden açılmalıdır. Hard refresh aynı view'ı tekrar oluşturmalıdır. Deployment preview server gerçek fallback configuration ile test edilmelidir. API endpoint direct request yanlışlıkla index.html almamalıdır. Static asset 404 da HTML fallback'e dönmemelidir.

404 Testleri

Bilinmeyen client route not-found UI göstermelidir. Geçersiz entity ID doğru error state üretmelidir. Public page architecture gerçek HTTP status requirement'ını karşılamalıdır. Not-found page main navigation'a recovery sağlamalıdır. Search indexing behavior gerekiyorsa noindex veya rendering response ayrıca test edilmelidir.

End-to-End Navigation Testleri

E2E test user click, URL update ve rendered content'i birlikte doğrular. Page reload ve browser history gerçek browser üzerinde çalıştırılabilir. Auth redirect veya checkout flow route chain'i test edilebilir. Network error ve lazy chunk failure gibi edge case'ler simüle edilebilir. Her route için E2E yazmak yerine kritik navigation journey'leri seçmek daha sürdürülebilir olur.

Routing'de Sık Yapılan Hatalar

Routing hatalarının büyük bölümü yalnızca yanlış path yazmaktan kaynaklanmaz. URL ile state'in ayrışması, server fallback'in unutulması veya history davranışının bozulması production'da daha görünür problemler yaratır. Her UI state'i route yapmak history'yi gereksiz büyütebilir. Hassas verileri query içine koymak privacy riski oluşturabilir. Route architecture browser'ın link, refresh ve back davranışlarını korumayı temel hedef olarak görmelidir.

Her UI State'i Route Yapmak

Dropdown açık mı bilgisi çoğu zaman route olmamalıdır. Aynı şekilde hover ve transient animation state URL için anlamlı değildir. Shareable modal veya multi-step workflow bazı durumlarda route olabilir. Karar kullanıcının bu state'i bağımsız konum olarak algılayıp algılamadığı üzerinden verilmelidir. Fazla routing history ve URL modelini gereksiz büyütür.

URL'yi State ile Senkronize Etmemek

Filter local state'te değişirken query parameter eski kalırsa paylaşılmış URL yanlış görünüm üretir. Back navigation da eski UI state'i koruyabilir. URL source of truth seçildiyse component bundan türetilmelidir. Local draft state gerekiyorsa commit mekanizması açık olmalıdır. Duplicate source of truth routing bug'larının yaygın nedenidir.

Hard Refresh Senaryosunu Test Etmemek

Development router fallback çoğu zaman otomatik çalıştığı için sorun fark edilmeyebilir. Production hosting nested path'i file olarak arayıp 404 döndürebilir. Her önemli route direct URL ile preview environment'ta test edilmelidir. Refresh login ve data hydration behavior'ını da ortaya çıkarır. Soft navigation'ın çalışması deployment'ın doğru olduğunu kanıtlamaz.

Sunucu Fallback Yapılandırmasını Unutmak

Browser history router server rewrite olmadan yalnızca internal navigation'da düzgün görünebilir. Direct request client router yüklenmeden önce server tarafından cevaplanır. Fallback application route'larını index document'e yönlendirmelidir. API ve static file namespace'leri korunmalıdır. Infrastructure configuration routing architecture dokümantasyonuna dahil edilmelidir.

Link Yerine Button Kullanmak

Başka URL'ye gitmek navigation'dır ve semantic link gerektirir. Button yalnızca görünüşü kolay biçimlendirildiği için navigation amacıyla kullanılmamalıdır. Anchor open-in-new-tab ve copy-link gibi browser özelliklerini destekler. Screen reader da element rolünü doğru algılar. Router Link component'i bu semantics'i koruyarak client navigation sağlar.

Her Navigasyonda pushState Kullanmak

Her URL değişikliği yeni history checkpoint olmak zorunda değildir. Search typing ve filter adjustment gibi yüksek frekanslı interaction history'yi doldurabilir. Replace semantiği current state'i normalize etmek için daha uygun olabilir. Gerçek page transition push kullanabilir. History behavior product flow üzerinden belirlenmelidir.

Back Butonunun Davranışını Bozmak

Back event geldiğinde yeniden pushState çağırmak history loop oluşturabilir. Kullanıcı uygulamadan çıkmak isterken sürekli aynı route içinde tutulmamalıdır. Unsaved form confirmation gibi özel durumlar dikkatli tasarlanmalıdır. Browser history kullanıcıya ait bir navigation sistemidir. Application onu kendi internal stack'i gibi kontrol etmeye çalışmamalıdır.

URL'ye Hassas Veri Yazmak

URL birçok sistem tarafından loglanabilir. Query string browser history'de kalabilir. Referrer üzerinden başka origin'e bilgi sızma riski oluşabilir. Token, password veya private payload URL state'i olmamalıdır. Routing state ile secret state birbirinden ayrılmalıdır.

Route'ları Gereğinden Fazla İç İçe Geçirmek

Derin nesting relative link hesaplamasını zorlaştırabilir. Parent loader dependency'leri bütün child route'ları etkileyebilir. Component tree ile URL tree aynı olmak zorunda değildir. Shared layout veya meaningful hierarchy yoksa flat route daha okunabilir olabilir. Route structure user information architecture üzerinden şekillendirilmelidir.

Eski Router API'lerini Güncel Kodda Kullanmak

Router library'leri zaman içinde navigation, data loading ve route configuration API'lerini geliştirebilir. Eski tutorial'lardan doğrudan code kopyalamak deprecated pattern getirebilir. Proje kullandığı router sürümünün güncel resmi dokümantasyonunu esas almalıdır. Migration guide version upgrade öncesi okunmalıdır. Framework API'si değişse bile URL ve History API bilgisi geçerliliğini büyük ölçüde korur.

Routing Mimarisi İçin En İyi Uygulamalar

Sağlam routing architecture URL'yi kullanıcıyla uygulama arasındaki kalıcı navigasyon contract'ı olarak görür. Route isimleri tutarlı ve okunabilir olmalıdır. Navigation state business state'in tamamına dönüşmemelidir. Lazy loading, error boundaries, server fallback ve accessibility başlangıç tasarımına dahil edilmelidir. En önemli test ise route'un link tıklaması dışında direct URL, refresh ve back/forward yollarıyla da aynı şekilde çalışmasıdır.

URL'leri İnsan Tarafından Okunabilir Tutmak

URL business resource ve hierarchy'yi mümkün olduğunca açık ifade etmelidir. Internal database table veya component isimleri path'e sızmamalıdır. Gereksiz uzun parameter listesi readability'yi düşürür. Slug kullanılıyorsa stability politikası bulunmalıdır. Kullanıcı link'e bakarak gideceği content hakkında fikir edinebilmelidir.

Route İsimlendirmesini Tutarlı Hale Getirmek

Singular ve plural resource isimleri application genelinde aynı convention'ı izlemelidir. Aynı action için farklı bölümde farklı path pattern kullanılmamalıdır. Dynamic parameter isimleri de standardize edilebilir. Route helper'lar hard-coded string tekrarını azaltabilir. Consistency onboarding ve refactoring maliyetini düşürür.

Navigation State ile Business State'i Ayırmak

URL hangi entity veya view'ın açık olduğunu gösterebilir. Entity'nin bütün data object'i URL veya history state içinde taşınmamalıdır. Business data cache veya store katmanında tutulabilir. Navigation state resource key üzerinden business layer'a ulaşır. Bu ayrım refresh ve direct navigation davranışını daha güvenilir hale getirir.

Route Konfigürasyonunu Merkezi Yönetmek

Route configuration'ın tamamının tek dev dosyada olması her zaman gerekli değildir. Ancak route ownership ve naming merkezi bir model üzerinden anlaşılabilir olmalıdır. Feature-based route modules büyük application'da ölçeklenebilir. Shared path helper ve metadata duplication'ı azaltır. Permission ve breadcrumb bilgisi route definition'a yakın tutulabilir.

Route Bazlı Lazy Loading Kullanmak

Nadir kullanılan büyük feature'lar initial bundle'a dahil edilmek zorunda değildir. Lazy route boundary code split için doğal noktadır. Critical initial route gereksiz şekilde split edilmemelidir. Chunk loading error fallback'i bulunmalıdır. Prefetch gerçek navigation probability'sine göre uygulanmalıdır.

404 ve Error Boundary Tasarlamak

Unknown route ile runtime error aynı ekran olmak zorunda değildir. 404 kullanıcının adreslediği resource bulunmadığını anlatır. Error boundary beklenmeyen application failure için recovery sunar. API error kendi retry behavior'ına sahip olabilir. Hata türlerini ayırmak hem kullanıcı mesajını hem monitoring'i iyileştirir.

Direct Navigation'ı Her Zaman Test Etmek

Her production route link click olmadan açılabilmelidir. Browser address bar URL'si yeni tab'da açıldığında doğru server response gelmelidir. Auth ve data hydration sıfır memory state ile çalışmalıdır. CDN rewrite configuration test environment'a mümkün olduğunca benzer olmalıdır. Bu test yalnızca deployment sonrası yapılan manuel kontrol olmamalıdır.

Accessibility'yi Routing Tasarımının Bir Parçası Yapmak

Route transition focus strategy baştan belirlenmelidir. Title ve main heading current page'i açıklamalıdır. Links semantic anchor olarak kalmalıdır. Pending navigation assistive technology için gerektiğinde duyurulmalıdır. Accessibility testleri keyboard ve screen reader akışlarını kapsamalıdır.

Örnek Bir E-Ticaret SPA'sında Routing Akışı

E-ticaret SPA routing'i public catalog, search state, cart ve protected account route'larını aynı browser history içinde yönetir. Ana sayfa ve kategori route'ları public olabilir. Product detail dynamic segment kullanır. Search ve filter state query parameter üzerinden paylaşılabilir. Checkout ve user account authentication gerektirirken hard refresh ve browser back bütün bu ekranlarda beklenen state'i yeniden oluşturmalıdır.

Ana Sayfa

/ application'ın public entry route'u olabilir. Initial shell ve önemli content burada yüklenir. Category veya product link'leri semantic navigation sağlar. User login state header içinde hydrate edilebilir. Ana sayfaya back navigation scroll restoration behavior'ı ayrıca test edilebilir.

Kategori

/categories/shoes benzeri route category listing gösterebilir. Category slug route parameter görevini üstlenir. Filter ve sort query parameters ile tutulabilir. Route invalid category için not-found davranışı üretmelidir. Category data cache back navigation'ı hızlandırabilir.

Ürün Detayı

Product detail route stable ID veya slug kullanabilir. Route parameter loader tarafından product request'ine çevrilir. Product bulunamazsa page-level 404 gösterilir. Related product navigation yeni history entry oluşturabilir. Back kullanıcının eski list filter ve scroll state'ine dönmesini sağlamalıdır.

Arama ve Filtreleme

/search?q=router&page=2 gibi yapı shareable result state sağlar. Search input kullanıcı yazarken replace, submit olduğunda push kullanabilir. Filter değerleri canonical order ile serialize edilebilir. Unsupported query temizlenebilir. Sensitive search context URL'ye yazılmadan önce privacy açısından değerlendirilmelidir.

Sepet

/cart kullanıcı sepetini gösterir. Cart data server session veya persistent client storage üzerinde tutulabilir. URL yalnızca cart view location'ını temsil eder. Product quantity gibi bütün business state query içine yazılmamalıdır. Refresh cart state'ini güvenilir kaynaktan yeniden yüklemelidir.

Checkout

Checkout route authentication veya guest flow requirement'ına bağlı olabilir. Multi-step checkout URL child route veya controlled state ile modellenebilir. Payment secret bilgileri URL'de taşınmamalıdır. Browser back kullanıcıyı yanlışlıkla duplicate payment işlemine sokmamalıdır. Mutation idempotency ve backend validation routing'den bağımsız güvenlik katmanlarıdır.

Kullanıcı Hesabı

/account protected parent route olabilir. Orders, addresses ve profile nested child route olarak tasarlanabilir. Parent auth guard UX sağlar. Her API request backend permission kontrolünden geçer. Logout sonrası protected history entry'lere dönüldüğünde data yeniden gösterilmemelidir.

Protected Route

Order history yalnızca authenticated user için açılabilir. Client guard unauthenticated kullanıcıyı login route'una götürür. Return target güvenli şekilde saklanır. Backend order endpoint current user ownership kontrolü yapar. Login tamamlandıktan sonra route tekrar açılabilir.

404

Unknown product veya route not-found experience üretmelidir. Search bar veya category link recovery sağlar. Public crawling requirement'ında doğru status strategy uygulanır. Error monitoring invalid URL ile application exception'ı birbirinden ayırır. Kullanıcı dead end içinde bırakılmamalıdır.

Browser Back Senaryosu

Kullanıcı category'den product'a gider ve ardından back tuşuna basar. URL category route'una dönmelidir. Filter state query'den yeniden kurulmalıdır. Liste cache'den gelebilir ve scroll position restore edilebilir. Bu akış e-ticaret navigation kalitesi için kritik senaryolardan biridir.

Hard Refresh Senaryosu

Kullanıcı product detail URL'sini yeni sekmede açabilir. Server index document veya server-rendered page'i doğru şekilde sunmalıdır. Router parameter'ı initial location'dan okur. Product data sıfır memory state ile yüklenir. Bu ekran yalnızca category'den click edilerek gelindiğinde çalışıyorsa routing architecture eksiktir.

Sık Sorulan Sorular

SPA routing konusunda en sık karıştırılan noktalar History API, client-server route ayrımı ve browser navigation davranışları çevresinde toplanır. Framework router'ları birçok detayı gizlediği için temel mekanizma gözden kaçabilir. Buna rağmen direct URL, refresh, back ve forward gibi davranışlar browser seviyesinde devam eder. Routing öğrenirken URL'nin application state'i temsil ettiği düşüncesini merkezde tutmak konuyu kolaylaştırır. Aşağıdaki cevaplar bu rehberdeki ana routing prensiplerini kısa biçimde bir araya getirir.

SPA'da Routing Ne Demektir?

SPA routing URL ile application view arasındaki eşleştirmedir. Kullanıcı yeni route'a geçtiğinde client router URL'yi değerlendirir. Uygun component veya view render edilir. Çoğu navigation yeni HTML document yüklemeden gerçekleşebilir. Browser history yine navigation geçmişini korur.

SPA'da URL Değiştiği Halde Sayfa Neden Yenilenmez?

History API current document'i reload etmeden URL değiştirmeye izin verir. Router browser'ın normal document navigation davranışını internal link için engelleyebilir. JavaScript runtime aynı şekilde çalışmaya devam eder. Framework yeni route view'ını DOM'a uygular. Direct URL veya refresh ise yeni document request'i başlatır.

pushState Ne İşe Yarar?

pushState() session history'ye yeni entry ekler. İsteğe bağlı olarak current document için URL'yi değiştirir. Bu URL değişimi otomatik document reload oluşturmaz. Router ardından yeni location'a göre UI render eder. Kullanıcı back ile önceki entry'ye dönebilir.

pushState ile replaceState Arasındaki Fark Nedir?

Push yeni history entry oluşturur. Replace mevcut entry'yi değiştirir. Yeni anlamlı page navigation çoğu zaman push kullanabilir. Automatic redirect veya URL normalization replace için uygun olabilir. Seçim back button davranışını belirler.

popstate Ne Zaman Çalışır?

Popstate session history içinde başka entry aktif olduğunda router için önemli sinyaldir. Back ve forward bunun tipik örneğidir. Handler current URL'yi tekrar okuyabilir. UI yeni history location'a göre render edilir. PushState çağrısını yaptıktan sonra aynı anda popstate bekleyip rendering'i ona bırakmak doğru yaklaşım değildir.

BrowserRouter ile HashRouter Arasındaki Fark Nedir?

BrowserRouter benzeri yapı normal pathname'i History API ile kullanır. HashRouter route bilgisini URL fragment bölümünde taşır. Browser routing temiz URL sağlar fakat server fallback yapılandırması gerektirir. Hash route static hosting kısıtlarında daha kolay olabilir. Public ve SEO odaklı projelerde normal path yaklaşımı çoğu zaman daha doğal yapı sunar.

React Router Olmadan SPA Routing Yapılabilir mi?

Evet, Browser History API kullanılarak vanilla JavaScript ile router yazılabilir. Click event'leri yakalanır. URL pushState ile değiştirilir. Popstate dinlenerek back ve forward desteklenir. React Router production projede bu behavior'ın birçok ayrıntısını hazır şekilde yönetir.

Sayfayı Yenileyince Neden 404 Alıyorum?

Refresh yeni HTTP document request'i başlatır. Server client route pathname'i için gerçek file bulamayabilir. SPA fallback yapılandırılmamışsa 404 verir. Server application route'larını index.html veya uygun server-rendered response'a yönlendirmelidir. API ve asset route'ları bu fallback'ten ayrı tutulmalıdır.

Dynamic Route Nedir?

Dynamic route path'in bir bölümünü değişken kabul eden route'tur. Product veya user identifier bu segmentte taşınabilir. Router matched value'yu parameter olarak çıkarır. Component veya loader bu value üzerinden data alabilir. Parameter validity ayrıca application tarafından kontrol edilmelidir.

Nested Route Nedir?

Nested route parent ve child route hierarchy'si oluşturur. Parent ortak layout sağlayabilir. Child route outlet içinde kendi content'ini render eder. Dashboard ve settings bölümleri tipik kullanım alanıdır. Nesting gerçek navigation hierarchy'sinden daha derin yapılmamalıdır.

Protected Route Gerçek Bir Güvenlik Önlemi midir?

Tek başına değildir. Client route guard UI erişimini kontrol eder. Kullanıcı client JavaScript davranışını değiştirebilir veya API'ye doğrudan request gönderebilir. Backend her hassas işlemde authentication ve authorization kontrolü yapmalıdır. Protected route güvenlik sisteminin kullanıcı deneyimi katmanıdır.

SPA Routing SEO'yu Etkiler mi?

Evet, public content URL yapısı, crawlability, metadata ve status code davranışıyla doğrudan ilişkilidir. Her önemli content anlamlı URL'ye sahip olmalıdır. Client-rendered content crawler tarafından görülebilir olsa da rendering erişimi ve metadata doğru çalışmalıdır. SSR, SSG veya prerendering birçok public projede initial HTML erişimini güçlendirebilir. 404 ve canonical behavior ayrıca kontrol edilmelidir.

Query Parameter mı Route Parameter mı Kullanılmalı?

Resource identity veya hierarchy çoğunlukla route parameter için uygundur. Filter, sort, pagination ve search gibi view variation'ları query parameter ile daha doğal ifade edilebilir. Kesin bir evrensel kural yoktur. URL kullanıcıya domain modelini anlaşılır şekilde anlatmalıdır. Paylaşım ve canonical behavior kararın parçası olmalıdır.

Routing Öğrenmek İçin En İyi Programlama Dili Hangisidir?

Browser SPA routing mantığını öğrenmek için JavaScript doğal başlangıç noktasıdır. History API doğrudan browser JavaScript API'sidir. TypeScript kullanmak route parameter ve configuration type safety açısından ek değer sağlayabilir. Asıl öğrenilmesi gereken URL ve history modelidir. Framework syntax daha sonra kolayca eklenebilir.

Yeni Bir Yazılımcı Routing Konusunu Ne Zaman Öğrenmeli?

HTML link ve temel JavaScript bilgisi oturduktan sonra routing öğrenmek anlamlıdır. Önce URL parçaları ve normal browser navigation anlaşılmalıdır. Ardından History API ile basit router yazılabilir. Daha sonra React, Vue veya Angular router API'leri öğrenilebilir. Böylece developer yalnızca framework fonksiyonlarını ezberlemek yerine altında çalışan mekanizmayı anlayabilir.

Open Source Router Projelerine Katkı Sağlamak Ne Kazandırır?

Router source code'u route matching, history abstraction ve navigation lifecycle konusunda gerçek production örnekleri sunar. Issue çözmek edge case'leri görmeyi sağlar. Test suite browser behavior'larının nasıl doğrulandığını öğretir. Documentation contribution bile terminology ve API contract bilgisini geliştirir. Küçük contribution'lar büyük framework architecture'ını anlamak için iyi başlangıç olabilir.

Yazılım Topluluklarında Routing Mimarisi Nasıl Pratik Edilebilir?

Bir workshop'ta önce vanilla JavaScript router yazmak oldukça öğretici olabilir. Katılımcılar pushState, popstate ve server fallback behavior'ını birlikte deneyebilir. Sonra aynı mini application React, Vue veya Angular router ile yeniden kurulabilir. Code review sırasında URL design, accessibility ve protected route sınırları tartışılabilir. Diyarbakır'daki yazılım etkinlikleri ve topluluk çalışmaları için https://www.diyarbakiryazilim.com.tr adresinden Diyarbakır Yazılım Topluluğu çalışmalarına ulaşabilirsiniz.

Sonuç: SPA Routing Bir Kütüphaneden Çok Tarayıcı ve URL Yönetimi Problemidir

SPA routing'i yalnızca React Router, Vue Router veya Angular Router API listesi olarak öğrenmek konunun en önemli kısmını kaçırmaya neden olur. Temel problem URL'nin kullanıcı tarafından adreslenebilir bir application state haline getirilmesi ve bu state'in browser history ile uyumlu biçimde yönetilmesidir. Framework router'ları matching, navigation, data loading ve nested view gibi ihtiyaçlar için güçlü abstraction sağlar. Buna rağmen refresh sırasında server request yapılması, back tuşunun history içinde hareket etmesi ve public URL'lerin SEO ile accessibility sorumlulukları devam eder. Sağlam frontend architecture framework değişse bile bu web platformu prensiplerini korur.

URL Uygulamanın Navigasyon Sözleşmesidir

URL kullanıcının uygulamada nerede bulunduğunu ifade eder. İyi tasarlanmış URL paylaşılabilir ve bookmark edilebilir. Refresh sonrası navigation state'inin yeniden kurulmasına yardım eder. Browser history bu URL'ler arasında doğal hareket sağlar. Bu nedenle URL yalnızca router'ın internal implementation detayı değildir.

History API Routing'in Temelini Oluşturur

History API browser tabanlı clean URL routing'in ana yapı taşlarından biridir. PushState yeni navigation entry oluşturabilir. ReplaceState mevcut entry'yi güncelleyebilir. Popstate history traversal sonrası router'a current location değişikliğini işleme fırsatı verir. Bu mekanizmaları anlamak framework router behavior'ını çok daha anlaşılır hale getirir.

Framework Router'ları Bu Mekanizmayı Soyutlar

Framework router kullanıcıdan raw event ve history yönetiminin çoğunu saklar. Route matching, nested layouts ve parameter parsing hazır hale gelir. Modern router'lar data loading, navigation pending state ve error boundary gibi ek yetenekler de sunabilir. Bu abstraction geliştirici hızını artırır. Ancak sorun çıktığında browser seviyesindeki mekanizmayı bilmek debugging süresini ciddi biçimde azaltır.

Sağlam Routing Deep Link, Refresh ve Back/Forward Senaryolarında da Çalışmalıdır

Bir route yalnızca uygulama içindeki menüden tıklanınca çalışıyorsa tam anlamıyla güvenilir değildir. Aynı URL yeni sekmede direct olarak açılabilmelidir. Hard refresh view'ı yeniden oluşturabilmelidir. Browser back ve forward URL ile UI'ı tutarlı biçimde değiştirmelidir. SPA routing mimarinizi bu prensiplerle geliştirmek, frontend ekipleriyle routing, JavaScript ve açık kaynak çalışmaları yapmak için https://www.diyarbakiryazilim.com.tr adresindeki Diyarbakır Yazılım Topluluğu içerik ve çalışmalarını inceleyebilirsiniz.