关于前端:Angular-模块封装概念常见的错误理解

Angular 以相似于 ES 模块的形式引入了模块封装的概念。它基本上意味着可申明的类型——组件、指令和管道——只能由在该模块内申明的组件应用。例如，如果我尝试应用上面的代码在 App 模块的 App 组件内应用 A 模块中的 a-comp：

@Component({
  selector: 'my-app',
  template: `
      <h1>Hello {{name}}</h1>
      <a-comp></a-comp>
  `
})
export class AppComponent {}

会收到这个谬误音讯：

Template parse errors:‘a-comp’is not a known element

这是因为 App 模块中没有申明 a-comp。如果我想应用这个组件，我须要导入定义这个组件的模块。解决方案如下：

@NgModule({imports: [..., AModule]
})
export class AppModule {}

这就是封装发挥作用的中央：A 模块必须通过将 a-comp 增加到 exports 数组来将其申明为在其余 module 内可用：

@NgModule({
  ...
  declarations: [AComponent],
  exports: [AComponent]
})
export class AModule {}

大多数 Angular 老手认为 Providers 也有封装，这种想法是谬误的。能够在应用程序内的任何地位拜访在任何非提早加载模块中申明的 Providers.

Modules hierarchy

对于 imported modules 的最大困惑是开发人员认为这些被导入的 Modules 在利用运行时保护了一种层次结构，并且假如导入其余模块的模块成为被导入模块的父模块。

然而，事实并非如此。 所有模块在编译阶段合并 。因而，导入的模块和导入的模块之间没有档次关系。

所需命名空间之一被定义为默认命名空间。此命名空间的管制标记不须要前缀。

<View> 标签是必须的，在下面的示例中，外围命名空间在第一行定义。当然开发人员能够定义任何名称。例如，为了使标签名称更短，还能够应用 c 而不是 core.