Tutorials on Html Template

In this blog post, we will look into what are entryComponents, why is the purpose of entryComponents, why do we no longer need to use them after Angular Ivy.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 entryComponents . The best way to start understanding what entryComponents 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. 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. When we reference the component inside templates using the component selector, that’s the declarative way of writing components. Something like this: Now, the browser doesn’t really understand what app-instruction-card 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, app-instruction-card would look something like this: 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! Before Ivy, Angular would create Ngfactories for all the components declared in the template and as per the NgModule configuration. 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: Adding the component to the entryComponents 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. 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 entryComponents array. Inside @ NgModule , we can define the component inside this array: 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? This is where entryComponents have a role to play. So the answer first of all to 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. EntryComponents 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 THOUGH , 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 ComponentFactoryResolver 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: 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 entering components 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 ANALYSE _FOR _ ENTRY_COMPONENTS. This is because NOW, the presence of the @Component decorator would mean that the factories would be generated for this component and this happens due to the ngtsc compiler which is like a set of TypeScript transformers and these transformers introduce the static properties θcmp and θfac . These static properties are then able to easily access the code required for instantiating a component/module etc. See the update from the Angular official documentation here: https://next.angular.io/guide/deprecations#entrycomponents-and-analyz for entry_components-no-longer-required A demo here shows how entryComponents are no longer required with Angular 9 https://ng-run.com/edit/c8U6CpMLbfGBDr86PUI0 In this blog post, we talked about the need of entryComponents array when dealing with dynamic components or web components before Ivy . However after Ivy , we do not need NgFactories for the components by specifying it in the entryComponents array and the presence of Component decorator provides the code required for the instantiation of the components ensuring that the compiler is aware of the presence of these dynamic/web components .

Building a good, reliable drag-n-drop email editor is hard. Every time we wanted to add one in any of our projects, there weren’t many good options available that were polished and reliable enough for commercial use. After months of search, we decided to build one that can be embedded in any web app within 5 minutes. It’s available on GitHub and npm . Here’s what it looks like: It takes care of all the unsexy and boring stuff that comes with building a reliable and solid email editor / page builder. Things like outputting the correct HTML syntax, and making sure it looks and works fine in all old browsers and email clients (Hey, IE & Outlook =). The easiest way to use Angular Email Editor is to install it from npm or Yarn and include it in your own Angular build process. Next, you'll need to import the Email Editor module in the app module. app.module.ts app.component.ts app.component.html That’s it. This should render a fully functional drag-n-drop editor in your Angular app. Now that we have a fully functional email editor, we need to save the HTML it outputs. The editor exposes a method called exportHtml that converts the user design into HTML. We'll add a button that calls exportHtml. app.component.ts app.component.html While HTML is the final result of the design, you will need to save the work done in the email editor for future use. There are a number of use cases for this such as: Our email editor saves all work in JSON format. You can save the JSON and then pass it when loading the editor again and it will resume from where you left. We'll add a button that calls saveDesign . app.component.ts app.component.html Once you have the JSON saved, you can pass it to the editor using the loadDesign method. app.component.ts app.component.html Check out the live demo here: https://angular-email-editor-demo.netlify.com/ Play with the example implementation: Edit on CodeSandbox You can check out Unlayer’s full documentation for all available options.