TypeScript, JavaScript'in üzerine kurulu, güçlü bir şekilde yazılmış bir programlama dili olduğunu ve her ölçekte daha iyi araçlar sağladığını iddia ediyor. Bununla birlikte,     türü içerir ve bu genellikle kod tabanına gizlice sızarak TypeScript'in birçok avantajının kaybolmasına neden olabilir. TypeScript any  Bu makalede TypeScript projelerinde   türün kontrolünü ele almanın yolları araştırılmaktadır. TypeScript'in gücünü açığa çıkarmaya, üstün tür güvenliği elde etmeye ve kod kalitesini artırmaya hazır olun. any  TypeScript'te Herhangi Birini Kullanmanın Dezavantajları  TypeScript, geliştirici deneyimini ve üretkenliğini artırmak için bir dizi ek araç sağlar:  Hataların geliştirme aşamasında erken yakalanmasına yardımcı olur.  Kod editörleri ve IDE'ler için mükemmel otomatik tamamlama sunar.  Harika kod gezinme araçları ve otomatik yeniden düzenleme aracılığıyla büyük kod tabanlarının kolayca yeniden düzenlenmesine olanak tanır.  Türler aracılığıyla ek anlamlar ve açık veri yapıları sağlayarak kod tabanının anlaşılmasını kolaylaştırır.  Ancak kod tabanınızda   türü kullanmaya başladığınız anda yukarıda sıralanan tüm avantajları kaybedersiniz.   tip, tip sisteminde tehlikeli bir boşluktur ve bunun kullanılması, tip kontrolüne bağlı tüm araçların yanı sıra tüm tip kontrolü yeteneklerini de devre dışı bırakır. Sonuç olarak TypeScript'in tüm avantajları kaybolur: hatalar gözden kaçırılır, kod düzenleyiciler daha az kullanışlı hale gelir ve daha fazlası. any any  Örneğin aşağıdaki örneği göz önünde bulundurun:   function parse(data: any) { return data.split(''); } // Case 1 const res1 = parse(42); // ^ TypeError: data.split is not a function // Case 2 const res2 = parse('hello'); // ^ any  Yukarıdaki kodda:    işlevi içindeki otomatik tamamlamayı kaçıracaksınız.   düzenleyicinizde,   için mevcut yöntemlere ilişkin doğru öneriler size sunulmayacaktır. parse data. data  İlk durumda, bir   çünkü bir dize yerine bir sayı ilettik. TypeScript,   tür denetimini devre dışı bıraktığından hatayı vurgulayamıyor. TypeError: data.split is not a function any  İkinci durumda   değişkeni de   türe sahiptir. Bu,   birinin tek bir kullanımının kod tabanının büyük bir kısmı üzerinde basamaklı bir etkiye sahip olabileceği anlamına gelir. res2 any any    kullanılması yalnızca aşırı durumlarda veya prototip oluşturma ihtiyaçları için uygundur. Genel olarak TypeScript'ten en iyi şekilde yararlanmak için   kullanmaktan kaçınmak daha iyidir. any any  Herhangi Bir Türün Geldiği Yer  Bir kod tabanındaki   türün kaynaklarının farkında olmak önemlidir çünkü açıkça   yazmak tek seçenek değildir.   bir türü kullanmaktan kaçınmak için elimizden geleni yapmamıza rağmen, bazen dolaylı olarak kod tabanına gizlice girebilir. any any any  Bir kod tabanında   türden dört ana kaynak vardır: any  Tsconfig'deki derleyici seçenekleri.  TypeScript'in standart kütüphanesi.  Proje bağımlılıkları.    kod tabanında açık kullanımı. any  İlk iki nokta için   ve   konularında zaten makaleler yazdım. Projelerinizde tip güvenliğini artırmak istiyorsanız lütfen bunlara göz atın. tsconfig'te Önemli Hususlar Standart Kütüphane Türlerinin Geliştirilmesi  Bu sefer kod tabanındaki   türün görünümünü kontrol etmeye yönelik otomatik araçlara odaklanacağız. any  Aşama 1: ESLint'i kullanma    , web geliştiricileri tarafından en iyi uygulamaları ve kod biçimlendirmesini sağlamak için kullanılan popüler bir statik analiz aracıdır. Kodlama stillerini uygulamak ve belirli kurallara uymayan kodları bulmak için kullanılabilir. ESLint  ESLint,   eklentisi sayesinde TypeScript projeleriyle de kullanılabilir. Büyük olasılıkla, bu eklenti projenize zaten yüklenmiştir. Ancak değilse resmi   takip edebilirsiniz. typectipt-eslint başlangıç kılavuzunu    için en yaygın yapılandırma aşağıdaki gibidir: typescript-eslint   module.exports = { extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', root: true, };  Bu yapılandırma,   TypeScript'i sözdizimi düzeyinde anlamasına olanak tanıyarak, bir kodda manuel olarak yazılan türler için geçerli olan basit eslint kuralları yazmanıza olanak tanır. Örneğin,   şeyin açıkça kullanımını yasaklayabilirsiniz. eslint any    ön ayar, kod doğruluğunu iyileştirmeyi amaçlayan, dikkatle seçilmiş bir dizi ESLint kuralını içerir. Ön ayarın tamamının kullanılması tavsiye edilse de, bu makalenin amacı doğrultusunda yalnızca   kuralına odaklanacağız. recommended no-explicit-any  açık-hiçbiri  TypeScript'in katı modu, ima edilen   ifadesinin kullanımını engeller, ancak   açıkça kullanılmasını engellemez.   kural, kod tabanında   yere manuel olarak yazılmasını yasaklamaya yardımcı olur. any any no-explicit-any any   // ❌ Incorrect function loadPokemons(): any {} // ✅ Correct function loadPokemons(): unknown {} // ❌ Incorrect function parsePokemons(data: Response<any>): Array<Pokemon> {} // ✅ Correct function parsePokemons(data: Response<unknown>): Array<Pokemon> {} // ❌ Incorrect function reverse<T extends Array<any>>(array: T): T {} // ✅ Correct function reverse<T extends Array<unknown>>(array: T): T {}  Bu kuralın temel amacı takım genelinde   kullanımın engellenmesidir. Bu, ekibin projede   kullanımının caydırılmadığı konusundaki anlaşmasını güçlendirmenin bir yoludur. any any  Bu çok önemli bir hedeftir çünkü   birinin tek bir kullanımı bile   dolayı kod tabanının önemli bir kısmı üzerinde basamaklı bir etkiye sahip olabilir. Ancak bu hala nihai tip güvenliğe ulaşmaktan çok uzak. any tür çıkarımından  Neden hiçbir şeyin açık olmaması yeterli değil  Her ne kadar açıkça kullanılan   ile ilgilenmiş olsak da, bir projenin bağımlılıkları içinde npm paketleri ve TypeScript'in standart kütüphanesi de dahil olmak üzere hala birçok ima edilen   vardır. any any  Herhangi bir projede görülmesi muhtemel olan aşağıdaki kodu göz önünde bulundurun:   const response = await fetch('https://pokeapi.co/api/v2/pokemon'); const pokemons = await response.json(); // ^? any const settings = JSON.parse(localStorage.getItem('user-settings')); // ^? any  Hem   hem de   değişkenleri örtülü olarak   türe verildi. Bu durumda ne   ne de TypeScript'in katı modu bizi uyaracaktır. Henüz değil. pokemons settings any no-explicit-any  Bunun nedeni,   ve   türlerinin TypeScript'in standart kitaplığından gelmesi ve bu yöntemlerin açık   açıklama içermesidir. Değişkenlerimiz için hâlâ manuel olarak daha iyi bir tür belirleyebiliriz ancak standart kitaplıkta bunlardan   birinin yaklaşık 1.200 örneği vardır.   standart kitaplıktan kod tabanımıza gizlice girebileceği tüm durumları hatırlamak neredeyse imkansızdır. response.json() JSON.parse() any any any  Aynı şey dış bağımlılıklar için de geçerli. Npm'de pek çok kötü yazılmış kitaplık var ve bunların çoğu hala JavaScript ile yazılıyor. Sonuç olarak, bu tür kitaplıkların kullanılması, kod tabanında pek çok örtülü   bulunmasına kolaylıkla yol açabilir. any  Genel olarak   kodumuza sızmasının hâlâ birçok yolu vardır. any  Aşama 2: Tür Denetimi Yeteneklerinin Geliştirilmesi  İdeal olarak, TypeScript'te derleyicinin herhangi bir nedenle   türü alan herhangi bir değişken hakkında şikayette bulunmasını sağlayan bir ayara sahip olmak isteriz. Maalesef böyle bir ayar şu anda mevcut değil ve eklenmesi de beklenmiyor. any  Bu davranışı   eklentisinin type-checked modunu kullanarak başarabiliriz. Bu mod, TypeScript derleyicisinden ESLint kurallarına kadar eksiksiz tür bilgisi sağlamak için TypeScript ile birlikte çalışır. Bu bilgilerle, TypeScript'in tür denetleme yeteneklerini esasen genişleten daha karmaşık ESLint kuralları yazmak mümkündür. Örneğin, bir kural,   nasıl elde edildiğine bakılmaksızın,   türdeki tüm değişkenleri bulabilir. typescript-eslint any any  Yazıma duyarlı kuralları kullanmak için ESLint yapılandırmasını biraz değiştirmeniz gerekir:   module.exports = { extends: [ 'eslint:recommended', - 'plugin:@typescript-eslint/recommended', + 'plugin:@typescript-eslint/recommended-type-checked', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', + parserOptions: { + project: true, + tsconfigRootDir: __dirname, + }, root: true, };    için tür çıkarımını etkinleştirmek için   ESLint yapılandırmasına ekleyin. Ardından,   ön ayarı   ile değiştirin. İkinci ön ayar yaklaşık 17 yeni güçlü kural ekler. Bu makalenin amacı doğrultusunda bunlardan yalnızca 5 tanesine odaklanacağız. typescript-eslint parserOptions recommended recommended-type-checked  güvenli olmayan tartışma yok    kuralı,   türünde bir değişkenin parametre olarak iletildiği işlev çağrılarını arar. Bu olduğunda, yazım denetimi kaybolur ve güçlü yazmanın tüm faydaları da kaybolur. no-unsafe-argument any  Örneğin, parametre olarak bir nesne gerektiren bir   fonksiyonunu ele alalım. JSON'u aldığımızı, ayrıştırdığımızı ve   bir tür elde ettiğimizi varsayalım. saveForm any   // ❌ Incorrect function saveForm(values: FormValues) { console.log(values); } const formValues = JSON.parse(userInput); // ^? any saveForm(formValues); // ^ Unsafe argument of type `any` assigned // to a parameter of type `FormValues`.  Bu parametreyle   fonksiyonunu çağırdığımızda,   kuralı bunu güvensiz olarak işaretler ve   değişkeni için uygun türü belirtmemizi gerektirir. saveForm no-unsafe-argument value  Bu kural, işlev bağımsız değişkenleri içindeki iç içe geçmiş veri yapılarını derinlemesine inceleyecek kadar güçlüdür. Bu nedenle, nesnelerin işlev bağımsız değişkenleri olarak iletilmesinin hiçbir zaman türlenmemiş veriler içermeyeceğinden emin olabilirsiniz.   // ❌ Incorrect saveForm({ name: 'John', address: JSON.parse(addressJson), // ^ Unsafe assignment of an `any` value. });  Hatayı düzeltmenin en iyi yolu TypeScript'in   veya   veya   gibi bir doğrulama kitaplığını kullanmaktır. Örneğin, ayrıştırılan verilerin kesin türünü daraltan   fonksiyonunu yazalım. tür daraltmasını Zod Superstruct parseFormValues   // ✅ Correct function parseFormValues(data: unknown): FormValues { if ( typeof data === 'object' && data !== null && 'name' in data && typeof data['name'] === 'string' && 'address' in data && typeof data.address === 'string' ) { const { name, address } = data; return { name, address }; } throw new Error('Failed to parse form values'); } const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues saveForm(formValues);    türün,   kabul eden bir işleve bağımsız değişken olarak iletilmesine izin verildiğini unutmayın; çünkü bunu yapmakla ilgili herhangi bir güvenlik sorunu yoktur. any unknown  Veri doğrulama işlevlerini yazmak, özellikle büyük miktarda veriyle uğraşırken sıkıcı bir iş olabilir. Bu nedenle, bir veri doğrulama kütüphanesinin kullanılması dikkate alınmalıdır. Örneğin Zod'da kod şöyle görünecektir:   // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); const formValues = schema.parse(JSON.parse(userInput)); // ^? { name: string, address: string } saveForm(formValues);  güvenli olmayan atama yok    kuralı, bir değerin   türe sahip olduğu değişken atamaları arar. Bu tür atamalar, derleyiciyi bir değişkenin belirli bir türe sahip olduğunu düşünmesine neden olabilirken, veriler aslında farklı bir türe sahip olabilir. no-unsafe-assignment any  Önceki JSON ayrıştırma örneğini düşünün:   // ❌ Incorrect const formValues = JSON.parse(userInput); // ^ Unsafe assignment of an `any` value    kuralı sayesinde,   başka bir yere aktarmadan önce bile   türü yakalayabiliriz. Sabitleme stratejisi aynı kalıyor: Değişkenin değerine belirli bir tür sağlamak için tür daraltmayı kullanabiliriz. no-unsafe-assignment formValues any   // ✅ Correct const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues  güvenli olmayan üye erişimi yok ve güvenli olmayan çağrı yok  Bu iki kural çok daha az sıklıkla tetiklenir. Ancak deneyimlerime dayanarak, kötü yazılmış üçüncü taraf bağımlılıklarını kullanmaya çalıştığınızda bunlar gerçekten faydalıdır.    kuralı, bir değişkenin   türe sahip olması durumunda nesne özelliklerine erişmemizi engeller; çünkü bu,   veya   olabilir. no-unsafe-member-access any null undefined    kuralı,   türden bir değişkeni işlev olarak çağırmamızı engeller, çünkü bu bir işlev olmayabilir. no-unsafe-call any    adında kötü yazılmış bir üçüncü taraf kitaplığımızın olduğunu düşünelim: untyped-auth   // ❌ Incorrect import { authenticate } from 'untyped-auth'; // ^? any const userInfo = authenticate(); // ^? any ^ Unsafe call of an `any` typed value. console.log(userInfo.name); // ^ Unsafe member access .name on an `any` value.  Linter iki konuyu vurgulamaktadır:    işlevinin çağrılması güvenli olmayabilir, çünkü önemli argümanları işleve iletmeyi unutabiliriz. authenticate  Kimlik doğrulama başarısız olursa   olacağından   özelliğinin   nesnesinden okunması güvenli değildir. null name userInfo  Bu hataları düzeltmenin en iyi yolu, türü kesin olarak belirlenmiş bir API içeren bir kitaplık kullanmayı düşünmektir. Ancak bu bir seçenek değilse  . Sabit kitaplık türlerine sahip bir örnek şuna benzer: kitaplık türlerini kendiniz artırabilirsiniz   // ✅ Correct import { authenticate } from 'untyped-auth'; // ^? (login: string, password: string) => Promise<UserInfo | null> const userInfo = await authenticate('test', 'pwd'); // ^? UserInfo | null if (userInfo) { console.log(userInfo.name); }  güvenli olmayan dönüş yok    kuralı, daha spesifik bir şey döndürmesi gereken bir işlevden   türün yanlışlıkla döndürülmemesine yardımcı olur. Bu gibi durumlar, derleyiciyi, döndürülen değerin belirli bir türe sahip olduğunu düşünmesine neden olabilirken, veriler gerçekte farklı bir türe sahip olabilir. no-unsafe-return any  Örneğin, JSON'u ayrıştıran ve iki özelliğe sahip bir nesne döndüren bir fonksiyonumuz olduğunu varsayalım.   // ❌ Incorrect interface FormValues { name: string; address: string; } function parseForm(json: string): FormValues { return JSON.parse(json); // ^ Unsafe return of an `any` typed value. } const form = parseForm('null'); console.log(form.name); // ^ TypeError: Cannot read properties of null    fonksiyonu, ayrıştırılan değer kontrol edilmediğinden, kullanıldığı programın herhangi bir bölümünde çalışma zamanı hatalarına neden olabilir.   kuralı bu tür çalışma zamanı sorunlarını önler. parseForm no-unsafe-return  Ayrıştırılan JSON'un beklenen türle eşleştiğinden emin olmak için doğrulama ekleyerek bunu düzeltmek kolaydır. Bu sefer Zod kütüphanesini kullanalım:   // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); function parseForm(json: string): FormValues { return schema.parse(JSON.parse(json)); }  Performans Hakkında Bir Not  Tür denetimli kuralların kullanılması, ESLint'in tüm türleri çıkarması için TypeScript'in derleyicisini çağırması gerektiğinden performans kaybıyla birlikte gelir. Bu yavaşlama esas olarak linter'ı ön işleme kancalarında ve CI'da çalıştırırken fark edilir, ancak bir IDE'de çalışırken fark edilmez. Tür denetimi, IDE başlangıcında bir kez gerçekleştirilir ve ardından siz kodu değiştirdikçe türleri günceller.  Yalnızca türlerin çıkarımının,   derleyicisinin olağan çağrılmasından daha hızlı çalıştığını belirtmekte fayda var. Örneğin, yaklaşık 1,5 milyon satırlık TypeScript kodu içeren en son projemizde,   aracılığıyla tür kontrolü yaklaşık 11 dakika sürerken, ESLint'in türe duyarlı kurallarının önyükleme yapması için gereken ek süre yalnızca yaklaşık 2 dakikadır. tsc tsc  Ekibimiz için, türe duyarlı statik analiz kurallarının kullanılmasıyla sağlanan ek güvenlik, ödün vermeye değerdir. Daha küçük projelerde bu kararı vermek daha da kolaydır.  Çözüm  TypeScript projelerinde   birinin kullanımını kontrol etmek, optimum tür güvenliği ve kod kalitesi elde etmek için çok önemlidir. Geliştiriciler   eklentisini kullanarak kod tabanlarındaki   türün oluşumlarını tanımlayabilir ve ortadan kaldırabilir, böylece daha sağlam ve bakımı kolay bir kod tabanı elde edilebilir. any typescript-eslint any  Türe duyarlı eslint kuralları kullanıldığında,   bir anahtar kelimenin kod tabanımızda görünmesi bir hata veya gözden kaçırma yerine kasıtlı bir karar olacaktır. Bu yaklaşım bizi kendi   , standart kütüphanede ve üçüncü taraf bağımlılıklarında kullanmaktan korur. any any  Genel olarak, türe duyarlı bir linter, Java, Go, Rust ve diğerleri gibi statik olarak yazılan programlama dillerine benzer bir tür güvenliği düzeyi elde etmemizi sağlar. Bu, büyük projelerin geliştirilmesini ve bakımını büyük ölçüde basitleştirir.  Umarım bu makaleden yeni bir şeyler öğrenmişsinizdir. Okuduğunuz için teşekkürler!  kullanışlı bağlantılar   Kütüphane: typescript-eslint   Makale: tsconfig'te Önemli Hususlar   Makale: Standart Kütüphane Türlerinin Geliştirilmesi   Dokümanlar: TypeScript'te Yazım Daraltma   Dokümanlar: TypeScript'te Tür Çıkarımı   Kütüphane: Zod   Kütüphane: Üst Yapı

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

TypeScript'i Gerçekten "Kuvvetle Yazılmış" Hale Getirmek

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Kripto Büyümesi: Etkili Kullanıcı Kişilikleri Oluşturma

AI/ML Datalake için Referans Mimarisi Oluşturmaya Yönelik Mimar Kılavuzu

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Kripto Büyümesi: Etkili Kullanıcı Kişilikleri Oluşturma

AI/ML Datalake için Referans Mimarisi Oluşturmaya Yönelik Mimar Kılavuzu

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps