Photo by NeONBRAND on Unsplash

REACT ROUTING

React Router — 4 (Error Handling, 404 Pages)

React Router üzerinden analizlerimize devam ediyoruz. Bu yazıda olmayan sayfalar (404 Pages), path uyuşum problemleri, iç içe path tanımlamalarını nasıl gerçekleştirildiğini anlatacağız.

Bu blog postu okumadan önce aşağıdaki bu linkte yer alan serinin 3 yazısını okumanızı öneririm.

Kullanıcı adres barına yazıp enter tuşuna basınca bir takım yönlendirmeler yapılsada, aşağıdaki resimdeki adres çubuğu aslında kullanıcının kontrolündedir ve bu alana istediği metni yazabilir.

Address Bar

• Kullanıcı bu alana yanlış bilgiler girmiş olabilir.
• Yönlendirme yapan link eski bir versiyonda kalmış olabilir
• Veya link adresi yanlış kodlanmış olabilir

Bu durumda yönlendirme dediğimiz mekanizma ilgili adreslere ve ilgili yönlendirmeyi yapmaya çalışacaktır. Bu sırada uygulama bizim domain alanımıza gelinceye kadar sorumluluk biz geliştiricilere ait değildir. WebApp öncesi kısmın nasıl çalıştığını anlamak için aşağıdaki yazıları okuyabilirsiniz.

• Chrome Navigasyon’u Nasıl Gerçekleştiriyor ?
• DNS Nedir ?, Nasıl Çalışır ?

1. 404 Sayfalar için Routing ’de Nasıl Ele Alınır

404 yani ilgili sayfanın bulunmadığı, Routing açısından düşünülmediği sayfalardır. Geliştiriciler sayfaları düşünürken exceptional durumlar içinde ele alması gerekir.

In computer network communications, the HTTP 404, 404 not found, 404, 404 error, page not found or file not found error message is a hypertext transfer protocol standard response code, to indicate that the browser was able to communicate with a given server, but the server could not find what was requested. (Wikipedia)

Mevcut durumda Routing ile tanımlamarımızın dışında bir Path gelirse bunu nasıl render edeceğiz. Bunun için React Router 4 Switch kullanabilirsiniz. Switch sırasına göre match eden ilk bileşeni ekrana render edecektir. Burada ilk root path(/) dokunması durumunda Home aksi taktirde path /landing ise LandingPage veya bunun da olmaması durumunda default olarak 404Page render edecektir.

React Router 4
<Switch> 
 <Route path="/" exact component={HomePage}/>
 <Route path="/landing" component={LandingPage}/>
 <Route component={404Page} />
</Switch>

Bu durum React Router 5 de * yani tüm pathlar için geçerlidir ibaresi kullanılarak yapılabilecek hale getirilmiştir.

React Router 5
<Switch> 
 <Route path="/" exact component={HomePage}/>
 <Route path="/landing" component={LandingPage}/>
 <Route path="*" component={404Page} />
</Switch>

Son olarak React Router6 da <Routes> içerisinde tanımlamara geçilmiş artık bir sıraya göre değilde Routes bunu akıllıca en iyi hangi sayfaya yönlendirebileceği üzerine kurulu bir routing ile gerçekleştirilir.

React Router 6
<Routes> 
 <Route path="*" component={404Page} />
 <Route path="/" exact component={HomePage}/>
 <Route path="/landing" component={LandingPage}/>
</Routes>

Whenever the location changes, <Routes> looks through all its children <Route> elements to find the best match and renders that branch of the UI. <Route> elements may be nested to indicate nested UI, which also correspond to nested URL paths. Parent routes render their child routes by rendering an <Outlet>. (https://reactrouter.com/docs/en/v6/api#routes-and-route)

2. URL/Search/Hash Param Hataları Nasıl Ele Alınır ?

Yukardaki bahsettiğimiz konu sayfanın olmaması durumuydu. Peki biz sayfaya gittiğimizde aşağıdaki parametrelerin doğru türde veri geçirildiğini veya ilgili verinin veritabanınında olup olmadığını nasıl anlayacağız, bunlar ile ilgili hatalar olduğunda nasıl davranacağız.

/users/onur?filterStart=”2021”&filterEnd=2022#lineNo:10000

Bu kısım Routing çok ele alınan bir konu olmasada bu alanların doğru şekilde doldurulması en önemli önceliğimiz olmalıdır.

A. Parametreleri Doğru Şekilde Tanımlama

URL Params kısmını örneğin generatePath ile doldurabilirsiniz.

https://v5.reactrouter.com/web/api/generatePath

Search Params kısmını aşağıdaki APIleri kullanarak doldurabilirsiniz.

• Web API’deki URL Search Params API
• Query Strings

Hash Params kısmını ise window.location.hash üzerinden tanımlayabilirsiniz.

B. Türlerin Doğru Olmadığı Durumlar İçin Validation

URL, Search veya Hash Params String, Number, Boolean vb türlerinin en başından hatalı olduğunu düşünüyorsanız. Bunların validation(doğrulama) işlemlerini Client Side yapıp hiç backend gitmeden durum için bir uyarı sayfa içeriği oluşturulabilir.

Örneğin aşağıdaki örnekte username string , tarih aralığının number , lineNo yine number olmasını bekliyoruz .

/users/onur?filterStart=”2021”&filterEnd=2022#lineNo:10000

Bu alanlar için türler doğru değil ise sayfanızda aranan kriterlere uygun veri bulunamamıştır diyebilirsiniz.

C. Türlerin Doğru Ama İlgili Verinini Veritabanında/Sunucuda Olmadığı Durumlar İçin

Bu durum ancak ilgili sorguların sunucuda yapıldıktan sonra anlayabileceğimiz bir durumdur. B durumunda olduğu gibi aranan kriterlere uygun veri bulunamamıştır diyebilirsiniz.

3. Path Match Belirsizlik Durumlarının Ele Alınması ?

Aşağıdaki pathlar alt alta dizdiğimizde

"/" -> Home Page Path
"/:userId" -> Profile Page Path
"/about" -> About Page Path
"/dashboard" -> Dashboard Page Path

/onur dediğimde yukarıdaki ilk 2 path dokunacaktır. Bu durumda bunların her birisinin ayrı sayfa olduğunu düşünüyorsam başlarına Switch eklemeliyim.

<Switch>
   .....
</Switch>

Bu durumda yine ilk path “/” -> Home Page Path yine uyum sağlıyor. Ve 2nci path yönlenmiyor. Bu durumda path exact tanımlıyorum. Yani path birebir tutmasını istiyoruz exact path. Exact path nested yapıların kullanmasını engelleyende bir durumdur. Biz burada artık sadece / gelirse render edilmesini istiyoruz.

Bu istediğimiz durumu oluşturdu artık /onur path var ise bizi exact keyword dolayı ilk Home sayfası ile değilde Profile Sayfası ile eşleştirdi.

"/:userId" -> Profile Page Path

Peki /about yazdık bizi About sayfası yerine Profile eşleştiği için Profile sayfasına yönlendirecek bu durumda bizim Statik sayfa tanımlamalarını daha yukarı çekerek önceliğini arttırmamız gerekiyor.

"/" -> Home Page Path
"/about" -> About Page Path
"/dashboard" -> Dashboard Page Path
"/:userId" -> Profile Page 

4. İç İçe Sayfalarda URL Tanımlama Yöntemleri Bunların Avantaj ve Dezavantajları

Bazı durumlarda farklı sayfalar olsa bile alandan kaynaklı olarak iç içe sayfalar tanımlamanız gerekir. Bu durumda 2 yöntem uygulayabilirsiniz.

• 1nci Yöntem Domain Modelinizdeki Hiyerarşik yapıyı URL Path yansıtma
• 2nci Yöntemde Domain Modelinde Hiyerarşik yapıyı tam anlmayıyla URL YansıtMAma
• 3ncü Yöntemde Domain Modelindeki Hiyerarşik yapıyı hiç yansıtMama

4.A Hiyerarşik Yapıyı URL Yansıtma

Aşağıdaki uygulamada Functions → Invocations → Invocation sayfalarının iç içe tutarken aynı path ile başlamasını sağlarsanız. hepside functions/ ile başlar.

İç İçe Path Tanımlaması

Bunun getirdiği bir takım avantajlar varken bir takım dezavantajlarda oluyor.

Avantaj: Aşağıda görüldüğü gibi SideBar (Fx) seçili olmasını anlamak için sadece URL içerisinde functions başlayan bir path yeterli olduğunu görebilirsiniz.

Function Listesi
functions/4  -> 4 queryId
functions/quriRuntime%3Dnode -> runtime=node (Query)
Invocation Listesi
functions/aws%3Alambda%3Aeu-west-1%3A403892453228%3Atodo-app-todo-worker/invocations/default/1 =>Bir fonksiyona
Invocation 
functions/aws%3Alambda%3Aeu-west-1%3A403892453228%3Atodo-app-todo-worker/5f1cad5b-cd8a-4ca2-93b0-28821462bb7b/trace-chart

Avantaj 2 ise Invocation nesnesi Function ile ilgili bilgileri kendi üst path tanımlanmış olan path alarak hiç Store gitmeden veya Backend bu TransactionID bilgisinin diğer bilgilerini çekmeden işlerini görebilir.

Invocation 
functions/aws%3Alambda%3Aeu-west-1%3A403892453228%3Atodo-app-todo-worker/5f1cad5b-cd8a-4ca2-93b0-28821462bb7b/trace-chart

Dezavantaj ise Path çok uzun olması ve uygulamanın ilerleyen süreçlerinde path taşınan bilginin tek başına yeterli olmaması ve her durumda Backend sorgu yapma gereksinimin eninde sonunda oluşuyor olması

Dezavantaj 2 ise domain yapısını doğru oluşturamamış iseniz. Örneğin yapı içerisine ekstra yeni bir structure gelirse tüm path tanımınız bozulmuş olur. Hele bir de bunları Alert, Report veya Email gibi yerlerde persist ediyorsanız öneceki pathlerin kullanılmaz duruma gelmesine bile neden olabilirsiniz.

functions → (…. New Structures)→ invications → invocation 

4.B Hiyerarşik Yapıyı Tam Anlamıyla URL Yansıtmama

Bu uygulamada Repositories → Repository → TestRuns → TestRun → Test Suite → Test hiyerarşik yapısı bulunuyor.

Buradaki tüm hireyarşik yapıyı URL taşımak yerine paylaşımlarda gözükmesi iyi olacak kullanıcıya anlam ifade eden şeyleri URL taşıdık.

/repositories (Repositories)
/repositories/git/Netflix/zuul/test-runs (TestRuns)
/testrun/ba0505b6a318099b52294a69 (Spesific TestRun)
/ba0505b6a318099b52294a69/testsuite/com.netflix.zuul.netty.server.IoUringTest (TestSuite)
testrun/ba0505b6a318099b52294a69/test/3857a659-5773-46e9-8013-de9a81a94873

Avantajları Tüm pathleri hiyeraşik tanımlasaydık aşağıdaki gibi çok uzun bir path oluşacaktı, path gereksinimleri artacak ileride repo ile testRun arasına workflow eklemek istediğimizde tüm path yapımımızı baştan revize etmek gerekecekti.

repositiories/git/Netflix/zuul/test-runs/ba0505b6a318099b52294a69/testsuite/com.netflix.zuul.netty.server.IoUringTest/test/3857a659-5773-46e9-8013-de9a81a94873

Dezavantajı ise bazı kısımlarda BreadCrumb, Menu, Sidebar kısmında kullanıcının hangi noktada olduğunu anlayabilip bu Parçaların koyu (Segmentlerin bold) olarak gösterilebilmesi için ekstra kod yazımını gerektirir.

Not:

Bu arada bu örnekte karşıma çıktığı için buraya koymak istedim. AutoFocus hash ile sayfanın belli noktasına odaklanma sağlayabilirsiniz. Tabi bunu algılayıp ilgil odaklanmayı sağlayacak kodu yazmanız gerekiyor. Kalıcı olmayan bir seferlik işler için #(hash) parametrelerini kullanabilirsiniz.

ba0505b6a318099b52294a69/testsuite/com.netflix.zuul.netty.server.ClientRequestReceiverTest#auto-focus

4.C Domain Modelindeki Hiyerarşik yapıyı hiç yansıtMama

Bu yöntemi beğenmiyorum çünkü belli bir seviyede hiyerarşik yapıyı URL görebilmek kullanıcıya büyük kolaylıklar sağlayarak bazen Adres Çubuğu üzerinden URL kullanmasını sağlar. Bu yöntemin çok fazla kullanıcı dostu olduğu düşünmüyorum. Aynı zamanda SEO açısından da problemler yaratacağını düşünüyorum

repositiories/git/Netflix/zuul/ -> Repositories Path
testruns/ba0505b6a318099b52294a69 -> TestRuns Path
testsuite/com.netflix.zuul.netty.server.IoUringTest -> TestSuite
test/3857a659-5773-46e9-8013-de9a81a94873 /Test Path

Görüldüğü gibi yukarıda URL üzerinden hiyerarşik yapıyı tümden kaybettik. Veriyi URL üzerinden taşımasak bile bu seviyede hirerarşik yapıyı kaybetmeyi doğru bulmuyorum.

Not: Yukarıdaki A,B,C durumlarını nasıl kullanacağınız ve nasıl bir URL yapısı oluşturacağınız size kalmış, mevcut duruma göre değerlendirip karar verin 😄

Referanslar

• URL Nedir ?
• URL API Nedir ?
• Her Ortamda Çalışan Web Uygulamaları Geliştirme (URL Kullanımı)
• Browser API Nedir?
• React da Sayfalar Arası Navigasyon
• Load Lazy When Routing
• Dynamic Page Routing

Okumaya Devam Et 😃

Bu yazının devamı veya yazı grubundaki diğer yazılara (React Router) erişmek için bu linke tıklayabilirsiniz.