TypeScript 1.5
, la nomenclature a été modifiée.
Les "modules internes" sont maintenant des "espaces de noms".
Les "modules externes" sont désormais simplement des "modules", afin de s'aligner sur la terminologie
d'ECMAScript 2015
(c'est-à-dire qu'elle module X {
équivaut à celle que nous préférons maintenant namespace X {
).
TypeScript
.
Comme nous l'avons mentionné dans notre note sur la terminologie, les "modules internes" sont maintenant appelés "espaces de noms".
En outre, partout ou le mot-clé module
a été utilisé lors de la déclaration d'un module interne, namespace
peut et doit être utilisé à la place.
Cela évite de créer de la confusion chez les nouveaux utilisateurs en les surchargeant de termes similaires.Validateurs dans un seul fichier
Validation
.
Parce que nous voulons que les interfaces et les classes ici soient visibles en dehors de l'espace de noms, nous les précédons de export
.
à l'inverse, les variables lettersRegexp
et numberRegexp
sont des détails d'implémentation, elles ne sont donc pas déclarées et ne seront pas
visibles pour le code en dehors de l'espace de noms. Dans le code de test au bas du fichier, nous devons maintenant qualifier les noms des
types lorsqu'ils sont utilisés en dehors de l'espace de noms, par exemple Validation.LettersOnlyValidator
.Validateurs de namespaced
Validation
de noms en plusieurs fichiers.
Même si les fichiers sont séparés, ils peuvent chacun contribuer au même espace de nom et peuvent être utilisés comme s'ils
étaient tous définis à la même place. Comme il existe des dépendances entre les fichiers, nous ajouterons des balises de référence
pour indiquer au compilateur les relations entre les fichiers. Notre code de test est par ailleurs inchangé.Validation.ts
LettersOnlyValidator.ts
ZipCodeValidator.ts
Test.ts
--outFile
pour
compiler tous les fichiers d'entrée en un seul fichier de sortie JavaScript
:JavaScript
pour chaque fichier d'entrée.
Si plusieurs fichiers JS
sont générés, nous devrons utiliser des balises ‹script›
sur notre page Web pour charger
chaque fichier émis dans l'ordre approprié, par exemple :MyTestPage.html (extrait)
import q = x.y.z
.
Ne pas confondre avec la syntaxe utilisée pour charger les modules import x = require("name")
, cette syntaxe crée simplement un alias pour le symbole spécifié.
Vous pouvez utiliser ces types d'importations (communément appelés alias) pour tout type d'identificateur, y compris les objets créés à partir d'importations de module.require
au lieu de cela, nous assignons directement à partir du nom qualifié du symbole que nous importons.
Ceci est similaire à utiliser var
, mais fonctionne également sur les significations de type et d'espace de nom du symbole importé.
Il est important de noter que pour les valeurs, import
s'agit d'une référence distincte du symbole d'origine.
Par conséquent, les modifications apportées à un alias var
ne seront pas reflétées dans la variable d'origine.TypeScript
, nous devons déclarer l'API exposée par la bibliothèque.
étant donné que la plupart des bibliothèques JavaScript
n'exposent que quelques objets de niveau supérieur,
les espaces de noms constituent un bon moyen de les représenter..d.ts
.
Si vous connaissez C/C++
, vous pouvez les considérer comme des fichiers .h
.
D3
définit ses fonctionnalités dans un objet global appelé d3
.
Comme cette bibliothèque est chargée via une balise ‹script›
(au lieu d'un chargeur de module), sa déclaration utilise des espaces de noms pour définir sa forme.
Pour que le compilateur TypeScript
puisse voir cette forme, nous utilisons une déclaration d'espace de nom ambiant.
Par exemple, nous pourrions commencer à l'écrire comme suit :D3.d.ts (extrait simplifié)