With angular 9, there has been a lot of talking going on around entryComponents, and the Angular developers who had not been much aware of entryComponents have now been interested in knowing more about it.

In this blog post, I will try to cover everything that might help you clear up all the thoughts you have around the usage, importance, and the goodbye of 

The best way to start understanding what 

are would be by first trying to understand component renders in Angular and how really does the compiler play a role here.

So just for a visual understanding of what we are talking right now, I have added below a snapshot of the component declarations inside the root module.

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    RouterModule.forRoot(routes), HttpClientModule
  ],
  entryComponents: [],
  providers: [],
  bootstrap: [AppComponent],
  exports: []
})
export class AppModule { }

Basically, there are two types of component declarations, ones which are included as a reference insides templates, and the other ones which are loaded imperatively.

What does this mean and what is the difference?

When we reference the component inside templates using the component selector, that’s the declarative way of writing components.

Now, the browser doesn’t really understand what 

 means, and therefore compiling it down to what browser would be able to understand is exactly the Angular compiler’s job.

The imperatively written template for, for example, 

const el = document.createElement('app-instruction-card');
const cmp = new AppInstructionCardCmp();

renderComponent(el, cmp);

if(ctx.val !== oldValue) {
  cmp.value = ctx.val;
  oldValue = cmp.value;
  ng.updateView(el, cmp);
}

This creates an element with your component name and registers it with the browser. It also checks for change detection by comparing the old Value with the current value and updates the view accordingly.

We write templates declaratively since the Angular compiler does this rendering bit for us.

Now, this is where we we can introduce ourselves to what entryComponents are!

 are the type of components which are imperatively loaded or now that we know what imperative loading means, we can say, entryComponents are those which are not referenced inside the template.

Before Ivy, Angular would create Ngfactories for all the components declared in the template and during the runtime it would enable tree shaking for the components not used. This is why the dynamic components with no Ngfactories could not be rendered and would throw an error like:

 array would then make the factories for these dynamic components available at runtime.

How Angular specifies a component as an entryComponent behind the hood can be in different ways.

Another way of bootstrapping your component can be done using the 

 method wherein we can imperatively define which component to be bootstrapped on the launch of the app in the browser. This is more imperative way to write since you create an element for the component selector and check for change detection.

Using ngDoBootstrap() and using the same imperative code to declare a component bootstraps it and makes it an entry component into the browser.

Now, you’d be wondering that if entryComponents have such a massive role to play in component declaration, why do we as developers see it rarely used?

As we discussed above, entryComponents are mostly specified in two ways, bootstrapping them or defining them in a router definition. But since these happen under the hood, we hardly notice it. However, when working with dynamic components, or web components in Angular, we explicity define the components as entry Components inside the 

, we can define the component inside this array:

Role of entryComponents in smaller bundle sizes?

Alright, think for a minute. When we declare multiple components inside the declarations array of our modules, does that mean all these components will be included inside the final bundle?

 have a role to play. So the answer first of all the above question is NO. All declared components aren’t necessarily present in the final produced bundle. It is if they are specified as entryComponents what decides if they’d be present in the produced bundle.

This basically means that all the routable components will be present in the bundle for sure and also the bootstrap component obviously. This would also include the bundles that are declared inside the templates of other components. However, the tree shaking process will get rid of all the unused components with no reference without having to include them inside the package.

 are mostly explicity defined when dealing with dynamic components, like I said before. This is because there needs to be a reference for the compiler to understand that 

, there is no reference for a particular component in the template or router for now, there is a possibility for it to be rendered dynamically when required. The 

takes care of creating this dynamic component for us but we specify this inside the entryComponents array inside NgModule.

If you have worked with dynamic components before, you might have faced an error like:

Coming to the point why entryComponents are no longer required.

Now knowing why need entryComponents, lets discuss a scenario where in we have created a dynamic component and have added it to the entryComponents array.

This basically means that now since we explicitly declared it as an entryComponent, the tree shaker would not prune this component thinking that it doesn’t have a reference in the template. Also, specifying it as an entryComponent would create a component factory for this dynamic component.

First, the entryComponent for a particular dynamic component could be added automatically whenever a dynamic component was created to be used. So this would save the developer from specifying it everytime to make sure the compiler knows the component. One more issue with using entry component was referencing the entryComponents declared inside a lazily loaded module. So if a lazy loaded module contains a modal component as an entry component, you’d face an error like 

No component factory found for this component.

 This was because the root injector couldn’t be referenced to create a component factory for the entryComponent. One solution, though not very promising was creating a component resolver factory yourself for a particular entry component inside the lazy loaded module to be able to execute it.

With Angular 9 coming in and Ivy as the new rendering engine

, all the components would be considered as 

 and do not necessarily need to specified inside the entryComponents array.

With Ivy, the components will have locality and this means that dynamically importing these dynamic components will always work regardless of presence of entryComponents or ANALYS

This is because NOW, there would be no Ngfactories at all. Rendering the component is based on the static properties θcmp and θfac.

See the update from the Angular official documentation here:

https://next.angular.io/guide/deprecations#entrycomponents-and-analyz

A demo here shows how entryComponents are longer required with Angular 9

https://ng-run.com/edit/bY1pxzWwKrEqPOjevXnS

In this blog post, we discussed the role of 

 in Angular applications. We saw how before Ivy, we needed to add all the 

 to ensure that its NgFactories are available at the runtime, and we saw how after Ivy, we do not need entryComponents at all since we do not need to have 

Some more references to be curious about:

<h1 data-node-type="titlePlaceholder" class="titlePlaceholder">Bye bye, entryComponents?</h1><figure class="photo figure-position-inline"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20200429154921046_ales-nesetril-Im7lZjxeLhg-unsplash.jpg" attachmentid="2a3b7ab6-e85e-4d9e-81fa-4b29a033c560" contenteditable="false" data-width="4846" data-height="3431"><div></div></figure><p>With angular 9, there has been a lot of talking going on around entryComponents, and the Angular developers who had not been much aware of entryComponents have now been interested in knowing more about it.</p><p style="line-height: 32px;" id="12d9">In this blog post, I will try to cover everything that might help you clear up all the thoughts you have around the usage, importance, and the goodbye of&nbsp;<strong>entryComponents</strong>.</p><h1><a name="introduction">Introduction</a></h1><p style="line-height: 32px;" id="961f">The best way to start understanding what&nbsp;<strong>entryComponents&nbsp;</strong>are would be by first trying to understand component renders in Angular and how really does the compiler play a role here.</p><p style="line-height: 32px;" id="8ae5">So just for a visual understanding of what we are talking right now, I have added below a snapshot of the component declarations inside the root module.</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-qbowN" id="cm-qbowN">@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    RouterModule.forRoot(routes), HttpClientModule
  ],
  entryComponents: [],
  providers: [],
  bootstrap: [AppComponent],
  exports: []
})
export class AppModule { }</textarea><p>Basically, there are two types of component declarations, ones which are included as a reference insides templates, and the other ones which are loaded imperatively.</p><h2><a name="what-does-this-mean-and-what-is-the-difference?">What does this mean and what is the difference?</a></h2><p style="line-height: 32px;" id="e0cc">When we reference the component inside templates using the component selector, that’s the declarative way of writing components.</p><p style="line-height: 32px;" id="1ee0">Something like this:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-iqhga" id="cm-iqhga">&lt;div class="container"&gt;
&lt;app-instruction-card [value]="'answer'"&gt;&lt;/app-instruction-card&gt;
&lt;/div&gt;</textarea><p>Now, the browser doesn’t really understand what&nbsp;<code>app-instruction-card</code>&nbsp;means, and therefore compiling it down to what browser would be able to understand is exactly the Angular compiler’s job.</p><p style="line-height: 32px;" id="c12b">The imperatively written template for, for example,&nbsp;<code>app-instruction-card</code>&nbsp;would look something like this:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-BD0hA" id="cm-BD0hA">const el = document.createElement('app-instruction-card');
const cmp = new AppInstructionCardCmp();

renderComponent(el, cmp);

if(ctx.val !== oldValue) {
  cmp.value = ctx.val;
  oldValue = cmp.value;
  ng.updateView(el, cmp);
}</textarea><p>This creates an element with your component name and registers it with the browser. It also checks for change detection by comparing the old Value with the current value and updates the view accordingly.<br>We write templates declaratively since the Angular compiler does this rendering bit for us.</p><p style="line-height: 32px;" id="2cc4">Now, this is where we we can introduce ourselves to what entryComponents are!</p><blockquote><p style="line-height: 44px;" id="50ae"><strong>entryComponents</strong>&nbsp;are the type of components which are imperatively loaded or now that we know what imperative loading means, we can say, entryComponents are those which are not referenced inside the template.</p></blockquote><p style="line-height: 32px;" id="a4b7">Before Ivy, Angular would create Ngfactories for all the components declared in the template and during the runtime it would enable tree shaking for the components not used. This is why the dynamic components with no Ngfactories could not be rendered and would throw an error like:</p><p></p><p>No component factory found for a <code>my-dynamic-component</code></p><p style="line-height: 32px;" id="571f">Adding the component to the&nbsp;<code>entryComponents</code>&nbsp;array would then make the factories for these dynamic components available at runtime.</p><p style="line-height: 32px;" id="2475">How Angular specifies a component as an entryComponent behind the hood can be in different ways.</p><ul><li><p><strong><em>Bootstrapping the component</em></strong>&nbsp;is one of the ways of declaring entryComponents. This renders the root component inside the DOM when we launch the app in the browser.<br>The bootstrap array inside the NgModule defines this entryComponent and lets the compiler know that this component should be launched onto the browser with the bootstrapping of the application.</p></li></ul><blockquote><p style="line-height: 44px;" id="711e">Another way of bootstrapping your component can be done using the&nbsp;<strong>ngDoBootstrap()</strong>&nbsp;method wherein we can imperatively define which component to be bootstrapped on the launch of the app in the browser. This is more imperative way to write since you create an element for the component selector and check for change detection.</p></blockquote><p style="line-height: 32px;" id="72e4">Using ngDoBootstrap() and using the same imperative code to declare a component bootstraps it and makes it an entry component into the browser.</p><ul><li><p>Specifying components in&nbsp;<strong>route definitions<br></strong>This is the other way Angular specifies a component as an entry component. If we look at the routing definitions, we always specify the routable component class in the definitions and this is when the CLI registers all the routable components as entryComponents.</p></li></ul><p style="line-height: 32px;" id="8651">Now, you’d be wondering that if entryComponents have such a massive role to play in component declaration, why do we as developers see it rarely used?<br>As we discussed above, entryComponents are mostly specified in two ways, bootstrapping them or defining them in a router definition. But since these happen under the hood, we hardly notice it. However, when working with dynamic components, or web components in Angular, we explicity define the components as entry Components inside the&nbsp;<strong>entryComponents</strong>&nbsp;array.</p><p style="line-height: 32px;" id="585c">Inside @<strong>NgModule</strong>, we can define the component inside this array:</p><blockquote><p style="line-height: 44px;" id="389a">entryComponents: […]</p></blockquote><h1><a name="role-of-entrycomponents-in-smaller-bundle-sizes?">Role of entryComponents in smaller bundle sizes?</a></h1><p style="line-height: 32px;" id="f3be">Alright, think for a minute. When we declare multiple components inside the declarations array of our modules, does that mean all these components will be included inside the final bundle?</p><p style="line-height: 32px;" id="1172">This is where&nbsp;<strong><em>entryComponents</em></strong>&nbsp;have a role to play. So the answer first of all the above question is NO. All declared components aren’t necessarily present in the final produced bundle. It is if they are specified as entryComponents what decides if they’d be present in the produced bundle.</p><p style="line-height: 32px;" id="b502">This basically means that all the routable components will be present in the bundle for sure and also the bootstrap component obviously. This would also include the bundles that are declared inside the templates of other components. However, the tree shaking process will get rid of all the unused components with no reference without having to include them inside the package.</p><p style="line-height: 32px;" id="ab2d"><strong>EntryComponents</strong>&nbsp;are mostly explicity defined when dealing with dynamic components, like I said before. This is because there needs to be a reference for the compiler to understand that&nbsp;<strong>THOUGH</strong>, there is no reference for a particular component in the template or router for now, there is a possibility for it to be rendered dynamically when required. The&nbsp;<strong>ComponentFactoryResolver&nbsp;</strong>takes care of creating this dynamic component for us but we specify this inside the entryComponents array inside NgModule.</p><p style="line-height: 32px;" id="5ab2">If you have worked with dynamic components before, you might have faced an error like:</p><p></p><h1><a name="coming-to-the-point-why-entrycomponents-are-no-longer-required">Coming to the point why entryComponents are no longer required.</a></h1><p style="line-height: 32px;" id="49cd">Now knowing why need entryComponents, lets discuss a scenario where in we have created a dynamic component and have added it to the entryComponents array.<br>This basically means that now since we explicitly declared it as an entryComponent, the tree shaker would not prune this component thinking that it doesn’t have a reference in the template. Also, specifying it as an entryComponent would create a component factory for this dynamic component.</p><p style="line-height: 32px;" id="a810">First, the entryComponent for a particular dynamic component could be added automatically whenever a dynamic component was created to be used. So this would save the developer from specifying it everytime to make sure the compiler knows the component. One more issue with using entry component was referencing the entryComponents declared inside a lazily loaded module. So if a lazy loaded module contains a modal component as an entry component, you’d face an error like&nbsp;<code>No component factory found for this component.</code>&nbsp;This was because the root injector couldn’t be referenced to create a component factory for the entryComponent. One solution, though not very promising was creating a component resolver factory yourself for a particular entry component inside the lazy loaded module to be able to execute it.</p><h1><a name="however,">However,</a></h1><p style="line-height: 32px;" id="bedf"><strong>With Angular 9 coming in and Ivy as the new rendering engine</strong>, all the components would be considered as&nbsp;<code>entering components</code>&nbsp;and do not necessarily need to specified inside the entryComponents array.</p><h1><a name="why?">Why?</a></h1><p style="line-height: 32px;" id="cb31">With Ivy, the components will have locality and this means that dynamically importing these dynamic components will always work regardless of presence of entryComponents or ANALYS<em>FOR</em>ENTRY_COMPONENTS.</p><p style="line-height: 32px;" id="14e6">This is because NOW, there would be no Ngfactories at all. Rendering the component is based on the static properties θcmp and θfac.</p><p style="line-height: 32px;" id="e1c5">See the update from the Angular official documentation here:</p><p style="line-height: 32px;" id="9c42"><a href="https://next.angular.io/guide/deprecations#entrycomponents-and-analyze_for_entry_components-no-longer-required" rel="noopener noreferrer nofollow">https://next.angular.io/guide/deprecations#entrycomponents-and-analyz</a><em><a href="https://next.angular.io/guide/deprecations#entrycomponents-and-analyze_for_entry_components-no-longer-required" rel="noopener noreferrer nofollow">for</a></em><a href="https://next.angular.io/guide/deprecations#entrycomponents-and-analyze_for_entry_components-no-longer-required" rel="noopener noreferrer nofollow">entry_components-no-longer-required</a></p><p style="line-height: 32px;" id="b54c">A demo here shows how entryComponents are longer required with Angular 9</p><p>https://ng-run.com/edit/bY1pxzWwKrEqPOjevXnS</p><h2><a name="summary">Summary</a></h2><div data-node-type="summary" class="summary-block">In this blog post, we discussed the role of <code>entryComponents</code> in Angular applications. We saw how before Ivy, we needed to add all the <code>dynamic/web components</code> to the <strong>entryComponents array inside NgModule</strong> to ensure that its NgFactories are available at the runtime, and we saw how after Ivy, we do not need entryComponents at all since we do not need to have <strong>Ngfactories </strong>for the components now in Angular.</div><h1><a name="some-more-references-to-be-curious-about">Some more references to be curious about:</a></h1><ul><li><p><a href="https://next.angular.io/guide/entry-components" rel="noopener noreferrer nofollow">https://angular.io/guide/entry-components</a></p></li><li><p><a href="https://github.com/angular/angular/issues/28977" rel="noopener noreferrer nofollow">https://github.com/angular/angular/issues/28977</a></p></li><li><p><a href="https://github.com/angular/angular/issues/28826" rel="noopener noreferrer nofollow">https://github.com/angular/angular/issues/28826</a></p></li></ul>

AUTHOR

Nishu Goel

In this blog post, we discussed the role of entryComponents in Angular applications. We saw how before Ivy, we needed to add all the dynamic/web components to the entryComponents array inside NgModule to ensure that its NgFactories are available at the runtime, and we saw how after Ivy, we do not need entryComponents at all since we do not need to have Ngfactories for the components now in Angular.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Bye bye, entryComponents?

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript