typescript 命名空间和模块.pdfVIP

TypeScript 命名空间和模块 TypeScript命名空间和模块 关于术语的⼀点说明: 请务必注意⼀点，TypeScript 1.5⾥术语名已经发⽣ 了变化。 “ 内部模块”现在称做“命名空间” 。 “ 部模块”现在则简称为“模 块” ，这是为了与 ECMAScript 20 15⾥的术语保持⼀致，(也就是说 module X {相当于现在推荐的写法 namespace X {) 。 介绍 这篇⽂章将概括介绍在TypeScript⾥使⽤模块与命名空间来组织代码的⽅法。 我们也 会谈及命名空间和模块的⾼级使⽤场景，和在使⽤它们的过程中常见的陷阱。 查看模块章节了解关于模块的更多信息。 查看 命名空间章节了解关于命名空间的更 多信息。 使⽤命名空间 命名空间是位于全局命名空间下的⼀个普通的带有名字的JavaScript对象。 这令命名 空间⼗分容易使⽤。 它们可以在多⽂件中同时使⽤，并通过 --outFile结合在⼀ 起。 命名空间是帮你组织Web应⽤不错的⽅式，你可以把所有依赖都放在HTML页⾯ 的 script标签⾥。 但就像其它的全局命名空间污染⼀样，它很难去识别组件之间的依赖关系，尤其是在 ⼤型的应⽤中。 使⽤模块 像命名空间⼀样，模块可以包含代码和声明。 不同的是模块可以 声明它的依赖。 模块会把依赖添加到模块加载器上 （例如Co onJs / Require .j s ）。 对于⼩型的JS应 ⽤来说可能没必要，但是对于⼤型应⽤，这⼀点点的花费会带来长久的模块化和可维 护性上的便利。 模块也提供了更好的代码重⽤，更强的封闭性以及更好的使⽤⼯具进 ⾏优化。 对于Node .j s应⽤来说，模块是默认并推荐的组织代码的⽅式。 从ECMAScript 20 15开始，模块成为了语⾔内置的部分，应该会被所有正常的解释引 擎所⽀持。 因此，对于新项⽬来说推荐使⽤模块做为组织代码的⽅式。 命名空间和模块的陷阱 这部分我们会描述常见的命名空间和模块的使⽤陷阱和如何去避免它们。 对模块使⽤/// reference ⼀个常见的错误是使⽤/// reference引⽤模块⽂件，应该使⽤import。 要理 解这之间的区别，我们⾸先应该弄清编译器是如何根据 import路径 （例 如，import x from ...;或import x = require(...)⾥⾯的...，等 等）来定位模块的类型信息的。 编译器⾸先尝试去查找相应路径下的.ts，.tsx再或者.d.ts。 如果这些⽂件都找 不到，编译器会查找 部模块声明。 回想⼀下，它们是在 .d.ts⽂件⾥声明的。 m Modules.d.ts // In a .d.ts file or .ts file that is not a module: declare module SomeModule { export function fn(): string; } m OtherModule.ts /// reference path=m Modules.d.ts / import * as m from SomeModule; 这⾥的引⽤标签指定了 来模块的位置。 这就是⼀些Typescript例⼦中引 ⽤ node.d.ts的⽅法。 不必要的命名空间 如果你想把命名空间转换为模块，它可能会像下⾯这个⽂件⼀件： shapes.ts export namespace Shapes { export class Triangle { /* ... */ } export class Square { /* ... */ } } 顶层的模块Shapes包裹了Triangle和Square。 对于使⽤它的⼈来说这是令⼈迷惑 和讨厌的： shapeConsumer.ts import * as shapes from ./shapes; let t = new shapes.Shapes.Triangle(); // shapes.Shapes? TypeScript⾥模块的⼀个特点是不同的模块永远也不会在相同的作⽤域内使⽤相同的 名字。 因为使⽤模块的⼈会为它们命名，所以完全没有必要把导出的符号包裹在⼀个 命名空间⾥。 再次重申，不应该对模块使⽤命名空间，使⽤命名空间是为了提供