Hoe te module over meerdere AMD-bestanden te verspreiden?

stemmen
8

Ik kan niet achterhalen of het zelfs mogelijk om een ​​export module hebben verspreid overkant van meerdere bestanden.

Als ik file Contact.ts:

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

en een ander ContactView.ts

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

Dan TSC is niet herkennen van de Contact klasse. Zoals je kunt zien het contact en de ContactView worden gedeclareerd in dezelfde module te verblijven en volgens de spec het zou moeten werken.

Ik ben het bouwen van een samengestelde toepassing die de require.js en AMD patronen gebruikt dus ik moet de export module verklaring gebruiken.

Moet ik doen een soort van voorsprong verklaring of een tricky import?

Bedankt voor het advies.

EDIT: Momenteel ben afzonderlijk laadt elke module via import, maar als je zult merken, het creëert een enorme verspilling van code en veel import afhankelijkheden. Mijn vraag was of er een manier is om dezelfde namespace (dwz Contactpersonen) te gebruiken om te laten weten de TS, dat bedoel ik niet importeren. Ik was op zoek naar de normale // commando, maar het werkt niet. Ik probeerde zelfs de * .d.ts verklaring bestanden zonder succes tot nu toe.

De vraag is gesteld op 08/10/2012 om 23:18
bron van user
In andere talen...                            


2 antwoorden

stemmen
6

De spec kunt u bepalen interne modules in meerdere bestanden (in wezen interne modules verwijzen naar de javascript module patroon). Externe modules, zoals AMD of CommonJS modules, werken aan het idee dat elk bestand is de eigenlijke "module van de code", en de namespacing / naamgeving binnen het is niet relevant, omdat de module in zijn eigen nieuwe object in ieder geval zal worden geladen.

Je zou de volgende code om de Contact.ts module binnenkant van de ContactView.ts module te laden schrijven:

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

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

En dat moet goed genoeg werken, maar als je wilde om de toegang tot de inhoud van beide modules hebben in een ander gebied (om bijvoorbeeld een nieuwe Contact model zelf), zou je in wezen zowel importeren van hen:

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

Waarvan ik denk dat goed genoeg is, omdat je met duidelijke vermelding van uw afhankelijkheden. Het nadeel is dat ze een gemeenschappelijk bovenliggend object zal niet delen, dus met hen beiden in een "Contact" module-patroon is waarschijnlijk niet van groot nut.

Een andere optie is om te exporteren "Contact" samen met "ContactView", als volgt (verleende deze code is een beetje dom, want je bent al precies dat te doen via het model eigendom van ContactView, maar nooit de minder ...):

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

    export var Contact = mod.Contacts.Contact;
}

Dus je zou in staat zijn om toegang te krijgen na ContactView te hebben geladen.

EDIT: By the way, bent u niet beperkt tot alleen het exporteren modules via "export module Name {...}", kun je alles exporteren als het bestand zelf is de module. Dus je zou een bestand dat alleen maar heeft "export functie foo () {...}", zonder enige module-patroon code te verpakken hebben.

EDIT2: Het lijkt erop dat AMD zou kunnen functionaliteit voor het laden van meerdere afhankelijkheden en de bouw van "modules" van die, maar ik heb geen idee hoe dat zou werken in TS, hier is een link die gaat over het volgende: http://www.adobe.com /devnet/html5/articles/javascript-architecture-requirejs-dependency-management.html (Constructor modules).

antwoordde op 09/10/2012 om 02:21
bron van user

stemmen
4

Ik worstelde met dezelfde vraag voor een tijdje, en wilde delen wat ik doe voor het geval dat iemand anders dwaalt over deze vraag.

Ten eerste, gedefinieerd ik mezelf een referentiebestand dat alle bestanden in mijn module verklaart:

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

Merk op dat paden opgegeven in het bestand zijn ten opzichte van de locatie van de referentie-bestand zelf ( _contacts.ts), in tegenstelling tot een .jsreferentiebestand. Mijn directory structuur ziet er als volgt uit:

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

Terug naar de referentie-zelf-bestand. De eerste regel heeft een aparte verwijzing bestand met alle van de externe bibliotheken gebruikt door de module, zoals underscore, moment of een andere bestaande bibliotheek u een hebt .d.tsdefinitie bestand voor. De overige lijnen zijn de bestanden die deel uitmaken van de module.

Binnen elk bestand dat deel uitmaakt van de module, ik verwijzen naar de bovenstaande file:

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

Op dezelfde manier kunt u één referentiebestand om alle modules te maken:

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

En gewoon wijzen op dit uit uw bronbestanden.

Dit betekent niet het probleem van de uitgezonden code die in afzonderlijke bestanden op te lossen, dat wel. Voor dat probleem Ik gebruik een JavaScript minification tool, die in staat is de bundeling van meerdere bestanden in een enkele bron bestand is. Afhankelijk van uw compilatie instellingen en use case nodig heeft, kan het nodig zijn om wat wrapper toe te passen rond de gegenereerde code voor het aan (nog niet te vertrouwd met dat deel) werken als een AMD-module.

antwoordde op 13/12/2012 om 00:12
bron van user

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