5 lines
51 KiB
JSON
5 lines
51 KiB
JSON
{
|
|
"id": "guide/ngmodule-faq",
|
|
"title": "NgModule FAQ",
|
|
"contents": "\n\n\n<div class=\"github-links\">\n <a href=\"https://github.com/angular/angular/edit/master/aio/content/guide/ngmodule-faq.md?message=docs%3A%20describe%20your%20change...\" aria-label=\"Suggest Edits\" title=\"Suggest Edits\"><i class=\"material-icons\" aria-hidden=\"true\" role=\"img\">mode_edit</i></a>\n</div>\n\n\n<div class=\"content\">\n <h1 id=\"ngmodule-faq\">NgModule FAQ<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#ngmodule-faq\"><i class=\"material-icons\">link</i></a></h1>\n<p>NgModules help organize an application into cohesive blocks of functionality.</p>\n<p>This page answers the questions many developers ask about NgModule design and implementation.</p>\n<h2 id=\"what-classes-should-i-add-to-the-declarations-array\">What classes should I add to the <code>declarations</code> array?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-classes-should-i-add-to-the-declarations-array\"><i class=\"material-icons\">link</i></a></h2>\n<p>Add <a href=\"guide/bootstrapping#the-declarations-array\">declarable</a> classes—components, directives, and pipes—to a <code>declarations</code> list.</p>\n<p>Declare these classes in <em>exactly one</em> module of the application.\nDeclare them in a module if they belong to that particular module.</p>\n<a id=\"q-declarable\"></a>\n<h2 id=\"what-is-a-declarable\">What is a <em>declarable</em>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-is-a-declarable\"><i class=\"material-icons\">link</i></a></h2>\n<p>Declarables are the class types—components, directives, and pipes—that\nyou can add to a module's <code>declarations</code> list.\nThey're the only classes that you can add to <code>declarations</code>.</p>\n<h2 id=\"what-classes-should-i-not-add-to-declarations\">What classes should I <em>not</em> add to <code>declarations</code>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-classes-should-i-not-add-to-declarations\"><i class=\"material-icons\">link</i></a></h2>\n<p>Add only <a href=\"guide/bootstrapping#the-declarations-array\">declarable</a> classes to an NgModule's <code>declarations</code> list.</p>\n<p>Do <em>not</em> declare the following:</p>\n<ul>\n<li>\n<p>A class that's already declared in another module, whether an app module, @NgModule, or third-party module.</p>\n</li>\n<li>\n<p>An array of directives imported from another module.\nFor example, don't declare <code>FORMS_DIRECTIVES</code> from <code>@angular/forms</code> because the <code><a href=\"api/forms/FormsModule\" class=\"code-anchor\">FormsModule</a></code> already declares it.</p>\n</li>\n<li>\n<p>Module classes.</p>\n</li>\n<li>\n<p>Service classes.</p>\n</li>\n<li>\n<p>Non-Angular classes and objects, such as\nstrings, numbers, functions, entity models, configurations, business logic, and helper classes.</p>\n</li>\n</ul>\n<h2 id=\"why-list-the-same-component-in-multiple-ngmodule-properties\">Why list the same component in multiple <code><a href=\"api/core/NgModule\" class=\"code-anchor\">NgModule</a></code> properties?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#why-list-the-same-component-in-multiple-ngmodule-properties\"><i class=\"material-icons\">link</i></a></h2>\n<p><code>AppComponent</code> is often listed in both <code>declarations</code> and <code>bootstrap</code>.\nYou might see the same component listed in <code>declarations</code>, <code>exports</code>, and <code>entryComponents</code>.</p>\n<p>While that seems redundant, these properties have different functions.\nMembership in one list doesn't imply membership in another list.</p>\n<ul>\n<li><code>AppComponent</code> could be declared in this module but not bootstrapped.</li>\n<li><code>AppComponent</code> could be bootstrapped in this module but declared in a different feature module.</li>\n<li>A component could be imported from another app module (so you can't declare it) and re-exported by this module.</li>\n<li>A component could be exported for inclusion in an external component's template\nas well as dynamically loaded in a pop-up dialog.</li>\n</ul>\n<h2 id=\"what-does-cant-bind-to-x-since-it-isnt-a-known-property-of-y-mean\">What does \"Can't bind to 'x' since it isn't a known property of 'y'\" mean?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-does-cant-bind-to-x-since-it-isnt-a-known-property-of-y-mean\"><i class=\"material-icons\">link</i></a></h2>\n<p>This error often means that you haven't declared the directive \"x\"\nor haven't imported the NgModule to which \"x\" belongs.</p>\n<div class=\"alert is-helpful\">\n<p>Perhaps you declared \"x\" in an application sub-module but forgot to export it.\nThe \"x\" class isn't visible to other modules until you add it to the <code>exports</code> list.</p>\n</div>\n<h2 id=\"what-should-i-import\">What should I import?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-should-i-import\"><i class=\"material-icons\">link</i></a></h2>\n<p>Import NgModules whose public (exported) <a href=\"guide/bootstrapping#the-declarations-array\">declarable classes</a>\nyou need to reference in this module's component templates.</p>\n<p>This always means importing <code><a href=\"api/common/CommonModule\" class=\"code-anchor\">CommonModule</a></code> from <code>@angular/common</code> for access to\nthe Angular directives such as <code><a href=\"api/common/NgIf\" class=\"code-anchor\">NgIf</a></code> and <code>NgFor</code>.\nYou can import it directly or from another NgModule that <a href=\"guide/ngmodule-faq#q-reexport\">re-exports</a> it.</p>\n<p>Import <code><a href=\"api/forms/FormsModule\" class=\"code-anchor\">FormsModule</a></code> from <code>@angular/forms</code>\nif your components have <code>[(<a href=\"api/forms/NgModel\" class=\"code-anchor\">ngModel</a>)]</code> two-way binding expressions.</p>\n<p>Import <em>shared</em> and <em>feature</em> modules when this module's components incorporate their\ncomponents, directives, and pipes.</p>\n<p>Import <a href=\"guide/ngmodule-faq#q-browser-vs-common-module\">BrowserModule</a> only in the root <code>AppModule</code>.</p>\n<a id=\"q-browser-vs-common-module\"></a>\n<h2 id=\"should-i-import-browsermodule-or-commonmodule\">Should I import <code><a href=\"api/platform-browser/BrowserModule\" class=\"code-anchor\">BrowserModule</a></code> or <code><a href=\"api/common/CommonModule\" class=\"code-anchor\">CommonModule</a></code>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#should-i-import-browsermodule-or-commonmodule\"><i class=\"material-icons\">link</i></a></h2>\n<p>The root application module, <code>AppModule</code>, of almost every browser application\nshould import <code><a href=\"api/platform-browser/BrowserModule\" class=\"code-anchor\">BrowserModule</a></code> from <code>@angular/platform-browser</code>.</p>\n<p><code><a href=\"api/platform-browser/BrowserModule\" class=\"code-anchor\">BrowserModule</a></code> provides services that are essential to launch and run a browser app.</p>\n<p><code><a href=\"api/platform-browser/BrowserModule\" class=\"code-anchor\">BrowserModule</a></code> also re-exports <code><a href=\"api/common/CommonModule\" class=\"code-anchor\">CommonModule</a></code> from <code>@angular/common</code>,\nwhich means that components in the <code>AppModule</code> also have access to\nthe Angular directives every app needs, such as <code><a href=\"api/common/NgIf\" class=\"code-anchor\">NgIf</a></code> and <code>NgFor</code>.</p>\n<p>Do not import <code><a href=\"api/platform-browser/BrowserModule\" class=\"code-anchor\">BrowserModule</a></code> in any other module.\n<em>Feature modules</em> and <em>lazy-loaded modules</em> should import <code><a href=\"api/common/CommonModule\" class=\"code-anchor\">CommonModule</a></code> instead.\nThey need the common directives. They don't need to re-install the app-wide providers.</p>\n<p>Importing <code><a href=\"api/common/CommonModule\" class=\"code-anchor\">CommonModule</a></code> also frees feature modules for use on <em>any</em> target platform, not just browsers.</p>\n<a id=\"q-reimport\"></a>\n<h2 id=\"what-if-i-import-the-same-module-twice\">What if I import the same module twice?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-if-i-import-the-same-module-twice\"><i class=\"material-icons\">link</i></a></h2>\n<p>That's not a problem. When three modules all import Module 'A',\nAngular evaluates Module 'A' once, the first time it encounters it, and doesn't do so again.</p>\n<p>That's true at whatever level <code>A</code> appears in a hierarchy of imported NgModules.\nWhen Module 'B' imports Module 'A', Module 'C' imports 'B', and Module 'D' imports <code>[C, B, A]</code>,\nthen 'D' triggers the evaluation of 'C', which triggers the evaluation of 'B', which evaluates 'A'.\nWhen Angular gets to the 'B' and 'A' in 'D', they're already cached and ready to go.</p>\n<p>Angular doesn't like NgModules with circular references, so don't let Module 'A' import Module 'B', which imports Module 'A'.</p>\n<a id=\"q-reexport\"></a>\n<h2 id=\"what-should-i-export\">What should I export?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-should-i-export\"><i class=\"material-icons\">link</i></a></h2>\n<p>Export <a href=\"guide/bootstrapping#the-declarations-array\">declarable</a> classes that components in <em>other</em> NgModules\nare able to reference in their templates. These are your <em>public</em> classes.\nIf you don't export a declarable class, it stays <em>private</em>, visible only to other components\ndeclared in this NgModule.</p>\n<p>You <em>can</em> export any declarable class—components, directives, and pipes—whether\nit's declared in this NgModule or in an imported NgModule.</p>\n<p>You <em>can</em> re-export entire imported NgModules, which effectively re-export all of their exported classes.\nAn NgModule can even export a module that it doesn't import.</p>\n<h2 id=\"what-should-i-not-export\">What should I <em>not</em> export?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-should-i-not-export\"><i class=\"material-icons\">link</i></a></h2>\n<p>Don't export the following:</p>\n<ul>\n<li>Private components, directives, and pipes that you need only within components declared in this NgModule.\nIf you don't want another NgModule to see it, don't export it.</li>\n<li>Non-declarable objects such as services, functions, configurations, and entity models.</li>\n<li>Components that are only loaded dynamically by the router or by bootstrapping.\nSuch <a href=\"guide/ngmodule-faq#q-entry-component-defined\">entry components</a> can never be selected in another component's template.\nWhile there's no harm in exporting them, there's also no benefit.</li>\n<li>Pure service modules that don't have public (exported) declarations.\nFor example, there's no point in re-exporting <code><a href=\"api/common/http/HttpClientModule\" class=\"code-anchor\">HttpClientModule</a></code> because it doesn't export anything.\nIts only purpose is to add http service providers to the application as a whole.</li>\n</ul>\n<h2 id=\"can-i-re-export-classes-and-modules\">Can I re-export classes and modules?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#can-i-re-export-classes-and-modules\"><i class=\"material-icons\">link</i></a></h2>\n<p>Absolutely.</p>\n<p>NgModules are a great way to selectively aggregate classes from other NgModules and\nre-export them in a consolidated, convenience module.</p>\n<p>An NgModule can re-export entire NgModules, which effectively re-exports all of their exported classes.\nAngular's own <code><a href=\"api/platform-browser/BrowserModule\" class=\"code-anchor\">BrowserModule</a></code> exports a couple of NgModules like this:</p>\n<code-example language=\"typescript\">\n exports: [<a href=\"api/common/CommonModule\" class=\"code-anchor\">CommonModule</a>, <a href=\"api/core/ApplicationModule\" class=\"code-anchor\">ApplicationModule</a>]\n</code-example>\n<p>An NgModule can export a combination of its own declarations, selected imported classes, and imported NgModules.</p>\n<p>Don't bother re-exporting pure service modules.\nPure service modules don't export <a href=\"guide/bootstrapping#the-declarations-array\">declarable</a> classes that another NgModule could use.\nFor example, there's no point in re-exporting <code><a href=\"api/common/http/HttpClientModule\" class=\"code-anchor\">HttpClientModule</a></code> because it doesn't export anything.\nIts only purpose is to add http service providers to the application as a whole.</p>\n<h2 id=\"what-is-the-forroot-method\">What is the <code>forRoot()</code> method?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-is-the-forroot-method\"><i class=\"material-icons\">link</i></a></h2>\n<p>The <code>forRoot()</code> static method is a convention that makes it easy for developers to configure services and providers that are intended to be singletons. A good example of <code>forRoot()</code> is the <code><a href=\"api/router/RouterModule#forRoot\" class=\"code-anchor\">RouterModule.forRoot()</a></code> method.</p>\n<p>Apps pass a <code><a href=\"api/router/Routes\" class=\"code-anchor\">Routes</a></code> array to <code><a href=\"api/router/RouterModule#forRoot\" class=\"code-anchor\">RouterModule.forRoot()</a></code> in order to configure the app-wide <code><a href=\"api/router/Router\" class=\"code-anchor\">Router</a></code> service with routes.\n<code><a href=\"api/router/RouterModule#forRoot\" class=\"code-anchor\">RouterModule.forRoot()</a></code> returns a <a href=\"api/core/ModuleWithProviders\">ModuleWithProviders</a>.\nYou add that result to the <code>imports</code> list of the root <code>AppModule</code>.</p>\n<p>Only call and import a <code>forRoot()</code> result in the root application module, <code>AppModule</code>.\nAvoid importing it in any other module, particularly in a lazy-loaded module. For more\ninformation on <code>forRoot()</code> see <a href=\"guide/singleton-services#the-forroot-pattern\">the <code>forRoot()</code> pattern</a> section of the <a href=\"guide/singleton-services\">Singleton Services</a> guide.</p>\n<p>For a service, instead of using <code>forRoot()</code>, specify <code>providedIn: 'root'</code> on the service's <code>@<a href=\"api/core/Injectable\" class=\"code-anchor\">Injectable</a>()</code> decorator, which\nmakes the service automatically available to the whole application and thus singleton by default.</p>\n<p><code><a href=\"api/router/RouterModule\" class=\"code-anchor\">RouterModule</a></code> also offers a <code>forChild()</code> static method for configuring the routes of lazy-loaded modules.</p>\n<p><code>forRoot()</code> and <code>forChild()</code> are conventional names for methods that\nconfigure services in root and feature modules respectively.</p>\n<p>Follow this convention when you write similar modules with configurable service providers.</p>\n<h2 id=\"why-is-a-service-provided-in-a-feature-module-visible-everywhere\">Why is a service provided in a feature module visible everywhere?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#why-is-a-service-provided-in-a-feature-module-visible-everywhere\"><i class=\"material-icons\">link</i></a></h2>\n<p>Providers listed in the <code>@<a href=\"api/core/NgModule#providers\" class=\"code-anchor\">NgModule.providers</a></code> of a bootstrapped module have application scope.\nAdding a service provider to <code>@<a href=\"api/core/NgModule#providers\" class=\"code-anchor\">NgModule.providers</a></code> effectively publishes the service to the entire application.</p>\n<p>When you import an NgModule,\nAngular adds the module's service providers (the contents of its <code>providers</code> list)\nto the application root injector.</p>\n<p>This makes the provider visible to every class in the application that knows the provider's lookup token, or name.</p>\n<p>Extensibility through NgModule imports is a primary goal of the NgModule system.\nMerging NgModule providers into the application injector\nmakes it easy for a module library to enrich the entire application with new services.\nBy adding the <code><a href=\"api/common/http/HttpClientModule\" class=\"code-anchor\">HttpClientModule</a></code> once, every application component can make HTTP requests.</p>\n<p>However, this might feel like an unwelcome surprise if you expect the module's services\nto be visible only to the components declared by that feature module.\nIf the <code>HeroModule</code> provides the <code>HeroService</code> and the root <code>AppModule</code> imports <code>HeroModule</code>,\nany class that knows the <code>HeroService</code> <em>type</em> can inject that service,\nnot just the classes declared in the <code>HeroModule</code>.</p>\n<p>To limit access to a service, consider lazy loading the NgModule that provides that service. See <a href=\"guide/ngmodule-faq#service-scope\">How do I restrict service scope to a module?</a> for more information.</p>\n<a id=\"q-lazy-loaded-module-provider-visibility\"></a>\n<h2 id=\"why-is-a-service-provided-in-a-lazy-loaded-module-visible-only-to-that-module\">Why is a service provided in a lazy-loaded module visible only to that module?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#why-is-a-service-provided-in-a-lazy-loaded-module-visible-only-to-that-module\"><i class=\"material-icons\">link</i></a></h2>\n<p>Unlike providers of the modules loaded at launch,\nproviders of lazy-loaded modules are <em>module-scoped</em>.</p>\n<p>When the Angular router lazy-loads a module, it creates a new execution context.\nThat <a href=\"guide/ngmodule-faq#q-why-child-injector\" title=\"Why Angular creates a child injector\">context has its own injector</a>,\nwhich is a direct child of the application injector.</p>\n<p>The router adds the lazy module's providers and the providers of its imported NgModules to this child injector.</p>\n<p>These providers are insulated from changes to application providers with the same lookup token.\nWhen the router creates a component within the lazy-loaded context,\nAngular prefers service instances created from these providers to the service instances of the application root injector.</p>\n<h2 id=\"what-if-two-modules-provide-the-same-service\">What if two modules provide the same service?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-if-two-modules-provide-the-same-service\"><i class=\"material-icons\">link</i></a></h2>\n<p>When two imported modules, loaded at the same time, list a provider with the same token,\nthe second module's provider \"wins\". That's because both providers are added to the same injector.</p>\n<p>When Angular looks to inject a service for that token,\nit creates and delivers the instance created by the second provider.</p>\n<p><em>Every</em> class that injects this service gets the instance created by the second provider.\nEven classes declared within the first module get the instance created by the second provider.</p>\n<p>If NgModule A provides a service for token 'X' and imports an NgModule B\nthat also provides a service for token 'X', then NgModule A's service definition \"wins\".</p>\n<p>The service provided by the root <code>AppModule</code> takes precedence over services provided by imported NgModules.\nThe <code>AppModule</code> always wins.</p>\n<a id=\"service-scope\"></a>\n<h2 id=\"how-do-i-restrict-service-scope-to-a-module\">How do I restrict service scope to a module?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#how-do-i-restrict-service-scope-to-a-module\"><i class=\"material-icons\">link</i></a></h2>\n<p>When a module is loaded at application launch,\nits <code>@<a href=\"api/core/NgModule#providers\" class=\"code-anchor\">NgModule.providers</a></code> have <em>application-wide scope</em>;\nthat is, they are available for injection throughout the application.</p>\n<p>Imported providers are easily replaced by providers from another imported NgModule.\nSuch replacement might be by design. It could be unintentional and have adverse consequences.</p>\n<p>As a general rule, import modules with providers <em>exactly once</em>, preferably in the application's <em>root module</em>.\nThat's also usually the best place to configure, wrap, and override them.</p>\n<p>Suppose a module requires a customized <code><a href=\"api/common/http/HttpBackend\" class=\"code-anchor\">HttpBackend</a></code> that adds a special header for all Http requests.\nIf another module elsewhere in the application also customizes <code><a href=\"api/common/http/HttpBackend\" class=\"code-anchor\">HttpBackend</a></code>\nor merely imports the <code><a href=\"api/common/http/HttpClientModule\" class=\"code-anchor\">HttpClientModule</a></code>, it could override this module's <code><a href=\"api/common/http/HttpBackend\" class=\"code-anchor\">HttpBackend</a></code> provider,\nlosing the special header. The server will reject http requests from this module.</p>\n<p>To avoid this problem, import the <code><a href=\"api/common/http/HttpClientModule\" class=\"code-anchor\">HttpClientModule</a></code> only in the <code>AppModule</code>, the application <em>root module</em>.</p>\n<p>If you must guard against this kind of \"provider corruption\", <em>don't rely on a launch-time module's <code>providers</code>.</em></p>\n<p>Load the module lazily if you can.\nAngular gives a <a href=\"guide/ngmodule-faq#q-lazy-loaded-module-provider-visibility\">lazy-loaded module</a> its own child injector.\nThe module's providers are visible only within the component tree created with this injector.</p>\n<p>If you must load the module eagerly, when the application starts,\n<em>provide the service in a component instead.</em></p>\n<p>Continuing with the same example, suppose the components of a module truly require a private, custom <code><a href=\"api/common/http/HttpBackend\" class=\"code-anchor\">HttpBackend</a></code>.</p>\n<p>Create a \"top component\" that acts as the root for all of the module's components.\nAdd the custom <code><a href=\"api/common/http/HttpBackend\" class=\"code-anchor\">HttpBackend</a></code> provider to the top component's <code>providers</code> list rather than the module's <code>providers</code>.\nRecall that Angular creates a child injector for each component instance and populates the injector\nwith the component's own providers.</p>\n<p>When a child of this component asks for the <code><a href=\"api/common/http/HttpBackend\" class=\"code-anchor\">HttpBackend</a></code> service,\nAngular provides the local <code><a href=\"api/common/http/HttpBackend\" class=\"code-anchor\">HttpBackend</a></code> service,\nnot the version provided in the application root injector.\nChild components make proper HTTP requests no matter what other modules do to <code><a href=\"api/common/http/HttpBackend\" class=\"code-anchor\">HttpBackend</a></code>.</p>\n<p>Be sure to create module components as children of this module's top component.</p>\n<p>You can embed the child components in the top component's template.\nAlternatively, make the top component a routing host by giving it a <code><<a href=\"api/router/RouterOutlet\" class=\"code-anchor\">router-outlet</a>></code>.\nDefine child routes and let the router load module components into that outlet.</p>\n<p>Though you can limit access to a service by providing it in a lazy loaded module or providing it in a component, providing services in a component can lead to multiple instances of those services. Thus, the lazy loading is preferable.</p>\n<a id=\"q-root-component-or-module\"></a>\n<h2 id=\"should-i-add-application-wide-providers-to-the-root-appmodule-or-the-root-appcomponent\">Should I add application-wide providers to the root <code>AppModule</code> or the root <code>AppComponent</code>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#should-i-add-application-wide-providers-to-the-root-appmodule-or-the-root-appcomponent\"><i class=\"material-icons\">link</i></a></h2>\n<p> Define application-wide providers by specifying <code>providedIn: 'root'</code> on its <code>@<a href=\"api/core/Injectable\" class=\"code-anchor\">Injectable</a>()</code> decorator (in the case of services) or at <code><a href=\"api/core/InjectionToken\" class=\"code-anchor\">InjectionToken</a></code> construction (in the case where tokens are provided). Providers that are created this way automatically are made available to the entire application and don't need to be listed in any module.</p>\n<p>If a provider cannot be configured in this way (perhaps because it has no sensible default value), then register application-wide providers in the root <code>AppModule</code>, not in the <code>AppComponent</code>.</p>\n<p>Lazy-loaded modules and their components can inject <code>AppModule</code> services;\nthey can't inject <code>AppComponent</code> services.</p>\n<p>Register a service in <code>AppComponent</code> providers <em>only</em> if the service must be hidden\nfrom components outside the <code>AppComponent</code> tree. This is a rare use case.</p>\n<p>More generally, <a href=\"guide/ngmodule-faq#q-component-or-module\">prefer registering providers in NgModules</a> to registering in components.</p>\n<h3 class=\"no-toc\" id=\"discussion\">Discussion<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#discussion\"><i class=\"material-icons\">link</i></a></h3>\n<p>Angular registers all startup module providers with the application root injector.\nThe services that root injector providers create have application scope, which\nmeans they are available to the entire application.</p>\n<p>Certain services, such as the <code><a href=\"api/router/Router\" class=\"code-anchor\">Router</a></code>, only work when you register them in the application root injector.</p>\n<p>By contrast, Angular registers <code>AppComponent</code> providers with the <code>AppComponent</code>'s own injector.\n<code>AppComponent</code> services are available only to that component and its component tree.\nThey have component scope.</p>\n<p>The <code>AppComponent</code>'s injector is a child of the root injector, one down in the injector hierarchy.\nFor applications that don't use the router, that's almost the entire application.\nBut in routed applications, routing operates at the root level\nwhere <code>AppComponent</code> services don't exist.\nThis means that lazy-loaded modules can't reach them.</p>\n<a id=\"q-component-or-module\"></a>\n<h2 id=\"should-i-add-other-providers-to-a-module-or-a-component\">Should I add other providers to a module or a component?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#should-i-add-other-providers-to-a-module-or-a-component\"><i class=\"material-icons\">link</i></a></h2>\n<p>Providers should be configured using <code>@<a href=\"api/core/Injectable\" class=\"code-anchor\">Injectable</a></code> syntax. If possible, they should be provided in the application root (<code>providedIn: 'root'</code>). Services that are configured this way are lazily loaded if they are only used from a lazily loaded context.</p>\n<p>If it's the consumer's decision whether a provider is available application-wide or not,\nthen register providers in modules (<code>@<a href=\"api/core/NgModule#providers\" class=\"code-anchor\">NgModule.providers</a></code>) instead of registering in components (<code>@Component.providers</code>).</p>\n<p>Register a provider with a component when you <em>must</em> limit the scope of a service instance\nto that component and its component tree.\nApply the same reasoning to registering a provider with a directive.</p>\n<p>For example, an editing component that needs a private copy of a caching service should register\nthe service with the component.\nThen each new instance of the component gets its own cached service instance.\nThe changes that editor makes in its service don't touch the instances elsewhere in the application.</p>\n<p><a href=\"guide/ngmodule-faq#q-root-component-or-module\">Always register <em>application-wide</em> services with the root <code>AppModule</code></a>,\nnot the root <code>AppComponent</code>.</p>\n<a id=\"q-why-bad\"></a>\n<h2 id=\"why-is-it-bad-if-a-shared-module-provides-a-service-to-a-lazy-loaded-module\">Why is it bad if a shared module provides a service to a lazy-loaded module?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#why-is-it-bad-if-a-shared-module-provides-a-service-to-a-lazy-loaded-module\"><i class=\"material-icons\">link</i></a></h2>\n<h3 id=\"the-eagerly-loaded-scenario\">The eagerly loaded scenario<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#the-eagerly-loaded-scenario\"><i class=\"material-icons\">link</i></a></h3>\n<p>When an eagerly loaded module provides a service, for example a <code>UserService</code>, that service is available application-wide. If the root module provides <code>UserService</code> and\nimports another module that provides the same <code>UserService</code>, Angular registers one of\nthem in the root app injector (see <a href=\"guide/ngmodule-faq#q-reimport\">What if I import the same module twice?</a>).</p>\n<p>Then, when some component injects <code>UserService</code>, Angular finds it in the app root injector,\nand delivers the app-wide singleton service. No problem.</p>\n<h3 id=\"the-lazy-loaded-scenario\">The lazy loaded scenario<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#the-lazy-loaded-scenario\"><i class=\"material-icons\">link</i></a></h3>\n<p>Now consider a lazy loaded module that also provides a service called <code>UserService</code>.</p>\n<p>When the router lazy loads a module, it creates a child injector and registers the <code>UserService</code>\nprovider with that child injector. The child injector is <em>not</em> the root injector.</p>\n<p>When Angular creates a lazy component for that module and injects <code>UserService</code>,\nit finds a <code>UserService</code> provider in the lazy module's <em>child injector</em>\nand creates a <em>new</em> instance of the <code>UserService</code>.\nThis is an entirely different <code>UserService</code> instance\nthan the app-wide singleton version that Angular injected in one of the eagerly loaded components.</p>\n<p>This scenario causes your app to create a new instance every time, instead of using the singleton.</p>\n<!--KW--What does this cause? I wasn't able to get the suggestion of this to work from\nthe current FAQ:\nTo demonstrate, run the <live-example name=\"ngmodule\">live example</live-example>.\nModify the `SharedModule` so that it provides the `UserService` rather than the `CoreModule`.\nThen toggle between the \"Contact\" and \"Heroes\" links a few times.\nThe username goes bonkers as the Angular creates a new `UserService` instance each time.\nI'd like to see the error so I can include it.-->\n<a id=\"q-why-child-injector\"></a>\n<h2 id=\"why-does-lazy-loading-create-a-child-injector\">Why does lazy loading create a child injector?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#why-does-lazy-loading-create-a-child-injector\"><i class=\"material-icons\">link</i></a></h2>\n<p>Angular adds <code>@<a href=\"api/core/NgModule#providers\" class=\"code-anchor\">NgModule.providers</a></code> to the application root injector, unless the NgModule is lazy-loaded.\nFor a lazy-loaded NgModule, Angular creates a <em>child injector</em> and adds the module's providers to the child injector.</p>\n<p>This means that an NgModule behaves differently depending on whether it's loaded during application start\nor lazy-loaded later. Neglecting that difference can lead to <a href=\"guide/ngmodule-faq#q-why-bad\">adverse consequences</a>.</p>\n<p>Why doesn't Angular add lazy-loaded providers to the app root injector as it does for eagerly loaded NgModules?</p>\n<p>The answer is grounded in a fundamental characteristic of the Angular dependency-injection system.\nAn injector can add providers <em>until it's first used</em>.\nOnce an injector starts creating and delivering services, its provider list is frozen; no new providers are allowed.</p>\n<p>When an applications starts, Angular first configures the root injector with the providers of all eagerly loaded NgModules\n<em>before</em> creating its first component and injecting any of the provided services.\nOnce the application begins, the app root injector is closed to new providers.</p>\n<p>Time passes and application logic triggers lazy loading of an NgModule.\nAngular must add the lazy-loaded module's providers to an injector somewhere.\nIt can't add them to the app root injector because that injector is closed to new providers.\nSo Angular creates a new child injector for the lazy-loaded module context.</p>\n<a id=\"q-is-it-loaded\"></a>\n<h2 id=\"how-can-i-tell-if-an-ngmodule-or-service-was-previously-loaded\">How can I tell if an NgModule or service was previously loaded?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#how-can-i-tell-if-an-ngmodule-or-service-was-previously-loaded\"><i class=\"material-icons\">link</i></a></h2>\n<p>Some NgModules and their services should be loaded only once by the root <code>AppModule</code>.\nImporting the module a second time by lazy loading a module could <a href=\"guide/ngmodule-faq#q-why-bad\">produce errant behavior</a>\nthat may be difficult to detect and diagnose.</p>\n<p>To prevent this issue, write a constructor that attempts to inject the module or service\nfrom the root app injector. If the injection succeeds, the class has been loaded a second time.\nYou can throw an error or take other remedial action.</p>\n<p>Certain NgModules, such as <code><a href=\"api/platform-browser/BrowserModule\" class=\"code-anchor\">BrowserModule</a></code>, implement such a guard.\nHere is a custom constructor for an NgModule called <code>GreetingModule</code>.</p>\n<code-example path=\"ngmodules/src/app/greeting/greeting.module.ts\" region=\"ctor\" header=\"src/app/greeting/greeting.module.ts (Constructor)\">\nconstructor(@<a href=\"api/core/Optional\" class=\"code-anchor\">Optional</a>() @<a href=\"api/core/SkipSelf\" class=\"code-anchor\">SkipSelf</a>() parentModule?: GreetingModule) {\n if (parentModule) {\n throw new Error(\n 'GreetingModule is already loaded. Import it in the AppModule only');\n }\n}\n\n</code-example>\n<a id=\"q-entry-component-defined\"></a>\n<h2 id=\"what-is-an-entry-component\">What is an <code>entry component</code>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-is-an-entry-component\"><i class=\"material-icons\">link</i></a></h2>\n<p>An entry component is any component that Angular loads <em>imperatively</em> by type.</p>\n<p>A component loaded <em>declaratively</em> via its selector is <em>not</em> an entry component.</p>\n<p>Angular loads a component declaratively when\nusing the component's selector to locate the element in the template.\nAngular then creates the HTML representation of the component and inserts it into the DOM at the selected element. These aren't entry components.</p>\n<p>The bootstrapped root <code>AppComponent</code> is an <em>entry component</em>.\nTrue, its selector matches an element tag in <code>index.html</code>.\nBut <code>index.html</code> isn't a component template and the <code>AppComponent</code>\nselector doesn't match an element in any component template.</p>\n<p>Components in route definitions are also <em>entry components</em>.\nA route definition refers to a component by its <em>type</em>.\nThe router ignores a routed component's selector, if it even has one, and\nloads the component dynamically into a <code><a href=\"api/router/RouterOutlet\" class=\"code-anchor\">RouterOutlet</a></code>.</p>\n<p>For more information, see <a href=\"guide/entry-components\">Entry Components</a>.</p>\n<h2 id=\"whats-the-difference-between-a-bootstrap-component-and-an-entry-component\">What's the difference between a <em>bootstrap</em> component and an <em>entry component</em>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#whats-the-difference-between-a-bootstrap-component-and-an-entry-component\"><i class=\"material-icons\">link</i></a></h2>\n<p>A bootstrapped component <em>is</em> an <a href=\"guide/ngmodule-faq#q-entry-component-defined\">entry component</a>\nthat Angular loads into the DOM during the bootstrap process (application launch).\nOther entry components are loaded dynamically by other means, such as with the router.</p>\n<p>The <code>@<a href=\"api/core/NgModule#bootstrap\" class=\"code-anchor\">NgModule.bootstrap</a></code> property tells the compiler that this is an entry component <em>and</em>\nit should generate code to bootstrap the application with this component.</p>\n<p>There's no need to list a component in both the <code>bootstrap</code> and <code>entryComponents</code> lists,\nalthough doing so is harmless.</p>\n<p>For more information, see <a href=\"guide/entry-components\">Entry Components</a>.</p>\n<h2 id=\"when-do-i-add-components-to-entrycomponents\">When do I add components to <em>entryComponents</em>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#when-do-i-add-components-to-entrycomponents\"><i class=\"material-icons\">link</i></a></h2>\n<p>Most application developers won't need to add components to the <code>entryComponents</code>.</p>\n<p>Angular adds certain components to <em>entry components</em> automatically.\nComponents listed in <code>@<a href=\"api/core/NgModule#bootstrap\" class=\"code-anchor\">NgModule.bootstrap</a></code> are added automatically.\nComponents referenced in router configuration are added automatically.\nThese two mechanisms account for almost all entry components.</p>\n<p>If your app happens to bootstrap or dynamically load a component <em>by type</em> in some other manner,\nyou must add it to <code>entryComponents</code> explicitly.</p>\n<p>Although it's harmless to add components to this list,\nit's best to add only the components that are truly <em>entry components</em>.\nDon't include components that <a href=\"guide/ngmodule-faq#q-template-reference\">are referenced</a>\nin the templates of other components.</p>\n<p>For more information, see <a href=\"guide/entry-components\">Entry Components</a>.</p>\n<h2 id=\"why-does-angular-need-entrycomponents\">Why does Angular need <em>entryComponents</em>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#why-does-angular-need-entrycomponents\"><i class=\"material-icons\">link</i></a></h2>\n<p>The reason is <em>tree shaking</em>. For production apps you want to load the smallest, fastest code possible. The code should contain only the classes that you actually need.\nIt should exclude a component that's never used, whether or not that component is declared.</p>\n<p>In fact, many libraries declare and export components you'll never use.\nIf you don't reference them, the tree shaker drops these components from the final code package.</p>\n<p>If the <a href=\"guide/ngmodule-faq#q-angular-compiler\">Angular compiler</a> generated code for every declared component, it would defeat the purpose of the tree shaker.</p>\n<p>Instead, the compiler adopts a recursive strategy that generates code only for the components you use.</p>\n<p>The compiler starts with the entry components,\nthen it generates code for the declared components it <a href=\"guide/ngmodule-faq#q-template-reference\">finds</a> in an entry component's template,\nthen for the declared components it discovers in the templates of previously compiled components,\nand so on. At the end of the process, the compiler has generated code for every entry component\nand every component reachable from an entry component.</p>\n<p>If a component isn't an <em>entry component</em> or wasn't found in a template,\nthe compiler omits it.</p>\n<h2 id=\"what-kinds-of-modules-should-i-have-and-how-should-i-use-them\">What kinds of modules should I have and how should I use them?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-kinds-of-modules-should-i-have-and-how-should-i-use-them\"><i class=\"material-icons\">link</i></a></h2>\n<p>Every app is different. Developers have various levels of experience and comfort with the available choices.\nSome suggestions and guidelines appear to have wide appeal.</p>\n<h3 id=\"sharedmodule\"><code>SharedModule</code><a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#sharedmodule\"><i class=\"material-icons\">link</i></a></h3>\n<p><code>SharedModule</code> is a conventional name for an <code><a href=\"api/core/NgModule\" class=\"code-anchor\">NgModule</a></code> with the components, directives, and pipes that you use\neverywhere in your app. This module should consist entirely of <code>declarations</code>,\nmost of them exported.</p>\n<p>The <code>SharedModule</code> may re-export other widget modules, such as <code><a href=\"api/common/CommonModule\" class=\"code-anchor\">CommonModule</a></code>,\n<code><a href=\"api/forms/FormsModule\" class=\"code-anchor\">FormsModule</a></code>, and NgModules with the UI controls that you use most widely.</p>\n<p>The <code>SharedModule</code> should not have <code>providers</code> for reasons <a href=\"guide/ngmodule-faq#q-why-bad\">explained previously</a>.\nNor should any of its imported or re-exported modules have <code>providers</code>.</p>\n<p>Import the <code>SharedModule</code> in your <em>feature</em> modules,\nboth those loaded when the app starts and those you lazy load later.</p>\n<h3 id=\"feature-modules\">Feature Modules<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#feature-modules\"><i class=\"material-icons\">link</i></a></h3>\n<p>Feature modules are modules you create around specific application business domains, user workflows, and utility collections. They support your app by containing a particular feature,\nsuch as routes, services, widgets, etc. To conceptualize what a feature module might be in your\napp, consider that if you would put the files related to a certain functionality, like a search,\nin one folder, that the contents of that folder would be a feature module that you might call\nyour <code>SearchModule</code>. It would contain all of the components, routing, and templates that\nwould make up the search functionality.</p>\n<p>For more information, see <a href=\"guide/feature-modules\">Feature Modules</a> and\n<a href=\"guide/module-types\">Module Types</a></p>\n<h2 id=\"whats-the-difference-between-ngmodules-and-javascript-modules\">What's the difference between NgModules and JavaScript Modules?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#whats-the-difference-between-ngmodules-and-javascript-modules\"><i class=\"material-icons\">link</i></a></h2>\n<p>In an Angular app, NgModules and JavaScript modules work together.</p>\n<p>In modern JavaScript, every file is a module\n(see the <a href=\"https://exploringjs.com/es6/ch_modules.html\">Modules</a> page of the Exploring ES6 website).\nWithin each file you write an <code>export</code> statement to make parts of the module public.</p>\n<p>An Angular NgModule is a class with the <code>@<a href=\"api/core/NgModule\" class=\"code-anchor\">NgModule</a></code> decorator—JavaScript modules\ndon't have to have the <code>@<a href=\"api/core/NgModule\" class=\"code-anchor\">NgModule</a></code> decorator. Angular's <code><a href=\"api/core/NgModule\" class=\"code-anchor\">NgModule</a></code> has <code>imports</code> and <code>exports</code> and they serve a similar purpose.</p>\n<p>You <em>import</em> other NgModules so you can use their exported classes in component templates.\nYou <em>export</em> this NgModule's classes so they can be imported and used by components of <em>other</em> NgModules.</p>\n<p>For more information, see <a href=\"guide/ngmodule-vs-jsmodule\">JavaScript Modules vs. NgModules</a>.</p>\n<a id=\"q-template-reference\"></a>\n<h2 id=\"how-does-angular-find-components-directives-and-pipes-in-a-templatewhat-is-a-template-reference\">How does Angular find components, directives, and pipes in a template?<br>What is a <i><b>template reference</b></i>?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#how-does-angular-find-components-directives-and-pipes-in-a-templatewhat-is-a-template-reference\"><i class=\"material-icons\">link</i></a></h2>\n<p>The <a href=\"guide/ngmodule-faq#q-angular-compiler\">Angular compiler</a> looks inside component templates\nfor other components, directives, and pipes. When it finds one, that's a template reference.</p>\n<p>The Angular compiler finds a component or directive in a template when it can match the <em>selector</em> of that component or directive to some HTML in that template.</p>\n<p>The compiler finds a pipe if the pipe's <em>name</em> appears within the pipe syntax of the template HTML.</p>\n<p>Angular only matches selectors and pipe names for classes that are declared by this module\nor exported by a module that this module imports.</p>\n<a id=\"q-angular-compiler\"></a>\n<h2 id=\"what-is-the-angular-compiler\">What is the Angular compiler?<a title=\"Link to this heading\" class=\"header-link\" aria-hidden=\"true\" href=\"guide/ngmodule-faq#what-is-the-angular-compiler\"><i class=\"material-icons\">link</i></a></h2>\n<p>The Angular compiler converts the application code you write into highly performant JavaScript code.\nThe <code>@<a href=\"api/core/NgModule\" class=\"code-anchor\">NgModule</a></code> metadata plays an important role in guiding the compilation process.</p>\n<p>The code you write isn't immediately executable. For example, components have templates that contain custom elements, attribute directives, Angular binding declarations,\nand some peculiar syntax that clearly isn't native HTML.</p>\n<p>The Angular compiler reads the template markup,\ncombines it with the corresponding component class code, and emits <em>component factories</em>.</p>\n<p>A component factory creates a pure, 100% JavaScript representation\nof the component that incorporates everything described in its <code>@<a href=\"api/core/Component\" class=\"code-anchor\">Component</a></code> metadata:\nthe HTML, the binding instructions, the attached styles.</p>\n<p>Because directives and pipes appear in component templates,\nthe Angular compiler incorporates them into compiled component code too.</p>\n<p><code>@<a href=\"api/core/NgModule\" class=\"code-anchor\">NgModule</a></code> metadata tells the Angular compiler what components to compile for this module and\nhow to link this module with other modules.</p>\n\n \n</div>\n\n<!-- links to this doc:\n - guide/entry-components\n - guide/ngmodule-api\n - guide/providers\n - guide/singleton-services\n-->\n<!-- links from this doc:\n - api/common/CommonModule\n - api/common/NgIf\n - api/common/http/HttpBackend\n - api/common/http/HttpClientModule\n - api/core/ApplicationModule\n - api/core/Component\n - api/core/Injectable\n - api/core/InjectionToken\n - api/core/ModuleWithProviders\n - api/core/NgModule\n - api/core/NgModule#bootstrap\n - api/core/NgModule#providers\n - api/core/Optional\n - api/core/SkipSelf\n - api/forms/FormsModule\n - api/forms/NgModel\n - api/platform-browser/BrowserModule\n - api/router/Router\n - api/router/RouterModule\n - api/router/RouterModule#forRoot\n - api/router/RouterOutlet\n - api/router/Routes\n - guide/bootstrapping#the-declarations-array\n - guide/entry-components\n - guide/feature-modules\n - guide/module-types\n - guide/ngmodule-faq#can-i-re-export-classes-and-modules\n - guide/ngmodule-faq#discussion\n - guide/ngmodule-faq#feature-modules\n - guide/ngmodule-faq#how-can-i-tell-if-an-ngmodule-or-service-was-previously-loaded\n - guide/ngmodule-faq#how-do-i-restrict-service-scope-to-a-module\n - guide/ngmodule-faq#how-does-angular-find-components-directives-and-pipes-in-a-templatewhat-is-a-template-reference\n - guide/ngmodule-faq#ngmodule-faq\n - guide/ngmodule-faq#q-angular-compiler\n - guide/ngmodule-faq#q-browser-vs-common-module\n - guide/ngmodule-faq#q-component-or-module\n - guide/ngmodule-faq#q-entry-component-defined\n - guide/ngmodule-faq#q-lazy-loaded-module-provider-visibility\n - guide/ngmodule-faq#q-reexport\n - guide/ngmodule-faq#q-reimport\n - guide/ngmodule-faq#q-root-component-or-module\n - guide/ngmodule-faq#q-template-reference\n - guide/ngmodule-faq#q-why-bad\n - guide/ngmodule-faq#q-why-child-injector\n - guide/ngmodule-faq#service-scope\n - guide/ngmodule-faq#sharedmodule\n - guide/ngmodule-faq#should-i-add-application-wide-providers-to-the-root-appmodule-or-the-root-appcomponent\n - guide/ngmodule-faq#should-i-add-other-providers-to-a-module-or-a-component\n - guide/ngmodule-faq#should-i-import-browsermodule-or-commonmodule\n - guide/ngmodule-faq#the-eagerly-loaded-scenario\n - guide/ngmodule-faq#the-lazy-loaded-scenario\n - guide/ngmodule-faq#what-classes-should-i-add-to-the-declarations-array\n - guide/ngmodule-faq#what-classes-should-i-not-add-to-declarations\n - guide/ngmodule-faq#what-does-cant-bind-to-x-since-it-isnt-a-known-property-of-y-mean\n - guide/ngmodule-faq#what-if-i-import-the-same-module-twice\n - guide/ngmodule-faq#what-if-two-modules-provide-the-same-service\n - guide/ngmodule-faq#what-is-a-declarable\n - guide/ngmodule-faq#what-is-an-entry-component\n - guide/ngmodule-faq#what-is-the-angular-compiler\n - guide/ngmodule-faq#what-is-the-forroot-method\n - guide/ngmodule-faq#what-kinds-of-modules-should-i-have-and-how-should-i-use-them\n - guide/ngmodule-faq#what-should-i-export\n - guide/ngmodule-faq#what-should-i-import\n - guide/ngmodule-faq#what-should-i-not-export\n - guide/ngmodule-faq#whats-the-difference-between-a-bootstrap-component-and-an-entry-component\n - guide/ngmodule-faq#whats-the-difference-between-ngmodules-and-javascript-modules\n - guide/ngmodule-faq#when-do-i-add-components-to-entrycomponents\n - guide/ngmodule-faq#why-does-angular-need-entrycomponents\n - guide/ngmodule-faq#why-does-lazy-loading-create-a-child-injector\n - guide/ngmodule-faq#why-is-a-service-provided-in-a-feature-module-visible-everywhere\n - guide/ngmodule-faq#why-is-a-service-provided-in-a-lazy-loaded-module-visible-only-to-that-module\n - guide/ngmodule-faq#why-is-it-bad-if-a-shared-module-provides-a-service-to-a-lazy-loaded-module\n - guide/ngmodule-faq#why-list-the-same-component-in-multiple-ngmodule-properties\n - guide/ngmodule-vs-jsmodule\n - guide/singleton-services\n - guide/singleton-services#the-forroot-pattern\n - https://exploringjs.com/es6/ch_modules.html\n - https://github.com/angular/angular/edit/master/aio/content/guide/ngmodule-faq.md?message=docs%3A%20describe%20your%20change...\n-->"
|
|
} |