TypeScript'te ad alanı ve modül karışıklığı?

Typescript'in resmi sitesi bana bir soru sordurdu, "Namespace kullanmamız gerekiyor mu, yoksa gerek yok mu?".

Aşağıdaki alıntı, bu iki şeyi iyi bir şekilde açıklıyor:

TypeScript 1.5'te terminolojinin değiştiğini not etmek önemlidir. "İç modüller" artık "ad alanları" olarak adlandırılmaktadır. "Dış modüller" ise artık basitçe "modüller" olarak adlandırılmaktadır; bu, ECMAScript 2015’in terminolojisiyle uyumlu hale getirilmiştir (özellikle module X { ifadesi, artık tercih edilen namespace X { ile eşdeğerdir).

Yani, TS ekibinin namespace'i tercih etmesini öneriyorlar. Ayrıca, dahili modülü yapılandırmak için "namespace" kullanmamız gerektiğini söylüyor:

Bu yazı, TypeScript'te kodunuzu ad alanları (önceden "internal modules" olarak adlandırılıyordu) kullanarak düzenlemenin çeşitli yollarını özetlemektedir. Terminolojiyle ilgili notumuzda da belirttiğimiz gibi, "internal modules" artık "namespaces" olarak adlandırılmaktadır. Ek olarak, bir internal module bildirirken kullanılan module anahtar kelimesi yerine namespace anahtar kelimesi kullanılabilir ve kullanılmalıdır. Bu, benzer isimli terimlerle kullanıcıları karıştırmaktan kaçınır.

Yukarıdaki alıntı tamamen Namespace bölümünden ve evet, tekrar ediyor, ancak iç bir senaryoda.
ancak modül bölümünde, bir paragraf, şunu söylüyor:

ECMAScript 2015 ile başlayarak, modüller dilin yerleşik bir parçasıdır ve uyumlu tüm motor uygulamaları tarafından desteklenmelidir. Bu nedenle, yeni projeler için modüller önerilen kod organizasyon mekanizması olacaktır.

Bu, ad alanıyla uğraşmamam gerektiği ve baştan sona modül kullanmanın geliştirmek için önerilen yol olduğu anlamına mı geliyor?

Cevap #1

Bu, ad alanıyla uğraşmamam gerektiği ve baştan sona modül kullanmanın geliştirmek için önerilen yol olduğu anlamına mı geliyor?

Bunu tam olarak öyle söylemezdim... işte olanların başka bir açıklaması. Bir zamanlar, Typescript'te kullanılan iki terim vardı

  1. "external modules" - bu, JS topluluğunun AMD (ör. RequireJS) veya CommonJS (ör. NodeJS) modülleri diye adlandırdığı şeye karşılık gelen TS analoguydu. Bu isteğe bağlıydı; sadece tarayıcı tabanlı kod yazan bazı insanlar için, her zaman bununla uğraşmazlar, özellikle de dosyalar arasında iletişim kurmak için global değişkenleri kullanıyorlarsa.
  2. "internal modules" - bu, tüm değişkenlerin/fonksiyonların global olmasını önlemek için değişkenlerinizi/fonksiyonlarınızı hiyerarşik olarak düzenlemenin bir yoludur. Aynı desen JS'te de vardır; bu, insanların değişkenlerini hepsini global yapmak yerine nesneler/ iç içe nesnelere organize ettikleri zamandır.

2015 Ecmascript (aynı zamanda ES6 olarak da bilinir) ortaya çıktı ve "dış modüller" kategorisine ait yeni, resmi ve standart bir format ekledi. Bu değişiklik nedeniyle, Typescript, yeni Javascript standardına uyacak şekilde terminolojiyi değiştirmek istedi (çünkü Javascript’in bir üst kümesi olmayı seviyor ve Javascript’ten gelen kullanıcılar için kafa karışıklığını önlemeye çalışıyor). Böylece, "dış modüller" sadece "modüller" olarak basitleştirildi ve "iç modüller" ise "ad alanları" olarak yeniden adlandırıldı.

Burada bulduğunuz alıntı:

ECMAScript 2015 ile başlayarak, modüller dilin yerleşik bir parçasıdır ve uyumlu tüm motor uygulamaları tarafından desteklenmelidir. Bu nedenle, yeni projeler için modüller önerilen kod düzenleme mekanizması olacaktır.

Muhtemelen henüz (harici) modülleri kullanmayan kullanıcılar için rehberliğe atıfta bulunuyor. Şimdi en azından kullanmayı düşünmelerini sağlamak için. Ancak, ES6 modülleri için destek hâlâ eksiktir; çünkü Mayıs 2016 itibarıyla bu tarayıcılar yerleşik modül yükleyicilere sahip değiller. Bu yüzden, ya RequireJS veya SystemJS gibi çalışma zamanında bunu ele alan bir polyfill eklemeli, ya da bunu derleme zamanında (web sitenize dağıtmadan önce) ele alan browserify veya webpack gibi bir paketleyici kullanmalısınız.

Peki, her iki modülü (eski adıyla "dış modüller") ve ad alanlarını aynı anda kullanır mıydın? Kesinlikle - her ikisini de kod tabanlarımda sıkça kullanırım. Kod dosyalarımı düzenlemek için (dış) modülleri kullanıyorum.

Ad alanları Typescript'te son derece kullanışlıdır. Özellikle, fonksiyon nesnelerine ek özellikler eklemek için tür güvenli bir yol olarak ad alanı bildirim birleştirmesi kullanıyorum (JS'te sıkça kullanılan bir desen). Ayrıca, ad alanları normal nesne değişkenlerine çok benzese de, isimlerinin altına alt türler (iç içe geçmiş arayüzler, sınıflar, enumlar vb.) ekleyebilirsiniz.

İşte bir özelliğe sahip bir fonksiyon örneği (NodeJS kütüphanelerinde çok yaygındır):

function someUsefulFunction() {
  // asynchronous version
  return ...; // some promise
}

namespace someUsefulFunction {
  export function sync() {
    // synchronous version
  }
}

Bu, tüketicilerin bu yaygın NodeJS kalıbını yapmasına olanak tanır:

// asynchronous consumer
someUsefulFunction()
  .then(() => {
    // ... 
  });

// synchronous consumer
someUsefulFunction.sync();

Benzer şekilde, bir seçenekler nesnesini alan bir API'niz olduğunu varsayın. Eğer o seçenekler türü o API'ye özgüyse,

function myFunc(options?: myFunc.Options) {
    // ...
}

namespace myFunc {
    export interface Options {
        opt1?: number;
        opt2?: boolean;
        opt3?: string;
    }
}

Bu durumda, seçenekler için tür bildirimiyle daha büyük bir ad alanını (örneğin tüm modül kapsamını) kirletmek zorunda değilsiniz.

Umarım bu yardımcı olur!

İlgili makaleler