Comment étendre le module sur plusieurs fichiers AMD?

voix
8

Je ne peux pas savoir s'il même possible d'avoir une répartition « module d'exportation » accross plusieurs fichiers.

Si je Contact.ts fichier:

// file Contact.ts
export module Contacts {
   export class Contact {
      ...
   }
}

et un autre ContactView.ts

// file ContactView.ts
export module Contacts {
   export class ContactView {
      model: Contact;  // <---  is not recognized
   }
}

Ensuite TSC ne reconnaît pas la classe de contact. Comme vous pouvez le voir le contact et la ContactView sont déclarées à résider dans le même module et selon les spécifications, il devrait fonctionner.

Je construis une application composite qui utilise les require.js et les modèles AMD, donc je dois utiliser la déclaration « du module d'exportation ».

Dois-je faire un certain type de « déclaration d'avance » ou une « importation » délicate?

Merci pour les conseils.

EDIT: Actuellement, je charge chaque module séparément via l'importation, mais, si vous remarquez, il crée un énorme gaspillage de code et beaucoup de dépendances « d'importation ». Ma question était de savoir s'il y a un moyen d'utiliser le même espace de noms (c.-à-contacts) pour faire savoir le TS que je ne veux pas importer. Je regardais dans la commande normale //, mais il ne fonctionne pas. J'ai même essayé les fichiers de déclaration du * sans succès jusqu'à présent.

Créé 08/10/2012 à 23:18
source utilisateur
Dans d'autres langues...                            


2 réponses

voix
6

La spécification permet de définir internes des modules dans plusieurs fichiers (en substance, modules internes font référence au modèle du module javascript). Externes modules, tels que des modules AMD ou CommonJS, le travail sur l'idée que chaque fichier est le « module de code » réel et l'espace de nommage / nommer en son sein est sans objet puisque le module sera chargé dans son propre nouvel objet de toute façon.

Vous pouvez écrire le code suivant pour charger le module Contact.ts à l'intérieur du module ContactView.ts:

// file ContactView.ts    
import mod = module("./Contact");

export module Contacts {
   export class ContactView {
      model: mod.Contacts.Contact;  // <---  will be recognized
   }
}

Et cela devrait fonctionner assez bien, mais si vous voulez avoir accès au contenu des deux modules dans un autre domaine (par exemple à faire un nouveau modèle de contact vous), vous devez importer essentiellement deux d'entre eux:

import c = module("./Contact");
import cv = module("./ContactView");

Je pense que ce qui est assez bien, parce que vous indiquant clairement vos dépendances. L'inconvénient est que ils l'habitude de partager un objet parent commun, afin de les avoir à la fois être dans un module motif « Contact » est probablement pas d'une grande utilité.

Une autre option consiste à exporter « Contact » et « ContactView », comme suit (accordée ce code est un peu bête parce que vous faites déjà exactement cela via la propriété modèle de ContactView, mais jamais moins ...):

export module Contacts {
   export class ContactView {
       model: mod.Contacts.Contact;
       constructor() {
           this.model = new mod.Contacts.Contact();
       }
    }

    export var Contact = mod.Contacts.Contact;
}

Donc, vous seriez en mesure d'y accéder après avoir chargé ContactView.

EDIT: D'ailleurs, vous n'êtes pas limité à seulement exportateurs via des modules « Nom du module d'exportation {...} », vous pouvez exporter quoi que ce soit que le fichier lui-même est le module. Donc, vous pourriez avoir un fichier qui a juste « fonction d'exportation foo () {...} » sans code module modèle enveloppant.

EDIT2: Il semble que AMD pourrait avoir des fonctionnalités pour charger plusieurs dépendances et la construction de « modules » de ceux -ci , mais je ne sais pas comment cela pourrait fonctionner dans TS, voici un lien qui va plus que: http://www.adobe.com /devnet/html5/articles/javascript-architecture-requirejs-dependency-management.html (modules de constructeur).

Créé 09/10/2012 à 02:21
source utilisateur

voix
4

Je me suis battu avec la même question pendant un certain temps, et je voulais juste partager ce que je fais au cas où quelqu'un d'autre vagabonde à travers cette question.

Tout d'abord, je me suis défini un fichier de référence qui déclare tous les fichiers dans mon module:

/// <reference path="_contacts.dependencies.ts" />
/// <reference path="../contacts/Contact.ts" />
/// <reference path="../contacts/ContactView.ts" />
/// <reference path="../contacts/ContactModel.ts" />

Notez que les chemins spécifiés dans le fichier sont liés à l'emplacement du fichier lui - même de référence ( _contacts.ts), contrairement à un .jsfichier de référence. Ma structure de répertoire ressemble à ceci:

modules
    references // all of the reference files
        knockout 
        underscore
        // ... a subfolder for every 3rd party library used
    contacts
    commerce 
    // ... other modules at same level as contacts

Retour à la référence elle-même fichier. La première ligne comprend un fichier de référence distincte énumérant toutes les bibliothèques externes utilisées par le module, comme underscore, le moment ou toute autre bibliothèque existante vous avez une.d.ts fichier de définition pour. Les lignes restantes sont les fichiers qui composent le module.

A l'intérieur de chaque fichier qui fait partie du module, je référence le fichier ci-dessus:

/// <reference path="../references/_contacts.ts" />
module Contacts {
    export class Contact { 
        public model: ContactModel;
        // ...
    }
} 

De même, vous pouvez créer un seul fichier de référence à la liste de tous vos modules:

/// <reference path="_address.ts" />
/// <reference path="_contacts.ts" />
/// <reference path="_commerce.ts" />

Et simplement pointer vers ce à partir de vos fichiers source.

Cela ne résout pas le problème du code émis étant dans des fichiers séparés, cependant. Pour ce problème, je me sers d'un outil minification JavaScript, qui est capable de regrouper des fichiers multiples en un seul fichier source. En fonction de vos paramètres de compilation et les besoins de cas d'utilisation, vous devrez peut-être appliquer une enveloppe autour du code généré pour que cela fonctionne comme un module AMD (pas trop familier avec cette partie encore).

Créé 13/12/2012 à 00:12
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more