Typescript的官方网站让我问一个问题，“我们是否需要使用名称空间？”。
以下引用很好地解释了两件事：
重要的是要注意，在TypeScript 1.5中，术语已更改。“内部模块”现在是“命名空间”。为了与ECMAScript 2015的术语保持一致，“外部模块”现在仅是“模块”（即，模块X {等同于现在首选的命名空间X {）。
因此，他们建议TS团队更喜欢命名空间。此外，它说我们应该使用“命名空间”来构造内部模块：
这篇文章概述了使用TypeScript中的名称空间（以前称为“内部模块”）组织代码的各种方法。正如我们在有关术语的注释中提到的那样，“内部模块”现在称为“命名空间”。另外，在声明内部模块时，在使用module关键字的任何地方，可以而且应该改用namespace关键字。这样可以避免通过给新用户添加名称相似的术语来使新用户感到困惑。
上面的引文全部来自“命名空间”部分，是的，它再次说了，只是在内部结构上。
但在模块部分的一段中说：
从ECMAScript 2015开始，模块是语言的本机部分，所有兼容的引擎实现均应支持这些模块。因此，对于新项目，模块将是推荐的代码组织机制。
这是否意味着我不需要打扰命名空间，始终使用模块是建议的开发方式？
这是否意味着我不需要打扰命名空间，始终使用模块是建议的开发方式？
我不会这么说...这是发生的另一种解释。曾经有一次，Typescript中使用了两个术语
随着Ecmascript 2015（又名ES6）的到来，它添加了一种新的正式，标准格式，该格式属于“外部模块”类别。由于此更改，Typescript希望更改术语以匹配新的Javascript标准（因为它喜欢是Javascript的超集，并尽最大努力避免使来自Javascript的用户感到困惑）。因此，“外部模块”的切换简化为仅“模块”，而“内部模块”的重命名为“命名空间”。
您在这里找到的报价：
从ECMAScript 2015开始，模块是语言的本机部分，所有兼容的引擎实现均应支持这些模块。因此，对于新项目，模块将是推荐的代码组织机制。
可能暗示了针对尚未使用（外部）模块的用户的指导。至少现在考虑使用它。但是，由于截至2016年5月的浏览器没有内置的模块加载器，因此对ES6模块的支持仍然不完整。因此，您必须添加一个诸如RequireJS或SystemJS的polyfill（在运行时处理它），或者添加一个在构建时（在部署到您的网站之前）对其进行处理的捆绑器（例如browserify或webpack）。
因此，您是否会同时使用模块（以前称为“外部模块”）和名称空间？绝对-我在代码库中经常使用它们。我使用（外部）模块来组织我的代码文件。
Typescript中的命名空间非常有用。具体来说，我使用名称空间声明合并作为一种类型安全的方式来向函数对象本身添加额外的属性（JS中经常使用的一种模式）。另外，尽管名称空间很像常规对象变量，但是您可以将子类型（嵌套接口，类，枚举等）挂在其名称之外。
这是带有属性的函数的示例（在NodeJS库中很常见）：
function someUsefulFunction() {
// asynchronous version
return ...; // some promise
}
namespace someUsefulFunction {
export function sync() {
// synchronous version
}
}
这使消费者可以执行以下常见的NodeJS模式：
// asynchronous consumer
someUsefulFunction()
.then(() => {
// ...
});
// synchronous consumer
someUsefulFunction.sync();
同样，假设您有一个接受选项对象的API。如果该选项类型特定于该API，
function myFunc(options?: myFunc.Options) {
// ...
}
namespace myFunc {
export interface Options {
opt1?: number;
opt2?: boolean;
opt3?: string;
}
}
在这种情况下，您不必使用选项的类型声明来污染更大的名称空间（例如整个模块范围）。
希望这可以帮助！
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句