TypeScript'te hangi tip sistemi tercih edersiniz?

13 Tem 06:29

Birinci projede `any` tipini çok kullandım, sonradan kodu bakmakta zorlandım. Bir daha denemeye başladığımda `strict` moduna geçtim, derleyici uyarıları olunca kod daha güvenilir hale geldi. Artık hata ayıklamak kolaylaşıyor.

13 Tem 09:17

Eskiden `any` ile her şeyi "yaptırttığım" için şimdi TypeScript'in bana attığı kırmızı hataları gördüğümde 😭 "Niye bana izin vermedin?" diye sızlanıyorum. Strict o zaman, ama acemi olarak ilk hatamda hata ekranını kapatıp "noldu?" diyeceğimden eminim 😅

13 Tem 11:50

Vor etwa zwei Jahren hatte ich ein kleines Side-Project mit React und TypeScript gestartet, bei dem ich von Grund auf alles strikt typisiert umsetzen wollte. Ich hatte damals alle strict-Optionen in der `tsconfig.json` aktiviert – `strict: true`, `noImplicitAny: true`, `strictNullChecks: true` – einfach um wirklich sauberen Code zu schreiben. Doch dann kam der Moment, in dem ich eine externe API nutzen musste, die teilweise undokumentierte Rückgaben hatte. Der Punkt war nicht die Dokumentation, sondern dass bestimmte Felder nur manchmal zurückkamen – und dann auch noch mit unterschiedlichen Typen. Anfangs habe ich mit union types gearbeitet (`string | null | undefined`), aber nach ein paar Wochen wurde der Code so komplex, dass ich praktisch die Hälfte der Zeit mit Typ-Fixes verbrachte statt mit Logik. Ich habe dann irgendwann bewusst die `strictNullChecks`-Option deaktiviert und gezielt `any` oder `unknown` für solche Schnittstellenabschnitte eingesetzt. Ja, es fühlte sich erst wie ein Rückschritt an – aber plötzlich war der Code wieder lesbar und wartbar. Am Ende habe ich gelernt: strikt zu sein ist in Kern-Features oder eigenen Domänen-Typen Gold wert. Aber bei Third-Party-Code oder chaotischen APIs hilft Flexibilität manchmal mehr als Dogmatismus. Jetzt habe ich eine `tsconfig.strict.json` für "saubere" Modulen und eine `tsconfig.relaxed.json` für Legacy- oder API-Kram. Manchmal ist es einfach besser, pragmatisch zu bleiben.