Mr Josselin A - TypeScript









Namespaces

Références

L'actualité

Librairie

L'information

Introduction


Remarque à propos de la terminologie : Il est important de noter que dans 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 { ).

Cet article décrit les différentes manières d'organiser votre code à l'aide d'espaces de nommage (auparavant appelés "modules internes") dans 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.

Premiers pas

Commençons par le programme que nous allons utiliser comme exemple tout au long de cette page. Nous avons écrit un petit ensemble de validateurs de chaîne simplistes, comme vous pourriez éventuellement l'écrire pour vérifier l'entrée d'un utilisateur sur un formulaire dans une page Web ou pour vérifier le format d'un fichier de données fourni en externe.

Validateurs dans un seul fichier


Namespacing

Au fur et à mesure que nous ajoutons plus de validateurs, nous allons vouloir mettre en place une sorte d'organisation pour pouvoir garder une trace de nos types et ne pas nous inquiéter des conflits de noms avec d'autres objets. Au lieu de mettre beaucoup de noms différents dans l'espace de noms global, encapsulons nos objets dans un espace de noms.

Dans cet exemple, nous allons déplacer toutes les entités liées au validateur dans un espace de noms appelé 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


Séparer des fichiers

Au fur et à mesure que notre application grandit, nous souhaitons diviser le code en plusieurs fichiers pour en faciliter la maintenance.

Espaces de noms multi-fichiers

Ici, nous allons diviser notre espace 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

Une fois que plusieurs fichiers sont impliqués, nous devrons nous assurer que tout le code compilé est chargé. Il y a deux façons de le faire.

Tout d'abord, nous pouvons utiliser la sortie concaténée à l'aide de l'indicateur --outFile pour compiler tous les fichiers d'entrée en un seul fichier de sortie JavaScript :

Le compilateur ordonnera automatiquement le fichier de sortie en fonction des balises de référence présentes dans les fichiers. Vous pouvez également spécifier chaque fichier individuellement:

Alternativement, nous pouvons utiliser la compilation par fichier (valeur par défaut) pour émettre un fichier 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)


Alias

Une autre façon de simplifier l'utilisation des espaces de noms consiste à créer des noms plus courts pour les objets couramment utilisés 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.

Notez que nous n'utilisons pas le mot clé 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.

Travailler avec d'autres bibliothèques JavaScript

Pour décrire la forme des bibliothèques non écrites dans 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.

Nous appelons des déclarations qui ne définissent pas une implémentation "ambiante". Celles-ci sont généralement définies dans des fichiers .d.ts. Si vous connaissez C/C++, vous pouvez les considérer comme des fichiers .h.
Regardons quelques exemples.

Espaces de noms ambiants

La bibliothèque populaire 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é)