Как распространить модуль на несколько файлов AMD?

голоса
8

Я не могу понять, если это вообще возможно, чтобы иметь «экспортный модуль» распространяется accross несколько файлов.

Если у меня есть Contact.ts файлов:

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

и еще ContactView.ts

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

Тогда TSC не признают Контактный класс. Как вы можете видеть Контактный и ContactView объявлены проживать в том же модуле, и в соответствии со спецификацией он должен работать.

Я строй составного приложения, которое использует require.js и модель AMD, так что я должен использовать «экспортный модуль» декларацию.

Должен ли я сделать некоторый тип «впереди декларации» или каким-то хитрого «импорта»?

Благодарность за советом.

EDIT: В настоящее время я загружаю каждый модуль отдельно с помощью импорта, но, если вы заметите, что создает огромные потери коды и много «импортные» зависимостей. Мой вопрос был, если есть способ, чтобы использовать то же пространство имен (т.е. контактов), чтобы знать TS, что я не имею в виду, чтобы импортировать. Я смотрел в нормальную команду //, но она не работает. Я даже попробовал * .d.ts декларация файлы без успеха до сих пор.

Задан 08/10/2012 в 23:18
источник пользователем
На других языках...                            


2 ответов

голоса
6

Спецификация позволяет определить внутренние модули для нескольких файлов (в основном, внутренние модули относятся к яваскрипту шаблону модуля). Внешние модули, такие как модули AMD или CommonJS, работа на идее , что каждый файл является фактическим «модуль кода», и Пространства имен / имен в ней не имеет никакого значения , так как модуль будет загружен в собственный новый объект так или иначе.

Вы могли бы написать следующий код для загрузки модуля Contact.ts внутри модуля ContactView.ts:

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

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

И это должно работать достаточно хорошо, но если вы хотите иметь доступ к содержимому обоих модулей в другой области (к, например, сделать новый контакт моделирует себя), вам придется существенно импортировать оба из них:

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

Что я думаю, что это хорошо достаточно, потому что вы четко указав свою зависимость. Недостатком является то, что они не будут разделять общий родительский объект, поэтому иметь их оба в «Контакт» модуль-шаблон, вероятно, не очень полезны.

Другим вариантом является экспорт «Контакт» вместе с «ContactView», следующим образом (предоставляется этот код вроде глупо, потому что вы уже делаете точно, что с помощью модели свойство ContactView, но не менее ...):

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

    export var Contact = mod.Contacts.Contact;
}

Таким образом, вы сможете получить к нему доступ после загрузив ContactView.

EDIT: Кстати, вы не ограничены только экспортирующих модулей через «экспорт модуля Название {...}», вы можете экспортировать что-либо, как сам файл является модуль. Таким образом, вы можете иметь файл, который только имеет «функцию экспорта Foo () {...}» без какого-либо модуля шаблон упаковку его кода.

EDIT2: Похоже , что AMD может иметь функциональные возможности для загрузки нескольких зависимостей и построения «модулей» от тех, но я понятия не имею , как это будет работать в ТС, вот ссылка , которая идет над этим: http://www.adobe.com /devnet/html5/articles/javascript-architecture-requirejs-dependency-management.html (конструктор модулей).

Ответил 09/10/2012 в 02:21
источник пользователем

голоса
4

Я боролся с тем же вопросом на некоторое время, и просто хотел поделиться тем, что я делаю в случае, если кто-то бродит по этому вопросу.

Во-первых, я определил себе ссылочный файл, объявляющий все файлы в моем модуле:

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

Обратите внимание , что пути , указанные в файле являются относительно местоположения самого (эталонного файла _contacts.ts), в отличие от .jsэталонного файла. Моя структура каталогов выглядит следующим образом :

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

Назад к ссылке сам файл. Первая строка включает в себя отдельный справочный файл со списком всех внешних библиотек , используемых в модуле, например, подчеркивание, момента или любой другой существующей библиотеке у вас есть .d.tsфайл определение для. Остальные строки являются файлы, составляющие модуль.

Внутри каждый файл, который является частью модуля, я ссылаться на вышеуказанный файл:

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

Кроме того, вы можете создать единый справочный файл, чтобы перечислить все модули:

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

И просто указать на это из исходных файлов.

Это не решает проблему излучаемого кода, находящегося в отдельных файлах, хотя. Для этой проблемы я использую минификацию инструмент JavaScript, который способен пакетирование до нескольких файлов в один исходный файл. В зависимости от ваших настроек компиляции и потребностей сценариев использования, возможно, потребуется применить некоторые обертки вокруг сгенерированного кода для его работы в качестве модуля AMD (не слишком хорошо знаком с этой частью пока).

Ответил 13/12/2012 в 00:12
источник пользователем

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