Come diffondere modulo in più file di AMD?

voti
8

Non riesco a capire se è ancora possibile avere un modulo di esportazione spread attraversato più file.

Se ho Contact.ts di file:

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

e un altro ContactView.ts

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

Poi TSC non riconosce la classe Contact. Come si può vedere il contatto e la ContactView sono dichiarati a risiedere nello stesso modulo e secondo le specifiche dovrebbe funzionare.

Sto costruendo un'applicazione composita che utilizza le require.js e modelli AMD quindi devo utilizzare la dichiarazione modulo di esportazione.

Dovrei fare un certo tipo di dichiarazione avanti o qualche importazione ingannevole?

Grazie per i consigli.

EDIT: Attualmente passo per caricare ogni modulo separatamente tramite l'importazione, ma, se si noterà, si crea un enorme spreco di codice e molte dipendenze importazione. La mia domanda era se c'è un modo per utilizzare lo stesso spazio dei nomi (ad esempio contatti) per far conoscere la TS che non intendo importare. Stavo guardando nel comando normale //, ma non funziona. Ho anche provato il * .d.ts file di dichiarazione senza successo finora.

È pubblicato 08/10/2012 alle 23:18
fonte dall'utente
In altre lingue...                            


2 risposte

voti
6

Le specifiche consente di definire interne moduli in più file (in sostanza, moduli interni si riferiscono al modello del modulo JavaScript). Esterni moduli, come AMD o CommonJS moduli, il lavoro sull'idea che ogni file è il "Modulo di codice" vero e proprio, e la namespacing / denominazione all'interno di esso è irrilevante, poiché il modulo sarà caricato nel proprio nuovo oggetto comunque.

Si potrebbe scrivere il seguente codice per caricare il modulo Contact.ts interno del modulo ContactView.ts:

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

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

E che dovrebbe funzionare abbastanza bene, ma se si voleva avere accesso ai contenuti di entrambi i moduli in un'altra zona (per esempio, per fare un nuovo modello di contatto te stesso), che avrebbe dovuto importare essenzialmente entrambi:

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

Che credo sia bene abbastanza, perché si sta chiaramente indicando le dipendenze. Il rovescio della medaglia è che si suole condividono un oggetto padre comune, in modo da avere tutti e due in una "Contatto" modulo-modello probabilmente non è di grande utilità.

Un'altra opzione è quella di esportare "Contatto" insieme a "ContactView", come segue (concesso questo codice è una specie di stupido, perché si sta già facendo esattamente che tramite la proprietà del modello di ContactView, ma mai meno ...):

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

    export var Contact = mod.Contacts.Contact;
}

Così si sarebbe in grado di accedervi dopo aver caricato ContactView.

EDIT: A proposito, non si è limitato ai moduli solo esportatori tramite "modulo di esportazione Nome {...}", è possibile esportare nulla come il file stesso è il modulo. Così si potrebbe avere un file che ha appena "funzione di esportazione foo () {...}" senza alcun codice del modulo-modello avvolgendolo.

EDIT2: Sembra che AMD potrebbe avere funzionalità per il caricamento di più dipendenze e costruire "moduli" da quelli, ma non ho idea di come dovrebbe funzionare in TS, ecco un link che va oltre che: http://www.adobe.com /devnet/html5/articles/javascript-architecture-requirejs-dependency-management.html (moduli costruttore).

Risposto il 09/10/2012 a 02:21
fonte dall'utente

voti
4

Ho lottato con la stessa domanda per un po ', e volevo solo condividere quello che sto facendo nel caso in cui nessun altro vaga attraverso questa domanda.

In primo luogo, io stesso ho definito un file di riferimento che dichiara tutti i file nel mio modulo:

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

Si noti che i percorsi specificati all'interno del file sono relativi alla posizione del file di riferimento in sé ( _contacts.ts), a differenza di un .jsfile di riferimento. La mia struttura di directory simile a questo:

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

Torna il riferimento al file stesso. La prima linea comprende un file di riferimento separata che elenca tutte le librerie esterne utilizzate dal modulo, come sottolineatura, momento o qualsiasi altra libreria esistente si dispone di un .d.tsfile di definizione per il. Le linee rimanenti sono i file che compongono il modulo.

All'interno di ogni file che è parte del modulo, mi riferimento al file di cui sopra:

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

Allo stesso modo, è possibile creare un file di riferimento unico per elencare tutti i moduli:

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

E semplicemente puntare a questo dai file di origine.

Questo non risolve il problema del codice emesso essendo in file separati, però. Per questo problema che sto utilizzando uno strumento di minimizzazione JavaScript, che è in grado di bundling up più file in un singolo file sorgente. A seconda delle impostazioni di compilazione e le esigenze dei casi d'uso, potrebbe essere necessario applicare alcuni wrapper per il codice generato per farlo funzionare come modulo AMD (non troppo familiare con quella parte ancora).

Risposto il 13/12/2012 a 00:12
fonte dall'utente

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