Role of imports / exports in Angular 2+ ngModule

Question

I'm learning Angular 2+ and I'm having a hard time understanding the role of imports/exports in an ngModule. More specifically why is important to import a module if you're going to import it anyway using es6 syntax as well

import { BrowserModule } from '@angular/platform-browser';
@NgModule({
  imports:      [ BrowserModule ],
  providers:    [ Logger ],
  declarations: [ AppComponent ],
  exports:      [ AppComponent ]
})

Wasn't much simpler to detect that the module was imported via es6 syntax?

imports - other modules whose exported classes are needed by component templates declared in this module.

But we're already importing those on the component level. Am I missing something? I'm also looking for some example to why they went for this syntax .

Vita

Answer 1

The confusion comes from the fact both Angular and ES6 are using the same terminology...

In ES6/TypeScript:

• A module is any code file in your project.
• An import is a line starting with the import keyword.
• An export is a line starting with the export keyword.

In Angular:

• A module is a class decorated with @NgModule. It serves as a registry (aka container) for all the components, pipes, directives and providers in your application.
• An import is what you put in the imports property of the @NgModule decorator. It enables an Angular module to use functionality that was defined in another Angular module.
• An export what you put is the exports property of the @NgModule decorator. It enables an Angular module to expose some of its components/directives/pipes to the other modules in the applications. Without it, the components/directives/pipes defined in a module could only be used in that module.

ES6 modules/imports/exports are very low-level. They are a feature of the ES6 language, just like keywords like const or let... In ES6/TypeScript, each file has ITS OWN SCOPE. So whenever you need to use a class/function/variable in a file and that class/function/variable was defined in another file, you must import it (the counterpart being that it must be exported in the file where it was defined). This is not specific to Angular. ALL PROJECTS WRITTEN IN ES6 can use modules/imports/exports in this manner.

On the other hand, Angular's modules/imports/exports are a feature of the Angular framework. They only make sense in Angular world. Other JavaScript frameworks might have similar notions but they'll use a different syntax.

Now there's some overlap between the two. For instance, in order to use a symbol in @NgModule.imports (Angular world), you need to import the symbol in the TypeScript file where the module is defined (ES6/TypeScript world):

// ES6/TypeScript Imports
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';

@NgModule({
  // Angular Imports
  imports: [ BrowserModule ]
})

But if you read the above definitions carefully, you'll realize that the two things are actually quite different. One is the language, the other is the framework.

Dehorn

For the sake of being overly clear, is the upshot that, if you didn't have imports: [ BrowserModule ] in your NgModule, any use of BrowserModule in a "downstream" component would bork, whether you "properly" perform an ES6 import in the component or not? That is, how do Angular NgModule imports affect files/classes other than the NgModule where that [Angular] import occurs? – Secular

A good example is ReactiveFormsModule: @NgModule({ imports: [ ReactiveFormsModule ] … This can now be used in components, to create reactive forms. So, you can immediately use things like FormControl() etc without having to use the import keyword in the component head. – Chafin

Answer 2

import { BrowserModule } from '@angular/platform-browser'; 

will load the file into memory.

@NgModule({
    imports:      [ BrowserModule ],

will register BrowserModule with Angular.

Pannier

would it be more accurate to say that the second registers BrowserModule with that specific angular module instead of the entire Angular framework? – Myrtice

Yeah, I see what your saying and I agree it makes sense. I think though it would take away from my point about drawing a contrast between loading files into memory and using the objects that are loaded. The whole idea is not to delve into the inner workings of Angular as this distinction is not an Angular specific concern. And I believe it is still accurate as angular is literally a global singleton that manages modules. You are right in that this module is registered from another module and there is a relationship between them, but it is the framework that does all that. – Pannier