Tip oluşturmak neden işe yarar
Tipli modeller hataları erkenden yakalar. Bir API yanıtı bir interface ya da class ile tanımlandığında editörün alan adlarını tamamlar, derleyici yanlış yazılmış bir anahtarı fark eder, adı değişmiş bir alan da çalışma anında sessizce undefined ya da null dönmek yerine hata olarak karşına çıkar. Elli alanlı ve üç kat iç içe bir yanıt için bu tipleri elle yazmak hem zaman alır hem de hataya çok açıktır.
Bir oluşturucu bu tekrarlı işi bir saniyede yapar. Sonuç iyi bir ilk taslaktır; sen gözden geçirir, gereken yerleri yeniden adlandırır ve commit edersin. API değiştiğinde de yeni bir yanıtla tipleri birkaç saniyede yeniden oluşturup farkları kod karşılaştırma aracınla görebilirsin; elle yazılmış modellerde bu değişiklikler çoğu zaman gözden kaçar.
Burada dene: JSON'dan Kod Oluşturucu
Aracın tam sayfasını açOluşturucu örneğinden neleri çıkarır
Her şey JSON'daki değerlerden gelir. Bu yüzden örneğin kalitesi her şeyden daha önemlidir. Aşağıdaki tablo, JSON'da gördüğü her değer için aracın hangi tipi seçtiğini gösteriyor.
| JSON'da | Çıkarılan tip | Örnek |
|---|---|---|
| Metin | string | "name": "Ayşe" |
| Tam sayı | int, 2.147.483.647 üstünde long | "id": 42 |
| Ondalık noktalı sayı | double ya da float | "price": 19.0 |
| true ya da false | boolean | "active": true |
| ISO tarih biçiminde metin | açıksa tarih tipi | "created": "2026-10-27T09:30:00Z" |
| Bazı öğelerde null | nullable tip | "phone": null |
| Bazı öğelerde olmayan anahtar | isteğe bağlı alan | "discount" sadece bir öğede |
| Nesne | adı olan yeni bir tip | "address": { ... } |
| Nesne listesi | birleştirilmiş tek tipin listesi | "items": [ { ... }, { ... } ] |
Ona çeşitlilik içeren bir örnek ver
Bir oluşturucu sadece gördüğünü anlatabilir. Örneğinde tek kalemli tek bir sipariş varsa her alan zorunlu, hiçbir alan nullable görünmez. Bazılarında indirim olan, bazılarında olmayan bir sipariş listesi verirsen indirim alanı doğru şekilde isteğe bağlı olarak işaretlenir.
Bu yüzden tip oluşturmadan önce birkaç öğe içeren bir yanıt topla, mümkünse uç durumları da ekle: telefon numarası olmayan bir müşteri, kalemi olmayan bir sipariş, ondalıklı fiyatı olan bir ürün. Hepsini en üst düzeyde tek bir diziye koy; oluşturucu hepsini birleştirip her yapı için tek bir tip çıkarır. Örneğin eksik kaldığında şu durumlarla karşılaşırsın:
- Her öğede null olan alanlar unknown, object ya da Any gibi genel bir tip alır, çünkü gerçek tip görünmez.
- Boş listeler de aynı nedenle tipi bilinmeyen öğelerin listesi olur.
- Bir öğede sayı, başka bir öğede metin olan alan TypeScript'te union, diğer dillerde genel bir tip olur.
- Bazı veritabanı anahtarları gibi 2^53 üstündeki büyük ID'ler metin olarak daha güvenlidir. JavaScript onları sayı olarak tam gösteremez.
Adlar, attribute'lar ve dil kuralları
JSON anahtarları çoğu zaman sunucu tarafının stilini izler, örneğin Python ya da Ruby'den gelen snake_case; senin istemci kodun ise başka bir stil kullanır. İyi bir oluşturucu alanları hedef dilin kuralına göre yeniden adlandırır ve asıl anahtarı bir attribute içinde tutar, böylece serileştirme veriyle uyumlu kalır. Her dilde durum şöyle:
| Dil | Alan adları | JSON anahtarı nasıl korunur |
|---|---|---|
| TypeScript | Değişmez | Gerekmez; alışılmadık anahtarlar tırnağa alınır |
| C# | PascalCase | [JsonPropertyName] ya da [JsonProperty] |
| Python | snake_case | Pydantic'te Field(alias=...) |
| Go | Dışa açık, ID ve URL ile | json:"key" struct tag'leri |
| Java | camelCase | @JsonProperty (Jackson) |
| Kotlin | camelCase | @SerialName (kotlinx.serialization) |
Tipler doğrulama değildir
Bir TypeScript interface'i kod derlendiğinde ortadan kalkar. API, interface'in vaat ettiğinden farklı bir şey gönderirse çalışma anında hiçbir şey bunu durdurmaz. Çoğu dilde düz class'lar için de durum aynıdır: deserializer doldurabildiğini doldurur, gerisini boş bırakır.
Veri senin kontrolün dışından geliyorsa geldiği anda doğrula. Python'da Pydantic modelleri bunu kendiliğinden yapar; oluşturucuda bu stili seçmek için iyi bir neden. TypeScript'te veriyi çalışma anında kontrol eden kütüphanelerin şemaları oluşan interface'lerden yazılabilir. C#, Java ve Kotlin'de mutlaka olması gereken alanları zorunlu olarak işaretle ve serileştiricinin erkenden hata vermesine izin ver.
Commit etmeden önce kontrol listesi
Oluşan kodu projene eklemeden önce şu maddelerin üzerinden geç. Birkaç dakikalık kontrol, ileride saatler sürecek hata ayıklamayı önler.
- En üstteki tipin adını Root'tan Order gibi anlamlı bir ada çevir.
- unknown, object, Any ya da JsonElement tipli her alanı gözden geçir ve gerçek tipiyle değiştir.
- Sayıları kontrol et: fiyat gerçekten double mı, yoksa para için decimal bir tip mi olmalı?
- Tarihleri kontrol et: metin olarak mı, yoksa saat dilimi belli bir tarih tipi olarak mı istiyorsun?
- Hangi isteğe bağlı alanların gerçekten isteğe bağlı olduğuna, hangilerinin örnekte sadece tesadüfen eksik kaldığına karar ver.
- Örnekleri biraz farklı olduğu için oluşturucunun ayrı tuttuğu tipleri birleştir.