Yazılımın ilk 250 günü - Part 14

131. Gün

1. İlk önce Context’in ne olduğuna sil baştan tekrar baktım. Ağaç içerisinde bir prop’un kökten en uçtaki dala ulaşabilmesi için normalde gövdedeki her kısımdan ve budaklanmadan geçmesi gerekli. Fakat bu datanın(prop) hepsine uğrama zorunluluğu karmaşıklığı oldukça arttırabilir. Context burada bize provider’a erişen consumer component’lerin erişebildiği global bir veri (state) sağlar.
2. Component kısaca bir Javascript fonksiyonu gibi, prop ise input. State prop’a benzese de private ve component tarafından control ediliyor. State güncellendiğinde re-rendering gerçekleşir. Component’ler React’ın bize verdiği bir armağan gibi. Kodların tekrar kullanılabilirliğini sağlayan yapıtaşları. Bir button componenti yazdığımızı düşünelim. Her buton kullanılan sayfada tekrar tekrar button için kod yazıp tekrara düşmek yerine aynı component’i kullanabiliriz. Aynı component’in farklı varyasyonlarını da yaratabiliriz. Aynı button componentinin farklı varyasyonlarını kullanarak tutarlı bir tasarım elde ederiz (Her sayfada ilgisiz ve örtüşmeyen butonlar kirli ve tutarsız bir görünüm sağlayacaktır. Uygulamanın hafızalarda kalan kendine özgü tasarımı bu olmamalıdır).
3. Sonrasında tavsiyeniz ile tıpkı bir web sitesi projesinin mimarisini oluşturmak gibi, react projesinin de nasıl bir mimariye, klasör dizinine, design pattern’e sahip olması gerektiği üzerine okumalar yapıldı. Web projesi mimarisinde olduğu gibi burada da tek bir doğru veya yanlış olmadığı gibi herkesin best practice’i kendi yaklaşımıydı. Özellikle iki dizaynın sıkça bahsedildiği görüldü: Componentlerin atomik yapı (atom-molecule-organism-template-page) ile oluşturulduğu bir proje mimarisi vardı. Burada atomlar küçük gruplara bölünemeyen en küçük yapı taşı componentlerdi. Moleküller atomlardan oluşan ve tek bir şey yapan bir gruptu. Form alanı gibi düşünülebilir. Organizma ise moleküllerden oluşan ve app’in daha kompleks parçasını oluşturan bir yapıydı. Template ise adından da anlaşılacağı gibi bir sayfanın layout’ı, template’i idi (Örneklendirme: Nesnenin template’i class. Sayfa ise template’in instance’ı). Diğer sıkça karşılaşılan dizayn ise Container/Component konsepti idi. Mantığı anlaşıldığı kadarı ile componentleri elden geldiğince stateless yaparak onları “dump” olarak görmekti. Container ise hem bir controller hem de sayfanın kendisi olarak davranıyordu. Bu konunun çok fazla dezavantajı ile geçmişte karşılaşılmış ve şimdi de bunun için optimize çözümler getirilmiş (design pattern’lardan command pattern’i uygulamak, hook’ların yardımı ile geliştirme yapmak,, vs.) fakat farklı farklı uygulamaları olduğu için ve saat de geç olduğu için sonra değinmeyi düşünüyorum. Ama atomik dizaynın anlatıldığı referans kaynaklarda container/component konseptinin ölçeklenebilir olmadığı, ne iş yaptığının belli olmadığı (sayfa mı yoksa controller gibi hareket eden stateful bir component mı) gibi konulara değinilip bunu kullanmaya gerek yok denilmiş. Gri taraftan bakınca ikisinin de oldukça fazla kullananı var ve bizim işimize en çok hangisi yararsa ve gelecekte daha az soruna yol açacak hangisi ise ona göre bir dizayn oluşturmak faydalı olacaktır. Seçenekler ise sadece ikisi değil bambaşka bir yapıda olabilir.

Bu detaylı isimlendirmelere girmeyen ve React’ı oldukça güzel anlatan bir kaynak açıkçası daha çok dikkatimi çekti: React proje mimarisi.

SRP’nin react native’ e çevrilmiş hâli: “Bir component ya da bir hook; tek bir işi yapmalı, o işi çok iyi yapmalı ve yalnızca o işi yapmalı.”

Yine yukarıdaki linki referans alarak şu cümleyi direkt almaktayım: “Birbirleriyle direkt olarak haberleşemeyen fakat içerik olarak birbirleriyle bağımlı her bir modül için ayrı birer context yapısı kurmalısınız. Ek olarak; context, içinde tuttuğu herhangi bir state güncellemesinde bağlı olduğu her bir componenti günceller. Context’i dinleyen componentler zaten o context’e ihtiyaç duyuyor olmalı. Eğer çağırdığınız herhangi bir state’i gereksiz görüyorsanız; ya o state’tin context’e işi yok ya da context’i yanlış kurgulamışsınız demektir. ”

Redux ve context api kullanımı arasındaki farklar hakkındaki bir yazı benim konuyu daha iyi anlamamı sağladı.

API’den data alımı,context kullanımı, re-render konusuna yarın sabah tekrar bakmayı düşünüyorum. Hem redux’ı hem react’in yazımında bulunanlardan birinin yorumunu görünce, oop çalışırken Alan Key’in düşüncelerini okumak gibi bir hissiyat oluştu.

132. Gün

133. Gün

134. Gün

Günün benim anlam ve önemi Stackover’da ilk kez bir soruya cevap yazmam. Yine o birçok yerde sorulan ama doğru düzgün cevaplanmayan basit sorulardandı aslında (2015-16 civarı cevabı github'ta verilmiş gerçi, o da eklendi). Hiç hakim olmadığım ve yeni başladığım bir konuda yazmak elbette doğru olmayabilir fakat karşılaşılan sorunun sebebini biraz da olsa anladığımı düşündüğüm için yazmak istedim. Yanlışsa da silerim ya da güncellerim tabii ki utanılacak bir şey yok diye düşünüyorum.

135. Gün

136. Gün

@react-navigation/stack

@react-navigation/native-stack

137. Gün

138. Gün

139. Gün

Ayrıca kullanıcı token’I oluşturma konusunu front end tarafında yapmıştım fakat sonrasında sunucu tarafında tamamladım. Önce kullanıcının telefonundan elde edilen unique id yi aldım. Sonrasında da unique id nasıl oluşturulur araştırması yaparken karşılaştığım şu cevaptaki örneklerden birini kullandım. Algoritması nasıl işliyor merak etsem de yarın iş sonrası bakmayı düşünüyorum. Çünkü nasıl olur da unique bir id oluşturulabiliyor sonlu sayıda uzunluğu bulunan bir string ifade ile henüz anlamadım. Özetle kullanıcının telefonunda alınan unique id ve kendi oluşturduğum unique bir değeri birleştirerek kendimce bir token oluşturdum. Sonrasında kullanıcı sunucu ile iletişime geçtiğinde header'da bu token’I göndererek kendi varlığını ispatlayabilir. Kullanıcı uygulamayı silse dahi onun telefonundan gelen unique id bizde kalabileceği için, bilgileri tekrar kullanılabilir, hatırlanabilir.

Sonrasında hala ona mı bakıyorsun deme ihtimalinizi düşünsem de yine de call by value-reference konusuna çok az baktım. Bu sefer farklı bir şeyler karşılaştım. Ne pass-by-value, ne de pass-by-reference olduğunu öğrendim object konusunun. Açıkçası php, javascript ve birçok modern dil default olarak pass by value’yu kullansa da object konusunda call(pass)-by-sharing diye bir evaluation strategy siydi.

Anladığım kadarı ile nesneler ne klonlanıyor ne de kopyalanıyor. Nesneler, paylaşılıyor. Evet, paylaşılmasından söz edilmiş. Örnekle gidelim (ilk cevaptan alınmıştır):

function changeStuff(a, b, c)
{
  a = a * 10;
  b.item = "changed";
  c = {item: "changed"};
}

var num = 10;
var obj1 = {item: "unchanged"};
var obj2 = {item: "unchanged"};

changeStuff(num, obj1, obj2);

console.log(num);  //10
console.log(obj1.item);  //changed
console.log(obj2.item);  //unchanged

140. Gün