f2513c540a
Phase 2 sample code conversions per instructions in doc: https://docs.google.com/document/d/1QqnVK8Mc0O1gU9ctPrs-JJ42V9_dHCuEttD_01pXh34/edit **Included** 1. ajs-quick-reference Minor changes to remove references to NgModule. Converted sample to standalone. 2. architecture Migrated the code sample. Made minor changes to remove references to NgModule. I explicitly deprecated the `architecture-module.md` page and removed it from the navigation. 4. deprecations / deprecations-guide Migrated the code sample which required pulling NgModule and Reactive Forms material into a new `deprecated` folder. Made minor changes to clarify when advice was specific to NgModule (see `loadChildren` in particular). 5. displaying-data Deleted this `displaying-data` sample entirely as there is no need for a sample app just to display a single, vanilla data binding in the deprecated `zone.md` page. Replaced reference in `zone.md` with an inline code snippet. 10. ngcontainer Converted the code sample. There is no guide page for this sample. It can be displayed in Stackblitz **Excluded** 3. cli-builder Code sample is not an app; nothing to convert. 6-9 - related to getting-started and setup. Waiting until Angular team is ready to proceed. 11. providers This is in its own commit and PR 51918 because it may not make sense to convert. See that PR for details. 12. routing-with-urlmatcher No work needed. Already Standalone. 13 schematics-for-libraries Non-trivial (see doc notes) and Angular may decide to leave as is. Should have own PR. 14 setup Non-trivial (see doc notes) and Angular may decide to leave as is. Should have own PR. PR Close #51918
7.1 KiB
Introduction to modules
Angular applications are modular and Angular has its own modularity system called NgModules.
Older Angular applications are built with NgModules.
While this is no longer the preferred approach, many existing applications are still built with NgModules.
This page offers an overview of that concept; learn more here.
NgModules are containers for a cohesive block of code dedicated to an application domain, a workflow, or a closely related set of capabilities. They can contain components, service providers, and other code files whose scope is defined by the containing NgModule. They can import functionality that is exported from other NgModules, and export selected functionality for use by other NgModules.
While a small application might have only one NgModule, most applications have many more feature modules. The root NgModule for an application is so named because it can include child NgModules in a hierarchy of any depth.
NgModule metadata
An NgModule is defined by a class decorated with @NgModule().
The @NgModule() decorator is a function that takes a single metadata object, whose properties describe the module.
The most important properties are as follows.
| Properties | Details |
|---|---|
declarations |
The components, directives, and pipes that belong to this NgModule. |
exports |
The subset of declarations that should be visible and usable in the component templates of other NgModules. |
imports |
Other modules whose exported classes are needed by component templates declared in this NgModule. |
providers |
Creators of services that this NgModule contributes to the global collection of services; they become accessible in all parts of the application. You can also specify providers at the component level. |
bootstrap |
The main application view, called the root component, which hosts all other application views. Only the root NgModule should set the bootstrap property. |
Here's a simple root NgModule definition.
AppComponent is included in the exports list here for illustration; it isn't actually necessary in this example.
A root NgModule has no reason to export anything because other modules don't need to import the root NgModule.
NgModules and components
NgModules provide a compilation context for their components. A root NgModule always has a root component that is created during bootstrap but any NgModule can include any number of additional components, which can be loaded through the router or created through the template. The components that belong to an NgModule share a compilation context.
A component and its template together define a view. A component can contain a view hierarchy, which allows you to define arbitrarily complex areas of the screen that can be created, modified, and destroyed as a unit. A view hierarchy can mix views defined in components that belong to different NgModules. This is often the case, especially for UI libraries.
When you create a component, it's associated directly with a single view, called the host view. The host view can be the root of a view hierarchy, which can contain embedded views, which are in turn the host views of other components. Those components can be in the same NgModule, or can be imported from other NgModules. Views in the tree can be nested to any depth.
NOTE:
The hierarchical structure of views is a key factor in the way Angular detects and responds to changes in the DOM and application data.
NgModules and JavaScript modules
The NgModule system is different from, and unrelated to, the JavaScript ES2015 module system for managing collections of JavaScript objects.
These are complementary module systems that you can use together to write your applications.
In JavaScript each file is a module and all objects defined in the file belong to that module.
The module declares some objects to be public by marking them with the export key word.
Other JavaScript modules use import statements to access public objects from other modules.
Angular libraries
Angular loads as a collection of JavaScript modules.
You can think of them as library modules.
Each Angular library name begins with the @angular prefix.
Install them with the node package manager npm and import parts of them with JavaScript import statements.
For example, import Angular's Component decorator from the @angular/core library like this.
You also import NgModules from Angular libraries using JavaScript import statements.
For example, the following code imports the BrowserModule NgModule from the platform-browser library.
In the example of the simple root module above, the application module needs material from within
BrowserModule.
To access that material, add it to the @NgModule metadata imports like this.
In this way, you're using the Angular and JavaScript module systems together. Although it's easy to confuse the two systems, which share the common vocabulary of "imports" and "exports", you will become familiar with the different contexts in which they are used.
Learn more from the NgModules guide.
@reviewed 2022-02-28