Welcome to wechat Public account: Front Reading Room

A quick note on terminology: It’s important to note that terms have changed in TypeScript 1.5. “Internal modules” are now called “namespaces.” “External modules” are now referred to simply as “modules” to be consistent with ECMAScript 2015 terminology (that is, module X {is equivalent to the now recommended namespace X {).

introduce

This article will give you an overview of how to use modules and namespaces to organize code in TypeScript. We’ll also cover advanced usage scenarios for namespaces and modules, and common pitfalls in using them.

Using namespaces

A namespace is a plain JavaScript object with a name that is located under the global namespace. This makes namespaces very easy to use. They can be used in multiple files simultaneously and are combined by –outFile. Namespaces are a great way to organize your Web application. You can put all your dependencies in

But like other global namespace pollutions, it is difficult to identify dependencies between components, especially in large applications.

Use the module

Like namespaces, modules can contain code and declarations. The difference is that a module can declare its dependencies.

Modules add dependencies to module loaders (for example, CommonJs/require.js). This may not be necessary for a small JS application, but for a large application, this small cost will result in a long term modularity and maintainability benefit. Modules also provide better code reuse, greater closure, and better tooling optimization.

Modules are the default and recommended way of organizing code for node.js applications.

As of ECMAScript 2015, modules are a built-in part of the language and should be supported by all normal interpretation engines. Therefore, modules are recommended as a way to organize code for new projects.

Namespaces and module traps

In this section we describe common namespaces and module usage pitfalls and how to avoid them.

Using modules/// <reference>

A common mistake is to use ///

to reference a module file. You should use import instead. To understand the difference, we should first understand how the compiler works according to the import path (for example, import x from “…”). ; Import x = require(“…”) ) Inside… , etc.) to locate module type information.

The compiler first tries to find.ts,.tsx, or.d.ts in the corresponding path. If none of these files are found, the compiler looks for the external module declaration. Recall that they were declared in the.D.ts file.

myModules.d.ts

// In a .d.ts file or .ts file that is not a module:
declare module "SomeModule" {
    export function fn() :string;
}
Copy the code

myOtherModule.ts

/// <reference path="myModules.d.ts" />
import * as m from "SomeModule";
Copy the code

The reference tag here specifies the location of the foreign module. This is how some TypeScript examples refer to Node.d. ts.

Unnecessary namespaces

If you want to convert a namespace to a module, it might look something like this:

shapes.ts

export namespace Shapes {
    export class Triangle { / *... * / }
    export class Square { / *... * /}}Copy the code

The top layer module Shapes wraps around Triangle and Square. It’s confusing and annoying for people who use it:

shapeConsumer.ts

import * as shapes from "./shapes";
let t = new shapes.Shapes.Triangle(); // shapes.Shapes?
Copy the code

One of the things about modules in TypeScript is that different modules never use the same name in the same scope. Because the people who use the modules name them, there is absolutely no need to wrap the exported symbols in a namespace.

Again, namespaces should not be used for modules; they are used to provide logical grouping and to avoid naming conflicts. The module file itself is already a logical grouping, and its name is specified by the code that imports the module, so there is no need to add an extra module layer to the exported objects.

Here are some examples of improvements:

shapes.ts

export class Triangle { / *... * / }
export class Square { / *... * / }
Copy the code

shapeConsumer.ts

import * as shapes from "./shapes";
let t = new shapes.Triangle();
Copy the code

Module selection

Just as each JS file corresponds to a module, module files in TypeScript correspond to generated JS files one to one. This has the effect that depending on the target module system you specify, you may not be able to connect to multiple module source files. For example, the outFile option cannot be used when the target module system is CommonJS or UMD, but can be used in TypeScript 1.8 or later when the target is AMD or system.

Welcome to wechat Public account: Front Reading Room