Using namespaces

This is the 27th day of my participation in the August Genwen Challenge.More challenges in August

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

But like other global namespace contamination, it can be 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 (such as CommonJs/require.js). This may not be necessary for small JS applications, but for large applications, this small cost can lead to long-term modularity and maintainability benefits. Modules also provide better code reuse, greater closure, and better use of tools for optimization.

Modules are the default and recommended way to organize code for Node.js applications.

As of ECMAScript 2015, modules are built into 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 pitfalls

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

Use with modules/// <reference>

A common mistake is to use ///

to reference a module file. Import should be used instead. To understand the difference, we should first understand how the compiler uses import paths (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 _ external module declarations _. 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 label 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 like this:

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

The top module Shapes wrap Triangle and Square. It’s confusing and annoying to the people who use it:

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

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

Again, you should not use namespaces for modules, they are used to provide logical grouping and avoid naming conflicts. The module file itself is already a logical grouping, and its name is specified by the code importing the module, so there is no need to add an additional module layer to the exported object.

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

Choice of modules

Just as every JS file corresponds to a module, module files in TypeScript correspond to generated JS files. 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 is commonJS or UMD, but outFile can be used when the target module is AMD or System in TypeScript 1.8 and later.