2016-02-05 2 views
0

Я пытаюсь расширить абстрактный класс до другого класса, но для большего удобства мне нужен этот абстрактный класс в другом файле. К сожалению, это бросает мне ошибку времени выполнения, которую я изо всех сил пытаюсь понять.Унаследованный класс от другого модуля в Typcript

Это работает:

abstract class Item{ 
    constructor(){ 
     console.log("I am an Item"); 
    } 
} 

export class Folder extends Item{ 
    constructor(){ 
     super(); 
    } 
} 

Вход:

I am an Item 

Это не:

module MyModule{ 
    export abstract class Item{ 
     constructor(){ 
      console.log("I am an Item"); 
     } 
    } 
} 

export class Folder extends MyModule.Item{ 
    constructor(){ 
     super(); 
    } 
} 

Собирает но бросает:

Uncaught TypeError: Cannot read property 'prototype' of undefined 

Кто-нибудь понимает, что происходит?

+0

Проблема кажется, происходит от экспорта абстрактного класса. Решение, которое я только что нашел, было бы объявить var, который укажет на этот абстрактный класс: export var ItemClass = Item; затем: класс экспорта Папка расширяет MyModule.ItemClass; Это похоже на действующее обходное решение? – Kromah

ответ

0

Экспорт верхнего уровня (export class Folder в данном случае) в исходном файле означает, что TypeScript будет обрабатывать файл как внешний модуль, хотя если вы не укажете формат модуля при компиляции TypeScript, должен был испускаться error TS1148: Cannot compile modules unless the '--module' flag is provided. Итак, я несколько смутили то, как вам удалось скомпилировать эти фрагменты кода вообще, если вы используете только внутренние модули.

Я бы настоятельно рекомендовал использовать внешние модули (где каждый файл .ts сам по себе является модулем) и полностью избегать пространств имен (ранее называемых внутренними модулями).

Вот что ваш код будет выглядеть ничего, кроме внешних модулей:

// mymodule.ts 
export abstract class Item { 
    constructor() { 
    console.log("I am an Item"); 
    } 
} 

// folder.ts 
import * as MyModule from './mymodule'; 

export class Folder extends MyModule.Item { 
    constructor() { 
    super(); 
} 

Однако, если вы хотите придерживаться использования пространств имен вместо этого, вы могли бы сделать это:

namespace MyModule { 
    export abstract class Item { 
    constructor() { 
     console.log("I am an Item"); 
    } 
    } 
} 

namespace MyOtherModule { 
    export class Folder extends MyModule.Item { 
    constructor() { 
     super(); 
    } 
    } 
} 
+0

Большое спасибо за ваш ответ. Это действительно работает, но разве это разумный выбор? Мой проект ts содержит много файлов, организованных с помощью внутренних модулей. Импортирование всего как внешнего модуля вместо этого кажется сумасшедшей работой. И согласно http://typescript.codeplex.com/wikipage?title=Modules%20in%20TypeScript&referringTitle=TypeScript%20Documentation, «Внешние модули используются в двух случаях: node.js и require.js. Приложения, не использующие node.js или require.js не нужно использовать внешние модули и лучше всего организовать с использованием концепции внутреннего модуля, описанной выше ». Как вы думаете? – Kromah

+0

@Kromah Этот конкретный совет датирован, я считаю, что в наши дни консенсус заключается в использовании внешних модулей с модульным пакетом (если вы хотите объединить все в один или несколько файлов). Тем не менее, я расширил свой ответ, чтобы охватить подход пространства имен. FYI TypeScript перешел из CodePlex в Github некоторое время назад, и этот конкретный раздел документов теперь можно найти в [справочнике] (http://www.typescriptlang.org/Handbook), который также несколько устарел, есть пара страниц в Wiki, в которых описываются основные изменения каждой версии TypeScript. –

Смежные вопросы