Cum să se răspândească modul în mai multe fișiere AMD?

voturi
8

Nu pot să dau seama dacă este chiar posibil de a avea un „modul de export“, răspândit pe mai multe fișiere.

Dacă am Contact.ts fișier:

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

și un alt ContactView.ts

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

Atunci TSC nu recunoaște clasa de contact. După cum puteți vedea contactul și ContactView sunt declarate de a locui în același modul și în conformitate cu spec ar trebui să funcționeze.

Construiesc o aplicație compozit care utilizează require.js și modelele AMD așa că am să utilizeze „modulul de export“ declarație.

Ar trebui să fac un anumit tip de „declarație înainte“ sau unele complicat „de import“?

Multumesc pentru sfatul.

EDIT: In prezent am incarca fiecare modul separat prin import, dar, dacă veți observa, se creează o risipă enormă de cod și mulțime de dependențe „de import“. Întrebarea mea a fost dacă există o modalitate de a utiliza același spațiu de nume (de exemplu Contacte) pentru a înștiința TS că eu nu vreau să import. M-am uitat în comanda normală //, dar aceasta nu funcționează. Am încercat chiar * .d.ts fișiere cu declarații fără succes până în prezent.

Întrebat 08/10/2012 la 23:18
sursa de către utilizator
În alte limbi...                            


2 răspunsuri

voturi
6

Spec vă permite să definiți interne module în mai multe fișiere (în esență, module interne se referă la modelul de modul JavaScript). Externe module, cum ar fi module AMD sau CommonJS, lucru pe ideea că fiecare fișier este real „modulul de cod“, și spațiu de nume / denumire în cadrul acestuia este lipsită de relevanță , deoarece modulul va fi încărcat în propriul său obiect nou , oricum.

Ai putea scrie următorul cod pentru a încărca modulul Contact.ts în interiorul modulului ContactView.ts:

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

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

Și asta ar trebui să funcționeze destul de bine, dar dacă ai vrut să aibă acces la conținutul ambelor module într-o altă zonă (de exemplu, pentru a face un nou model de contact le), va trebui să importe, în esență, ambele dintre ele:

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

Ceea ce cred că este bine suficient, pentru că sunteți în mod clar care să ateste dependențele tale. Dezavantajul este că ei nu va distribui un obiect părinte comun, astfel încât să le având amândoi să fie într-un „Contact“ Modul-model, probabil, nu este de mare folos.

O altă opțiune este de a exporta „Contact“, împreună cu „ContactView“, după cum urmează (a acordat acest cod este un fel de prostie pentru că faci deja exact prin modelul proprietatea ContactView, dar niciodată mai puțin ...):

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

    export var Contact = mod.Contacts.Contact;
}

Deci, ai putea accesa după ce a încărcat ContactView.

EDIT: Apropo, nu sunt limitate la module numai exportul produselor prin intermediul „modul de export Nume {...}“, puteți exporta nimic ca fișierul în sine este modulul. Deci, ai putea avea un fișier care are doar „foo funcția de export () {...}“ fără nici un cod de modul de model de ambalaj-l.

EDIT2: Se pare ca AMD poate avea o funcționalitate pentru încărcarea mai multe dependențe și construirea „module“ de cele, dar nu am nici o idee cum că ar lucra în TS, aici este un link care trece peste asta: http://www.adobe.com /devnet/html5/articles/javascript-architecture-requirejs-dependency-management.html (modulele constructorului).

Publicat 09/10/2012 la 02:21
sursa de către utilizator

voturi
4

M-am luptat cu aceeași întrebare pentru un timp, și a vrut doar să împărtășească ceea ce fac, în cazul în care oricine altcineva rătăcește peste această întrebare.

În primul rând, m-am definit un fișier de referință care declară toate fișierele din modul meu:

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

Rețineți că căile specificate în interiorul fișierului sunt relativ la locația fișierului de referință în sine ( _contacts.ts), spre deosebire de un .jsfișier de referință. Structura mea director arata ca acest lucru:

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

Înapoi la referința în sine fișier. Prima linie include un fișier de referință separat listarea toate bibliotecile externe utilizate de către modulul, cum ar fi subliniere, momentul sau orice altă bibliotecă existentă aveți un .d.tsfișier de definiție pentru. Liniile rămase sunt fișierele care alcătuiesc modulul.

În interiorul fiecare fișier care este o parte a modulului, am referire la un fișier de mai sus:

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

În mod similar, puteți crea un singur fișier de referință pentru a lista toate modulele:

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

Și pur și simplu indică acest lucru de la fișierele sursă.

Acest lucru nu rezolvă problema codului emis fiind în fișiere separate, totuși. Pentru aceasta problema eu sunt, folosind un instrument de minification JavaScript, care este capabil de balotare până mai multe fișiere într-un singur fișier sursă. În funcție de setările de compilare și de nevoile de utilizare de caz, poate fi necesar să se aplice unele înveliș în jurul codul generat pentru a funcționa ca un modul AMD (nu prea familiarizat cu acea parte încă).

Publicat 13/12/2012 la 00:12
sursa de către utilizator

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