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.