Introduction

Cet article décrit les différentes façons d'organiser votre code à l'aide d'espaces de nommage et de modules dans TypeScript. Nous allons également passer en revue des sujets avancés sur l'utilisation des espaces de noms et des modules, ainsi que sur des pièges courants lors de leur utilisation dans TypeScript.

Consultez la documentation sur les modules pour plus d'informations sur les modules. Voir la documentation sur les espaces de noms pour plus d'informations sur les espaces de noms.

Utiliser les espaces de noms

Les espaces de noms sont simplement nommés objets JavaScript dans l'espace de noms global. Cela fait des espaces de noms une construction très simple à utiliser. Ils peuvent s'étendre sur plusieurs fichiers et peuvent être concaténés à l'aide de --outFile. Les espaces de noms peuvent être un bon moyen de structurer votre code dans une application Web. Toutes les dépendances sont incluses sous forme de ‹script› balises dans votre page HTML.

Comme pour toute la pollution globale des espaces de noms, il peut être difficile d'identifier les dépendances des composants, en particulier dans une application volumineuse.

Utilisation de modules

Tout comme les espaces de noms, les modules peuvent contenir du code et des déclarations. La principale différence est que les modules déclarent leurs dépendances.

Les modules ont également une dépendance sur un chargeur de module (tel que CommonJs / Require.js). Pour une petite application JS, cela peut ne pas être optimal, mais pour de plus grandes applications, le coût vient avec des avantages de modularité et de maintenabilité à long terme. Les modules permettent une meilleure réutilisation du code, une isolation renforcée et un meilleur support des outils pour le regroupement.

Il convient également de noter que, pour les applications Node.js, les modules sont l'approche par défaut et l'approche recommandée pour structurer votre code.

à partir de ECMAScript 2015, les modules font partie intégrante du langage et devraient être pris en charge par toutes les implémentations de moteurs conformes. Ainsi, pour les nouveaux projets, les modules seraient le mécanisme d'organisation du code recommandé.

Pièges des espaces de noms et des modules

Dans cette section, nous décrivons divers pièges courants liés à l'utilisation d'espaces de nommage et de modules, ainsi que la manière de les éviter.

/// ‹reference›-ing un module

Une erreur courante consiste à utiliser la syntaxe /// ‹reference ... /› pour faire référence à un fichier de module, plutôt que d'utiliser une instruction import. Pour comprendre la distinction, nous devons d'abord comprendre comment le compilateur peut localiser les informations de type d'un module en fonction du chemin d'un chemin import (par exemple , ...in import x from "..."; , import x = require("..."); etc.)...

Le compilateur essaiera de trouver un .ts, .tsx puis un .d.ts avec le chemin approprié. Si un fichier spécifique est introuvable, le compilateur recherchera une déclaration de module ambiante. Rappelons que ceux-ci doivent être déclarés dans un fichier .d.ts.

myModules.d.ts

myOtherModule.ts

La balise de référence ici nous permet de localiser le fichier de déclaration contenant la déclaration du module ambient. Voici comment le fichier node.d.ts utilisé par plusieurs exemples TypeScript est utilisé.

Nom de domaine inutile

Si vous convertissez un programme d'espaces de noms en modules, il peut être facile de vous retrouver avec un fichier qui ressemble à ceci :

shapes.ts

Le module de niveau supérieur ici Shapes enveloppe Triangle et Square sans aucune raison. Ceci est déroutant et gênant pour les utilisateurs de votre module :

shapeConsumer.ts

Une caractéristique clé des modules dans TypeScript est que deux modules différents ne contribueront jamais à des noms du même domaine. étant donné que le consommateur d'un module décide du nom à lui attribuer, il n'est pas nécessaire d'encapsuler de manière proactive les symboles exportés dans un espace de noms.

Pour rappeler pourquoi vous ne devriez pas essayer d'espacer le contenu de votre module en espace de noms, l'idée générale est de fournir un regroupement logique des constructions et d'éviter les conflits de noms. Comme le fichier de module lui-même constitue déjà un groupe logique et que son nom de niveau supérieur est défini par le code qui l'importe, il est inutile d'utiliser une couche de module supplémentaire pour les objets exportés.

Voici un exemple révisé :

shapes.ts

shapeConsumer.ts

Compromis des modules

Tout comme il existe une correspondance un à un entre les fichiers JS et les modules, TypeScript dispose d'une correspondance un à un entre les fichiers source du module et les fichiers JS qu'ils émettent. Cela a notamment pour effet qu'il est impossible de concaténer plusieurs fichiers source de module en fonction du système de module que vous ciblez. Par exemple, vous ne pouvez pas utiliser l'option outFile pendant le ciblage commonjs ou umd, mais avec TypeScript 1.8 et versions ultérieures, il est possible de l'utiliser outFile lorsque vous ciblez amd ou system.