Saf JavaScript ile başladığım frontend projelerinde, büyüdükçe "bu prop'un tipi neydi" gibi sorularla çok zaman kaybettim. TypeScript'e geçtikten sonra bu tür hataların büyük kısmı derleme aşamasında yakalanmaya başladı.
any Kullanmaktan Kaçınmak
any tipini kullanmak, TypeScript'in tüm faydasını devre dışı bırakıyor. Tipini bilmediğim bir veri için unknown kullanıp, kullanmadan önce tip kontrolü yapmayı tercih ediyorum; bu, derleyicinin beni yanlış varsayımlara karşı uyarmasını sağlıyor.
API Yanıtları İçin Tip Tanımlamak
interface OrderResponse {
id: string;
customerName: string;
items: OrderItem[];
total: number;
}
async function fetchOrder(id: string): Promise<OrderResponse> {
const res = await fetch(`/api/orders/${id}`);
return res.json();
}
Bu tanımlar, API'nin döndürdüğü veriyle frontend'in beklediği veri arasında bir sözleşme oluşturuyor; API değiştiğinde derleyici hangi kullanım yerlerinin bozulduğunu hemen gösteriyor.
Discriminated Union ile Durum Yönetimi
Bir isteğin loading/success/error durumlarını ayrı boolean bayraklarla değil, birleşik (discriminated union) bir tip ile modellemek, geçersiz durum kombinasyonlarının (örneğin hem loading hem error true) oluşmasını derleme zamanında engelliyor.
Strict Mode'u Açık Tutmak
tsconfig.json'da strict: true ayarını kapatmak, kısa vadede kolaylık sağlasa da, TypeScript'in asıl gücünü (null kontrolü, implicit any yasağı) devre dışı bırakıyor. Yeni projelerde bunu baştan açık tutmayı önemsiyorum.
Sonuç
TypeScript, JavaScript'in üzerine bir tür bürokrasi eklemiyor; doğru kullanıldığında hataları çalışma zamanından derleme zamanına taşıyarak, gerçek zamandan tasarruf sağlıyor.