Kısım II · İnşaat · Bölüm 30

TypeScript: Tiplerin güvencesi

JavaScript'in üstüne yazılan denetlenebilir sözleşmeler (TypeScript)

1. Kat 10Bizim uygulamamızSoru, puan, seri ve can verilerinin beklenen şekilleri.
2. Kat 9Web ve tarayıcı: HTML, CSS, JavaScriptWeb'de çalışacak çıktı JavaScript'tir; telefon tarafındaki karşılığı Bölüm 32'de.
3. Kat 6–8Açılış, işletim sistemi ve ağDosyaları ve araç süreçlerini taşıyan, önceki bölümlerde kurduğumuz altyapı.
4. Kat 5Programlama dilleri ve derleyiciTypeScript, JavaScript kaynak koduna çalışmadan önce denetlenen bir tip katmanı ekler.
5. Kat 0–4Elektrikten işlemciye ve makine dilineTypeScript yeni donanım değildir; çalışan JavaScript yine bu temelin üstündedir.

Bu bölümün sonunda : number, type Soru, interface Kullanici, number | null ve Array<Soru> gördüğünde ne okuduğunu söyleyebileceksin. Daha önemlisi, “tip denetiminden geçti” sözünün neyi güvence altına almadığını bileceksin. Amacımız bütün TypeScript sözdizimini ezberlemek değil; agent'ın yazdığı bir sözleşmeyi okuyup “neyi bekliyor, nerede denetleniyor, nerede yalnızca varsayılıyor?” sorularını sorabilmek.

30.1 Neden: hatayı programı çalıştırmadan yakalamak; tip bir sözleşmedir

Bölüm 25.1'de sayı 10 ile karakter dizisi "10"'un farklı değerler olduğunu gördün. Küçük bir JavaScript örneğinde bu farkı unutalım:

function puanEkle(puan, kazanilan) {
  return puan + kazanilan;
}
console.log(puanEkle(70, "10"));

İlk satır iki parametre alan fonksiyonu tanımlar; ikinci satır + işleminin sonucunu döndürür; son satır fonksiyonu sayı ve metinle çağırıp sonucu yazar. Sonuç sayı 80 değil, karakter dizisi "7010"'dur. Bu JavaScript açısından geçerli bir işlemdir: metin birleştirilmiştir. Uygulamanın puan kuralı açısından yanlıştır. TypeScript JavaScript'in üstüne, bu tür uyuşmazlıkları kaynak kodda ifade edip denetleyebildiğin bir tip sistemi (type system) koyar; davranışın kendisini başka bir toplama kuralıyla değiştirmez.²⁵

function puanEkle(puan: number, kazanilan: number): number {
  return puan + kazanilan;
}
puanEkle(70, "10"); // Bilerek hatalı çağrı

Burada puan: number ilk parametrenin sayı olmasını ister; kazanilan: number ikincisine aynı koşulu koyar; parantezden sonraki : number dönüş değerinin de sayı olacağını bildirir. Bir adın ardından tipi açıkça yazmaya tip belirtimi (type annotation) diyeceğiz. Son satırdaki metin, ikinci parametrenin sözleşmesine uymaz. Derleyici bunu fonksiyonu çalıştırmadan bildirir. “Metin geldi, ben onu sayıya çevireyim” demez; “burada sayı bekleniyordu” der.³

Buna statik tip denetimi (static type-checking) denir: “statik”, programı bu denetim için çalıştırmadan incelemek demektir. Denetleyici hangi fonksiyona hangi değerin verildiğini, nesnede beklenen özelliğin bulunup bulunmadığını ve bir işlemin eldeki tip için anlamlı olup olmadığını kaynak üzerinden değerlendirir. Editördeki tamamlamalar da aynı bilgiden yararlanır: soru. yazınca bilinen özellikleri önermek, yalnızca harf tahmin etmek değildir.¹⁵

Sözleşme benzetmesinin yararı ve sınırı

Hukuktaki bir sözleşme gibi düşünmek şu noktada işe yarar: taraflardan biri “sayı ver”, diğeri “sayı döndür” sözünü açıkça yazar. Ama benzetmeyi burada durdur. TypeScript dışarıdan gelecek her gerçek olayı önceden görmez; kendisine verilen tip bilgileri ve kodun yapısı üzerinden çalışır. Bir tip belirtimi, kullanıcı cihazına yerleştirilmiş sürekli bir zabıta değildir. 30.3'te bu belirtimlerin çıktıda silindiğini göreceğiz.⁵

30.2 Temel tipler, arayüz, tip takma adı, birleşim tipi

Bildik değerlerin üstüne ad yazmak

JavaScript değerlerini baştan anlatmayacağız; 25.1'deki değerlere TypeScript'in hangi adlarla baktığını göstereceğiz. Sık kullanılan üç ilkel tip string, number ve boolean'dır. Küçük harfle yazılırlar. String ile string aynı yazım değildir; burada büyük harfli nesne sarmalayıcılarını kullanmıyoruz. number için C'deki gibi ayrı int ve float yazmayız.³

Tablodaki string[], string'in arkasına iki köşeli parantez koyar: “bu tipten elemanlar taşıyan dizi.” Dizi hakkında ne bildiğimizi yazar, belleğe yeni bir dizi yerleştirmez. null ve undefined'ın ayrı ele alınması, birazdan kullanacağımız sıkı denetim ayarına bağlıdır.³

const ad: string = "Kerem";
let puan = 70;
const tamamlandi: boolean = false;
const sikler: string[] = ["İcap", "Kabul"];
puan = 80;

İlk satır adın metin olduğunu açıkça söyler. İkinci satırda : number yazmadık; başlangıç değerinden tip çıkarımı (type inference) yapılır ve puan sayı olarak izlenir. Üçüncü satır doğru/yanlış bilgisini, dördüncü satır metin dizisini tanımlar. Son satır başka bir sayı atar; geçerlidir. Onun yerine puan = "seksen" yazmak tip uyuşmazlığı olur. Her satıra tip eklemek zorunda değilsin; açık belirtim özellikle modüllerin ve fonksiyonların sınırlarını anlaşılır kılar.²³

Nesnenin sözleşmesi: arayüz

Bir kullanıcı adı yalnızca metin olabilir; fakat kullanıcı kaydı birkaç özelliği bir arada taşır. Arayüz (interface) bildirimi, böyle bir nesnenin beklenen şeklini adlandırır. Bölüm 1.4'teki genel arayüz fikrinin dildeki somut biçimlerinden biridir; kullanıcı arayüzü, yani ekrandaki düğmeler anlamına gelmez.²³

interface Kullanici {
  id: number;
  ad: string;
  puan: number;
  takmaAd?: string;
}
const kerem: Kullanici = { id: 1, ad: "Kerem", puan: 70 };

interface Kullanici bir tip tanımlar; kullanıcı nesnesi üretmez. İçerideki ilk üç özellik zorunludur. takmaAd? ise isteğe bağlı özellik (optional property): kayıt bu özelliği taşımayabilir. Son satırda gerçek bir JavaScript nesnesi oluşturulur ve şekli Kullanici ile karşılaştırılır. puan'ı çıkarmak ya da ona "70" vermek hata oluşturur. İsteğe bağlı özelliği okurken yok olma ihtimalini ele almak gerekir; ?, “yoksa otomatik metin üret” talimatı değildir.³

TypeScript burada öncelikle nesnenin adına değil yapısına bakar; buna yapısal tipleme (structural typing) denir. Bir fonksiyon Kullanici bekliyorsa, gereken özellikleri uygun tiplerle taşıyan bir değişken ona verilebilir; o nesnenin oluşturulurken mutlaka Kullanici etiketiyle bildirilmiş olması gerekmez. Bu “her ek özellik her bağlamda serbest” demek de değildir: doğrudan verilen nesne yazımlarında fazladan özellik denetimleri bulunur. Başlangıç için alacağın fikir şu: arayüz bir sınıfın nüfus kâğıdından çok, gerekli özelliklerin listesidir.²³

Tip takma adı: karmaşık tarife kısa ad

Tip takma adı (type alias), bir tipe type ile ad vermektir. Nesne şekillerini de adlandırabilir; yalnızca onlarla sınırlı değildir. Aynı soru tarifini farklı fonksiyonların içine tekrar tekrar yazmak yerine bir kez adlandırırız:³

type Soru = {
  id: number;
  metin: string;
  sikler: string[];
  dogru: number;
};
type CevapBildir = (kazanilan: number) => void;

Soru'nun ilk satırı sayısal kimlik, ikincisi soru metni, üçüncüsü metinlerden oluşan şık dizisi, dördüncüsü doğru şıkkın indeksidir. dogru: number indeksin dizinin sınırları içinde olduğunu tek başına kanıtlamaz; bunun ayrı bir kural olduğunu unutma. Son satır bir fonksiyon tipini adlandırır: sayı alan, çağıranın kullanacağı bir dönüş değeri beklenmeyen fonksiyon. Buradaki void bu dönüş beklentisini anlatır. => bu konumda fonksiyonun gövdesi değil, girdi ile dönüş tipi arasındaki işarettir. Bir sonraki bölümde onCevap: (kazanilan: number) => void gördüğünde, “buraya çağrılabilir bir fonksiyon verilecek” diye okuyacaksın.²³

interface ile type nesne şekli yazarken çoğu zaman benzer işi yapar; biri iyi, diğeri kötü değildir. Önemli ayrım: arayüz bildirimleri uygun koşullarda aynı ad altında genişletilip birleştirilebilir; tip takma adı aynı adla yeniden açılıp böyle genişletilmez. Birleşim tiplerine ad vermek için ise type kullanacağız. Ayrıca type Puan = number yeni, diğer sayılardan kesin ayrılan bir puan tipi üretmez; yalnızca number'a başka ad verir. Takma adın adı tek başına negatif sayıları ya da yanlış anlamdaki sayıları yasaklamaz.³

Birleşim tipi: seçeneklerden biri

Birleşim tipi (union type), bir değerin belirtilen tiplerden biri olabileceğini söyler. Aradaki | işaretini “veya” diye oku. number | null, “sayı veya bilerek boş bırakılmış değer”; string | number, “metin veya sayı” demektir. İkincisi bir metni sayıya dönüştürmez, iki olasılığı da sözleşmeye kabul eder. Olasılıklar daraltılmadan yalnızca hepsi için geçerli işlemler yapılabilir.³

function secimiYaz(secili: number | null): string {
  if (secili === null) return "Henüz şık seçilmedi";
  return secili.toFixed(0);
}

İlk satır boş seçim ihtimalini açıkça taşır. İkinci satır bu ihtimali denetler ve boşsa fonksiyondan çıkar. Üçüncü satıra ulaşılmışsa değer artık sayı olabilir, null olamaz; bu nedenle sayıların metotlarından toFixed kullanılabilir. TypeScript'in kodun yollarını izleyerek olasılıkları azaltmasına tip daraltma (narrowing) denir. Burada kontrolü gerçekten yapan şey yine JavaScript'in if'idir; TypeScript bu kontrolden bilgi çıkarır.⁴

Benzer biçimde string | number olan bir değerde typeof deger === "string" kontrolü, o dalda metin işlemlerine izin verir. typeof çalışma sırasında temel tip bilgisi veren bir JavaScript işlecidir; yeni bir TypeScript denetim motoru değildir. Dikkat: typeof null sonucu "object" olduğu için yalnızca “nesne mi?” sorusuyla null olasılığı elenmez. Boş seçimi sınarken if (secili) de yanlış sezgi verebilir: geçerli ilk indeks 0 koşulda yanlış sayılır. secili === null tam olarak aradığın yokluğu sorar.⁴

Birleşimin üyeleri belirli değerler de olabilir. type CevapDurumu = "bekliyor" | "dogru" | "yanlis"; yalnızca bu üç metne izin verir. Bunlar sabit değer tipleri (literal types) ile yazılmıştır: genel string yerine tek tek izinli değerler. Böylece "dogur" gibi bir yazım yanlışı sözleşmeye uymaz. Herhangi bir metin kabul etmekten daha dar bir tarif yazmış olduk.³

30.3 Tip denetimi ve derleme: tsc; tiplerin çalışma anında silinmesi

Önce denetlemek, sonra çalıştırmak

TypeScript paketinin komut satırı aracı TypeScript derleyicisi (TypeScript compiler, tsc) adını taşır. Bölüm 9.1'de derleyici C'den makine koduna giden yolun parçasıydı; burada tsc tip denetleyebilir ve JavaScript çıktısı üretebilir. “Derleyici” adı her zaman doğrudan işlemciye giden dosya demek değildir. Üretilen JavaScript'i çalıştırmak daha sonra JavaScript çalışma ortamının işidir.⁵

Aşağıdaki küçük deney, Node.js ve npm hazır olan ayrı bir deneme klasöründe yapılabilir. Prototipin üstüne kurulum yapman gerekmiyor. İlk komut TypeScript'i geliştirme bağımlılığı olarak kurar; ikincideki npx kurulan paketin komutunu çağırır. Paket ve geliştirme bağımlılığı kavramlarını 29.1'de kurduk.⁵

npm install --save-dev typescript
npx tsc --strict --noEmit demo.ts

İkinci komut demo.ts'yi denetler. --strict sıkı tip denetimi seçenekleri grubunu açar; özellikle örtük any sorunları ve olası null/undefined erişimleri daha görünür olur. --noEmit çıktı dosyası yazmayı kapatır, denetimi kapatmaz. Hata bulunmadığında komutun sessizce bitmesi normaldir. Bir önceki alt bölümdeki yokluk örneklerini bu sıkı ayarla okuyoruz.⁵⁸

demo.ts'ye şu bağımsız örneği yazalım:

function puanEkle(puan: number, kazanilan: number): number {
  return puan + kazanilan;
}
console.log(puanEkle(70, 10));

npx tsc --strict --target ES2020 --outDir cikti demo.ts
node cikti/demo.js

İlk komut tip denetler ve çıktıyı cikti klasörüne yazar; --target ES2020, üretilecek JavaScript'in dil hedefini belirtir. İkinci komut o JavaScript'i Node ile çalıştırır. Yazarın bu örnekle aldığı sonuç 80'dir; aşağıdaki, üretilen dosyanın içeriğidir. Sayısal beklenti ayrıca Python ile hesaplandı.⁵

"use strict";
function puanEkle(puan, kazanilan) {
    return puan + kazanilan;
}
console.log(puanEkle(70, 10));

Tiplerin silinmesi ne demek?

Parametrelerdeki ve dönüş değerindeki : number çıktıdan kayboldu. Buna tiplerin silinmesi (type erasure) denir. Tip belirtimleri, interface ve type gibi yalnızca tip anlatan bildirimler çalışma kodu değildir; JavaScript çıktısında bulunmazlar. Zaman sırası önemlidir: tipler derleme sırasında silinir; program çalışırken bu tip belirtimleri artık yoktur. JavaScript'in sayı, metin ve nesne gibi kendi çalışma zamanı değerleri ise elbette vardır. Silinen şey verinin kendisi ya da JavaScript'in bütün tip davranışları değildir.³⁵

“TypeScript'te yazdığım her şey silinir” sonucu da yanlış olur. if, toplama, fonksiyon çağrısı gibi gerçek davranışlar kalır; bazı TypeScript özellikleri de JavaScript kodu üretir. Örneğin enum yalnızca tip düzeyinde bir bildirim değildir; bu bölümde onu kullanmıyoruz. Silinme kuralını özellikle tip belirtimleri ve tip bildirimleri için aklında tut. Tarayıcıya .ts dosyasını düz bir JavaScript betiği gibi verip içindeki : number'ı anlamasını bekleme; araç zincirinin dönüştürme işi bunun içindir.³⁵

tsc ilk iki işi bir arada yapabilir; --noEmit ile yalnızca ilkini yapmasını isteyebilirsin. Başka bir dönüştürücü tipleri kaldırırken tip denetimini başka adıma bırakabilir. Bu yüzden “ekran açıldı” ile “tip denetiminden geçti” aynı haber değildir. 29.2'deki derleme betiğinin önce tsc çağırması bu ayrımı görünür kılar.⁵⁸

Bir ayrıntı daha: tsc'nin tip hatası bildirmesi, her ayarda JavaScript çıktısını engellediği anlamına gelmez. Hata varken yeni çıktı üretmesini istemiyorsan --noEmitOnError kullanılır. Bu, --noEmit'ten farklıdır: biri hatalı derlemede çıktı yazmayı, diğeri hata olsa da olmasa da bütün çıktı yazmayı kapatır. “Dosya üretildi, demek ki tipler doğru” diye karar verme; komutun başarıyla bitip bitmediğine bak.⁵

Dışarıdan gelen veri: belirtmek doğrulamak değildir

Bir JSON metnini JSON.parse ile ayrıştırmak, metnin JSON kurallarına uyup uymadığını denetler ve bir JavaScript değeri üretir. “Bu değer benim uygulamamın puan kaydı mı?” farklı bir sorudur. Tip iddiası (type assertion) olan as, derleyiciye elinde ek bilgi olduğunu söylemektir; çalışma sırasında veriyi incelemez ya da dönüştürmez.³¹⁰

type PuanKaydi = { puan: number };
const kayit = JSON.parse('{"puan":"70"}') as PuanKaydi;
console.log(kayit.puan + 10);

İlk satır beklenen şekli tanımlar. İkincisi metni ayrıştırır ama as PuanKaydi ile o şekli iddia eder. Üçüncü satır denetimden geçebilmesine rağmen çalışınca "7010" yazar: kaydın içindeki değer hâlâ metindir. Tip iddiası sayıya çevirme değildir. Benzer biçimde bir değerin sonuna konan !, null/undefined ihtimalini denetlemeden yok saydıran bir tip iddiasıdır; kayıp öğeyi bulmaz. Agent uyarıyı as veya ! ekleyerek susturduysa hangi gerçek bilgiye dayandığını sor.³

Burada iki özel tip ayrımını bilmek yararlı. any, ilgili değer üzerinde tip denetiminin önemli kısmını devreden çıkarır; bilinmeyen özelliklere erişmene izin verir. unknown ise “henüz tipini bilmiyorum” der ve kullanmadan önce daraltmanı ister. Dış veriyi unknown olarak karşılayıp gerçekten kontrol etmek, beklenen şekli yalnızca ilan etmekten farklıdır.²³⁴

function puaniOku(veri: unknown): number {
  if (typeof veri !== "object" || veri === null) {
    throw new Error("Puan kaydı bekleniyordu");
  }
  if (!("puan" in veri) || typeof veri.puan !== "number") {
    throw new Error("Puan sayı olmalı");
  }
  return veri.puan;
}

İlk satır, henüz bilinmeyen bir girdi alır. İlk koşul nesne olmayanı ve null'ı reddeder. İkinci koşul “puan özelliği var mı, değeri sayı mı?” diye sorar; || kısa devre yaptığı için özellik yoksa sağdaki erişim değerlendirilmez. throw hata fırlatır ve o yürütmeyi keser. Son satıra gelindiğinde özellik sayı olarak daraltılmıştır. Kontroller JavaScript çıktısında kalır: bu kez gerçek veri üzerinde doğrulama (validation) yapıyoruz. Bu örnek yalnızca nesne/özellik/sayı biçimini doğrular; negatif olmayan tam puan gibi ek ürün kurallarını doğruladığı iddiasında değiliz.⁴

30.4 Genel tipler: aynı ilişkiyi farklı tiplerle korumak

Şimdiye kadar belirli tipler yazdık: sayı, soru, kullanıcı. Fakat aynı davranış farklı tiplerle çalışabilir. Bir dizinin ilk elemanını okumak hem soru dizisinde hem metin dizisinde aynı iştir. İki ayrı fonksiyon yazmak tekrardır; giriş ve çıkışı any yapmak ise “metin dizisi verdim, ne aldım?” bilgisini kaybettirir. Genel tipler (generics), bu ilişkinin tipini bir parametreyle ifade etmemizi sağlar.⁶

function ilk<T>(liste: T[]): T | undefined {
  return liste[0];
}
const ilkMetin = ilk(["İcap", "Kabul"]);
const ilkPuan = ilk<number>([70, 80]);

<T> bir tip parametresi (type parameter) tanımlar. T özel bir hazır tip adı değildir; yer tutucunun adı olarak Eleman da yazabilirdik. liste: T[] “bu çağrıda seçilen tipten elemanların dizisi”, T | undefined “o eleman tipinden değer veya boş dizide bulunamayan değer” demektir. İkinci satır sıfırıncı elemanı döndürür. Üçüncü satırda T metin olarak çıkarılır; son satırdaki <number> ise tipi açıkça seçer. Sonuç tipleri sırasıyla string | undefined ve number | undefined'dır. Dönüşteki yokluk ihtimalini özellikle yazdık; “ilk eleman” ile “mutlaka eleman var” aynı vaat değildir.³⁶

Genel fonksiyonun içinde de sözleşme geçerlidir: T'nin ne olduğunu bilmiyorsan keyfine göre liste[0].toUpperCase() çağıramazsın; eleman sayı da olabilir. Genel tip, denetimden kaçış değil, giriş ile çıkış arasında korunacak ilişkinin tarifidir. any “ilişkiyi denetleme” derken T “tip hangisi seçilirse seçilsin bu ilişkiyi koru” der.⁶

Daha önce gördüğün köşeli açılar

Array<Soru> ile Soru[] aynı dizi tipini anlatır. Promise<Soru[]> ise 25.6'daki Promise'in başarıyla sonuçlandığında sağlayacağı değerin soru dizisi olmasını tarif eder; başarısız olma ihtimalini ortadan kaldırmaz. Böylece yeni bir çalışma zamanı mekanizması öğrenmeden tanıdık nesnelerin taşıdığı bilgiye tip verebiliriz.³⁶

type ListeSonucu<T> = { kayitlar: T[] };
const sorular: ListeSonucu<Soru> = { kayitlar: [] };

İlk satır, eleman tipi dışarıdan seçilen bir nesne tipine ad verir. İkinci satırda o boşluğu Soru ile doldurduk: sorular.kayitlar artık soru dizisidir; boş dizi de geçerli bir soru dizisidir. Bu parça 30.2'de tanımlanan Soru tipini kullanır. Genel nesne tipleri ve genel fonksiyonlar aynı “tipi parametreleştir” fikrinin iki görünümüdür.⁶

30.5 JavaScript prototipinden TypeScript'e kademeli geçiş

TypeScript'e geçiş “HTML, CSS ve JavaScript'i atıp başka bir ürün yazmak” değildir. Mevcut JavaScript davranışlarını ve modül düzenini koruyup denetimi adım adım artırabiliriz. Resmî geçiş rehberi JavaScript dosyalarının kabul edilmesini, kaynak ile çıktının ayrılmasını, ardından dosyaların tek tek .ts'ye taşınmasını anlatır. Kerem'in prototip kodunu görmediğimiz için aşağıdaki bir gerçek dosya dökümü değil, önerilen çalışma sırasıdır.⁷

1. Çalışan davranışı tarif et. Örneğimizde yanlış cevap sıfır puan, doğru cevap temel puan, belirli seride bonus alır. Neyi koruduğunu bilmiyorsan uzantı değişikliğiyle davranış değişikliğini karıştırırsın. Bu bir çalışma önerisidir; TypeScript'in otomatik verdiği bir güvence değildir.
2. Önce küçük bir JavaScript dosyasını denetle. // @ts-check ile tek dosyada denetim açabilir, yorumlardaki JSDoc belirtimleriyle parametreleri anlatabilirsin. Her dosyayı aynı gün dönüştürmek zorunda değilsin.⁸⁹
3. Bir küçük modülü .ts yap. DOM'a dokunmayan puan hesabı iyi bir örnektir; sayı, koşul ve dönüş değerinden oluşur. Eksik tip bilgisini tamamla, gerçek hatayı düzelt; her uyarıyı any ile susturma.⁷
4. Verinin ortak şekillerini adlandır. Soru, Kullanici, seçili şık gibi sınırları tarif et; sonra bu veriyi kullanan dosyaları sırayla denetle. .js ile .ts geçiş süresince birlikte bulunabilir.⁷⁸
5. Dönüştürme ve denetleme adımlarını görünür tut. Kaynak .ts dosyasını tarayıcıya doğrudan bağlamak yerine mevcut araç zincirinin ürettiği JavaScript'i kullan. Expo'ya geçerken onun proje ayarlarından başla; aşağıdaki küçük deneme ayarlarını bütün projeye körlemesine kopyalama.⁵⁷

Birinci basamak: dosya JavaScript kalabilir

// @ts-check
/**
 * @param {boolean} dogruMu
 * @param {number} seri
 * @returns {number}
 */
export function puanHesapla(dogruMu, seri) {
  if (!dogruMu) return 0;
  const bonus = seri >= 7 ? 5 : 0;
  return 10 + bonus;
}

İlk yorum editörün TypeScript desteğine dosyayı denetlemesini söyler; @param satırları parametreleri, @returns dönüşü anlatan JSDoc tip belirtimleridir (JSDoc type annotations). Kalan satırlar normal JavaScript'tir: fonksiyon dışa aktarılır, yanlış cevapta erken döner, seri koşulundan bonus hesaplar ve toplar. Yorumlar tarayıcının yeni bir sözdizimi öğrenmesini gerektirmez. Komut satırında örneğin npx tsc --allowJs --checkJs --noEmit puan.js ile denetlenebilir.⁹⁸

İkinci basamak: aynı davranışı tiplerle yazmak

// puan.ts
export function puanHesapla(dogruMu: boolean, seri: number): number {
  if (!dogruMu) return 0;
  const bonus = seri >= 7 ? 5 : 0;
  return 10 + bonus;
}

Burada JSDoc'taki sözleşme doğrudan fonksiyon imzasına taşındı. 27.1'deki örnek kural aynı: doğru cevap ve seri 7 için 10 + 5 = 15, doğru cevap ve seri 6 için 10, yanlış cevap için 0. Bu üç durum Python hesabıyla ve örneklerin gerçek çalıştırılmasıyla karşılaştırıldı. Bunlar uygulamanın değişmez ürün kararı değil, kitapta kullanılan örnek kuraldır. Tip eklemek tek başına bu kuralı değiştirmedi.⁵

Bir proje ayarı neyi değiştirir?

TypeScript yapılandırma dosyası (tsconfig.json), denetlenecek dosyaları ve derleyici seçeneklerini bir yerde toplar. Şu, yalnızca küçük bir src klasörü için denetim örneğidir; JavaScript çıktısını başka araç üreteceği için burada çıktı yazmayı kapatıyoruz:⁷⁸

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true,
    "strict": true,
    "noEmit": true
  },
  "include": ["src/**/*"]
}

allowJs JavaScript dosyalarını da proje girdisi olarak kabul eder; checkJs o JavaScript dosyalarındaki hataların raporlanmasını açar; ikisi aynı iş değildir. strict sıkı tip denetimi grubunu açar; noEmit JavaScript çıktı yazılmasını engeller. include dosyaların hangi klasörden alınacağını söyler. npx tsc --project tsconfig.json bu proje ayarını kullanır. noEmit olan bu denetim örneğinden çalıştırılacak dosya bekleme; 30.3'teki bağımsız derleme deneyinde çıktı üretimini ayrıca yaptık.⁸

HTML ve CSS dosyaları TypeScript dosyası yapılmaz. Düz davranış modülü .ts olabilir; bir sonraki bölümde göreceğin JSX sözdizimini içeren TypeScript dosyasının uzantısı .tsx'tir. Uzantıyı değiştirmek tek başına bir dönüştürücü, paketleyici ya da doğru proje ayarı kurmaz. Resmî geçiş rehberinin de uyardığı gibi dönüşümden sonra görülen tip hatalarını tek tek incelemek gerekir; bazıları gerçek hata, bazıları da kodun niyetini daha açık anlatma ihtiyacıdır.⁷

Özellikle form girdilerinde bu fark somuttur. Bir input öğesinin value özelliği karakter dizisidir; kutuda “70” görünmesi onun sayı 70 olduğu anlamına gelmez. TypeScript bunu as number yazarak gerçek sayıya dönüştürmez. Dönüştürme ve girdinin kabul edilebilir olup olmadığını kontrol etme, gerçek JavaScript davranışlarıyla yapılır. 26.2'deki olay kodunu taşırken böyle sınırları görürsen denetleyiciyi susturmadan önce girdinin gerçekte ne olduğuna bak.¹¹³

Bu bölümde neler kuruldu

TypeScript, JavaScript'e çalışmadan önce denetlenen sözleşmeler ekler. Tip belirtimi tipi açıkça söyler; tip çıkarımı bunu her yerde tekrar yazma ihtiyacını azaltır. interface nesne şekline, type bir tipe ad verir; birleşim tipi olası değerleri bir araya getirir, tip daraltma gerçek kontrollerden hangi olasılığın kaldığını çıkarır. tsc tip denetler ve istenirse JavaScript üretir; tip belirtimleri bu sırada silinir. as doğrulama değildir, any denetimi zayıflatır, unknown kullanmadan önce daraltmayı gerektirir. Genel tipler farklı tipler için giriş–çıkış ilişkisini korur. Geçiş tek hamlede olmak zorunda değildir: JavaScript + JSDoc, küçük bir TypeScript modülü, sonra ortak veri sözleşmeleri.

Terimler sözlükte, Bölüm 30 başlığı altında. Sıradaki Bölüm 31'de bu sözleşmeleri kullanıcı arayüzünün parçalarına vereceğiz; TypeScript'i tekrar baştan anlatmadan bileşenlerin beklediği girdileri okuyacağız.

Kaynaklar

1. TypeScript Handbook, The TypeScript Handbook, “About this Handbook”: JavaScript programlarına statik tip denetimi eklemenin amacı.
2. TypeScript Handbook, TypeScript for JavaScript Programmers: çıkarım, nesne şekilleri, birleşimler, genel tipler ve yapısal tipleme.
3. TypeScript Handbook, Everyday Types: temel tipler, diziler, fonksiyonlar, isteğe bağlı özellikler, birleşimler, tip takma adları, arayüzler, tip iddiaları, sabit değer tipleri ve yokluk denetimi.
4. TypeScript Handbook, Narrowing: typeof, eşitlik, in, kontrol akışı, sıfır ve null tuzakları.
5. TypeScript Handbook, The Basics, “Static type-checking”, “Types for Tooling”, “tsc, the TypeScript compiler”, “Emitting with Errors”, “Erased Types” ve “Strictness”.
6. TypeScript Handbook, Generics, “Hello World of Generics”, “Working with Generic Type Variables” ve “Generic Types”: tip bilgisini giriş ile çıkış arasında koruma.
7. TypeScript Handbook, Migrating from JavaScript: kaynak–çıktı ayrımı, allowJs, tek dosyayla başlama, .ts/.tsx ve sıkılık ayarları.
8. TypeScript, TSConfig Reference: allowJs, checkJs, strict, noEmit, noEmitOnError ve include seçenekleri.
9. TypeScript Handbook, Type Checking JavaScript Files: JavaScript dosyalarının denetlenmesi ve JSDoc ile tip anlatımı.
10. MDN, JSON.parse(), “Return value” ve “Exceptions”: JSON metninden değer üretme ile sözdizimi hatası; uygulamaya özgü şekil denetiminden ayrılır.
11. MDN, HTMLInputElement: value property: girdi değerinin karakter dizisi olması.