DEV Community: Valentine Awe

Antenatal for ng new - The mother of all angular applications both dead and alive

Valentine Awe — Fri, 27 Aug 2021 00:23:09 +0000

Before we start, I would like to state that the concepts in this article are not restricted to the Angular framework alone, but can be applied to other frontend frameworks and libraries like Vue and React.

Why antenatal?

Antenatal in the human world relates to the medical care of women when they are expecting a baby. In our case, ng new is the mother while our yet be created application is the baby.

ng new : The mother of all angular applications dead and alive.

Why this phrase? this is simply because almost all angular applications started with our glorious command ng new. ng new has birthed thousands of applications both the ones currently in development, the ones in production, the ones they have stopped using and the ones that never made it to production.

The whole idea of antenatal is to ensure that complications are avoided during the pregnancy and delivery process. This directly applies to what you need to do before birthing a new application.

The antenatal care for the ng new refers to the requirement gathering, research processes, documentation and all that you need to do before you start or create your frontend application.

Why Should you Care?

Below are some of the reasons why you would need to do the initial research and documentation of your frontend application before spinning up the project.

planning the architecture of your application
Decision on the numbers of resources needed
Estimating and managing development time
Easy maintainability and hand over
Reduce back and forth with product owners and clients

So, whether you are in the consulting space or you work for a specific company, doing this antenatal across all your products makes your development process extra smooth and seamless.

Consulting

If you fall under this category, there is a chance that you are going to be involved in different types of projects with unique use cases. And it is important to ask the right questions and document all the specific requirements before you start your application.

Company-Specific

If you fall under this category, You may have to do this process once in a while because there may be less frequent changes in your application development processes and policies. But it is also very important to have all these documented so that new employees or consultants can use them as a reference.

I have listed below with explanations and examples, some of the research and documentation (antenatal) you need to do before starting a new application.

It is important to know that this is not a cast in stone. while all the below points are important, you can go ahead and pick the ones that suit your need or you can also add more.

Application overview
Application features
CSS framework
External libraries
Device support
SEO
Analytics tool
Software management methodology
Internationalisation and Localisation
Testing
Deployment (Staging and Deployment)
Communication
Documentation
Storage

1. Application Overview

This is a detailed explanation of what the product entails and it should be simple and very easy to understand by anyone who cares to look at the document.

2. Application features

These are the key feature modules in your application. You can derive them from the functional requirement document. Eg. Transaction Management, User, Dashboard, etc. You can further divide this into features module and shared modules. This could help in making decisions around the structure of your application.

3. CSS Framework

The choice of the CSS framework is one of those things that varies across different products especially when you are working in the freelance or consulting space where each client can have their own preference. Examples include bootstrap, angular material, etc. You can also specify the CSS methodology and the CSS preprocessor.

4. External Libraries

These are external libraries apart from the CSS framework. they could range from your charting library, date/time and other critical libraries for company-specific or individual applications. It is important to always keep track of this and it is more useful for people with near static documentation. your consultants or staff will always know the appropriate permissible library to use when starting new projects or adding a new feature that requires an external library.

5. Device support

While it is important to make your application mobile responsive at any point in time. It is also worthy to document the target browsers, resolution information and whether the application has mobile-specific features or views.

6. SEO

Here, you will specify how you want to improve the SEO of your application. You can specify the strategies. Examples includes server side rendering, dynamic rendering or pre-rendering using tools like scully

7. Analytics tools And Monitoring

You can further categorize this into different types of environments eg. for local Performance analysis, you can specify tools like the source map explorer. For production monitoring, you can use Sentry and Pingdom
for traffic, you can use mixpanel, fb, google etc.

8. Software management methodology

Specify the details of the software management methodology.

9. Internationalization and Localization

You need to specify whether there is a need for internationalization, specify the locals you want to support and the translation tools you are going to use. This is very important as it is easier to implement this during application development. You also need to decide the localization strategy.

10. Testing

You can specify everything about the application testing
eg. The type of testing, test runner (Karma,Cypress), the testing framework (Jasmine,Jest), mocking libraries(Testdouble.js, Jasmine).

11. Deployment

You can define the various deployment strategies and environment. Eg. Whether you will be containerizing your application with tools like Docker, the numbers of environments, server details, type of repositories, AOT or JIT etc.

12. Communication;

This includes things like encryption method, message format. Etc.

13. Storage

This includes general storage information ranging from application local and global storage eg. NGRX, Ankita, Rxjs,NGRX component store, ngrx-slice, session, local, cookies etc. Also, you can include your assets storage.

14. Documentation

This is the actual documentation for you angular application. eg. For components libraries documentation you can specify Story book and also compodoc for the angular application documentation

Summary

I have outlined what I think are the most critical research or document to put in place before you start any new frontend application. I will gladly love to hear your opinion.

Here is a repo that shows a possible structure of your document

Frontend Documentation Guide

Injecting Angular Environment Variables at Build Time

Valentine Awe — Sun, 15 Aug 2021 15:38:38 +0000

In this article, I assume that you are containerizing your Angular application and also have a CI/CD process in place. While the example in the article is also AWS specific, you can use the same principle across other cloud services.

By default, Angular injects the environment variable at the application build time.

The above diagram depicts a regular flow for our application deployment.

Our frontend app. inclusive of the environment variables is pushed to the repo
Our build process picks it up, builds and deploy to our server.

While the above works very well, there are very unique cases where you would be required not to push your environment files to your application repository. If this happens, knowing that angular injects the environment variables at build time, we would need to find a way to inject the environment files during the build process.

Below are unique reasons why you might be required not to deploy your environment files to your repository

1.Extra level of security:
Some companies have policies which prevent them from pushing applications environment variables to their repository whether private repos or not. Although it is worthy to note that the safest way to keep your secret is not to put them in your frontend applications. So, on no account should you place any secret on your Frontend application whether as an environment variable or inside the application.

2.DevOps flow:
There are situations where the parameters of your applications can vary based on different environments, while you may know the specifics for an environment file. e.g the dev environment, the production credentials may be required to be added to your application by your devOps team or your client. In order to avoid them making changes to your application or going through a PR flow (which could be necessary depending on your policies). You would want to isolate the environment file from your application.

3.Multiple instances with dynamic variables:
There are scenarios where you would have a single repository for your application but multiple deployment instances that require different configuration files (environment variable). These types of variables could be styles, images, currency type, app settings, base url and many other variables that differ based on each instance. Below is a depiction.

In the Image above, we have a single application repository that is deployed to multiple instances.

If we follow the flow of having our environment variables in the repository, there would be no way to set different configurations for each of the various instances except we implement the logic of setting variables in the application level based on users, which wouldn't be a 100% perfect solution if we need some configuration on application startup.

In my experience, I was faced with the three (3) situations above.

My Solution

Add the environment path to your .gitignore. this ensures that you do not push your environment files to the repository.
Create a private repo on AWS S3.
a. you can call it (Frontend Env. Variables)
b. Create sub folders for each of your application
c. upload the different environment files. eg (dev, staging and prod)
(In the case of multiple instances with dynamic variables, this should be replicated in each of the environments.
Ensure that our build process has the permission to read from the s3 repository
Modify the buildSpec file to copy the file from the s3 repository to the application root folder during the build process.

s3 folder structure

Buildspec file

 build:
    commands:
      - echo Build started on `date`
      - printenv
      - aws s3 cp s3://frontend-env-variable/payment- application/ src/ --recursive
      - docker build -t payment-app --build-arg IMAGE_TAG=$IMAGE_TAG .
      - docker images -a
      - echo Building the Docker image...
      - docker tag $APP_NAME:latest $AWS_ACCOUNT_ID.dkr.ecr.eu-west-1.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
      - docker images -a
      # - command
  post_build:

Before the docker file is invoked, We already have the environment file copied from the s3 folder to the app folder as seen above in our buildspec file.

For the multi instance scenario with different environment variables in different cloud instances,

Create separate buildspec files for each environment in your application root. eg. (instance1.buildspec.yml, instance2.buildspec.yml) and each of them will have the reference to the corresponding s3 path.
In your AWS CDK or codebuild (or whichever build process you have in place, specify the name of the buildspec file for the specific environment

With the above process, you can successfully

Deploy your application to the repo without your environment files
Have your devOps, client or anyone for each of your business instances that needs to update the environment variables do so.

Just an extra info on what the docker file look file

#building angular App
FROM node:14.0.0 as node

WORKDIR /app
COPY package.json /app/
RUN npm install
COPY ./ /app/
ARG IMAGE_TAG=dev
RUN npm run build -- --prod --configuration $IMAGE_TAG

# building nginx
FROM public.ecr.aws/nginx/nginx:1.20-alpine

# FROM nginx:1.12.2-alpine
COPY --from=node /app/dist/payment-app /usr/share/nginx/html
COPY ./nginx-custom.conf /etc/nginx/conf.d/default.conf

Conclusion

I believe that there are other fun ways to inject your environment variables at build time. While the above works perfectly for me, I am open to know if you have a differ approach in solving this.

Remember that this solution is not cloud environment dependent.

Do not add any secret to your frontend application

ngTemplateOutlet

Valentine Awe — Sun, 08 Aug 2021 13:31:30 +0000

"Magic is just science that we do not understand yet"
...Arthur C. Clarke

This article is part of what I call the magical directives series. In this series, we will unravel the mystery behind some interesting Angular directives. Afterwards, we can add this little magic to our tool box. I call them magical directives because they play a very important role in building reusable components across our Angular applications.

Below are the directives that we will be looking at in this series.

ng-template
ng-container
ng-content
*ngTemplateOutlet

links to other articles in this series are below

The ngTemplateOutlet

In our last article ng-content, We said that we are going to discuss the conditional content projection in this particular article. One of the major draw backs in using the ng-content is the ability to specify default content. What this means is that if a user does not provide the content for a select attribute, that particular content tag will be blank. This is the first problem the *ngTemplateOutlet helps to solve. The *ngTemplateOutlet helps to build configurable components and also helps in the insertion of common template in different sessions of our page.

Let us start with the simple use case for the *ngTemplateOutlet, which is the insertion of a template into different sessions of our page. for example, if you have a repeated icon across your page, instead of creating the image tag or repeating the host html that holds that image, you can create a template with the <ng-template> and then use the *ngTemplateOutlet to reference it in every session that you need to display the icon.

// Template to be used at multiple sessions in our application

  <ng-template #ourIcon>
     <img src="urImage.jpg" alt="someImge">
  </ng-template>

//reference the template across different sessions in our application

  <div>
    <div class="header">
      <ng-container *ngTemplateOutlet="ourIcon"> </ng-container>
       <h1>Our lovely page</h1>
    </div>

    <div class="body">
      <ng-container *ngTemplateOutlet="ourIcon"> </ng-container>
    </div>

    <div class="Footer">
      <ng-container *ngTemplateOutlet="ourIcon"> </ng-container>
    </div>
  </div>

In the example above, we have been able to use the icon template across multiple sessions in our page without re-writing the html, and if we ever want to change the image url, we just have to update the template without touching the sessions where it is used.

The second use case, is for the conditional content projection

// books-view.html

<h2>Our Story Books..</h2>

<ng-container *ngTemplateOutlet="booksTemplate ? booksTemplate : defaultBooks;">
</ng-container>

<ng-template #defaultBooks>
  <div *ngFor="let bk of booklist" class="books-card_default">
    <h1>{{bk.name}}</h1>
    <p>{{bk.author}}  - {{bk.year}}</p>
 </div>
</ng-template>

  //books.view.ts
  import { Component, Input, OnInit, TemplateRef } from '@angular/core';

@Component({
  selector: 'app-books-view',
  templateUrl: './books-view.component.html',
  styleUrls: ['./books-view.component.scss']
})
export class BooksViewComponent implements OnInit {

  @Input() booksTemplate!:TemplateRef<any>
  @Input() booklist = [
    {name:'The young shall grow', author:'some persons', year:'1975'},
    {name:'Without a silver spoon', author:'some body', year:'1407'},
    {name:'Lara the sugar gurl', author:'everybody',year:'1947'},

  ];

  constructor() { }

  ngOnInit(): void {
  }

}

In sample code above, we have defined a view for our lists of books.
First in the books-view .ts file, we are expecting an input of type templateRef

  @Input() booksTemplate!:TemplateRef<any>

and in the .html file we defined another template called defaultBooks

<ng-template #defaultBooks>
  <div *ngFor="let bk of booklist" class="books-card_default">
    <h1>{{bk.name}}</h1>
    <p>{{bk.author}}  - {{bk.year}}</p>
 </div>
</ng-template>

and in our template, we created the template container for the view.

<ng-container *ngTemplateOutlet="booksTemplate ? booksTemplate : defaultBooks;">
</ng-container>

This is simply saying that, hey! we are expecting an input of type templateRef called booksTemplate, If it is provided, then display it, else use the default defined template called the defaultBooks

Now, you can use the books-view in any part of our application in the following ways.

pass in your custom template.

  <app-books-view [booksTemplate]="myCustomeTemplate"></app-books-view>

Allow the default template to be used

  <app-books-view></app-books-view>

Unlike the ng-content, we have been able to provide default values to be projected.

The *ngTemplateOutlet is super useful for creating configurable components.

Two examples of how we can utilize the power of `*ng-templateOutlet` in our books-view

create multiple templates for different use cases, eg. card view, table view, list view. e.t.c and allow the parent component that want to use our books-view to specify the type of view they want, else return default view. Here, we can even go further to automate the views depending on defined condition. Example, you can set the hostlistener to listen to screen sizes, or allow users to select the type of view that they want while you automatically switch between your defined templates (card view, table view, list view).
We can also decide to allow the parent component to send in their own template like we have in the above.

Below is an example of a parent component using our books-view along side with customer templates

<ng-template  #cardView >
   <div let *ngFor="let bk of books" class="books-card">
      <h1>{{bk.name}}</h1>
      <p>{{bk.author}}  - {{bk.year}}</p>
   </div>
</ng-template>

<ng-template #tableView >
  <table>
    <tr>
      <th>Title</th>
      <th>Author</th>
      <th>Year</th>
    </tr>
    <tr *ngFor="let bk of books">
      <td>{{bk.name}}</td>
      <td>{{bk.author}}</td>
      <td>{{bk.year}}</td>
    </tr>
  </table>
</ng-template>

//passing the template to our app-view
<app-books-view [booksTemplate]="cardView"></app-books-view>

As seen above, we have two templates defined by our parent component, the cardView and the tableView. Although we have manually assigned the cardView to the booksTemplate, but we can always dynamically change the value from the .ts file of our parent component as discussed earlier.

Hey guys!.. Isn't that super cool?

But wait.. If you look at the books-view.ts you will see that we have default data (booklist) being used. What if we want to send in our own data but still want to use the default template?.

If you look at the default template, you will notice that it directly has access to the booklist in our .ts file. And that is the same for every template embedded in the ng-template they can access variables in our .ts. We can further create a unique variable that is only accessible to our template alone and not outside of it. This is done by using let keyword as in let-[data].

Example:

<ng-container *ngTemplateOutlet="booksTemplate ? booksTemplate : defaultBooks; context:{$implicit:booklist}">

</ng-container>

<ng-template let-books #defaultBooks>
  <div *ngFor="let bk of books" class="books-card_default">
    <h1>{{bk.name}}</h1>
    <p>{{bk.author}}  - {{bk.year}}</p>
 </div>
</ng-template>

Here, we have defined a variable books that is only accessible by our template, we no longer have direct access to the booklist in our .ts. Where does the let-books get its value from?

The data for the let-books can be gotten directly from the parent
From a default value set in the *ngTemplateOutlet context property
To get the value from the parent

 <app-books-view [booklist]='booklist'></app-books-view>

Here, we are are not passing any template to the books views, this means that we want to use the default template while we are sending our own data to the template. Now, what happens is that

Our books-views will first check if booklist has been passed as an input value.
If the value is passed, it then assign the value of the booklist to let-books through the context
If there is no booklist passed to it, it then assign the data specified in the context to the let-books. context:{$implicit:booklist} which is the default value.

This way, we can successfully send in our own data to books-view while still using the default template.

Same way, if we want to send in our custom template and also allow for dynamic data, we can also declare the template scoped variable with the let

In our parent component

<ng-template let-books #cardView >
   <div let *ngFor="let bk of books" class="books-card">
      <h1>{{bk.name}}</h1>
      <p>{{bk.author}}  - {{bk.year}}</p>
   </div>
</ng-template>

<ng-template let-books #tableView >
  <table>
    <tr>
      <th>Title</th>
      <th>Author</th>
      <th>Year</th>
    </tr>
    <tr *ngFor="let bk of books">
      <td>{{bk.name}}</td>
      <td>{{bk.author}}</td>
      <td>{{bk.year}}</td>
    </tr>
  </table>
</ng-template>

<!-- This allows you to use project your custom template and also pass in the data.   -->
<app-books-view [booklist]='booklist'  [booksTemplate]="cardView"></app-books-view>

Here, we have also added the let-books variable to our custom templates. Whenever we pass in the data to our template, it assigns the value of the data to our context
whose value is then assigned to the let-books

<app-books-view [booklist]='booklist'  [booksTemplate]="cardView"></app-books-view>

You can check out the github rep for the sample code above

https://github.com/valoni01/ng-magical-directives

Conclusion

you can utilize the magical power of the *ngTemplateOutlet, ng-template, ng-content and ng-container to create your own reusable component library while also giving your users the flexibility to customize the components.

Previous: ng-content

ng-content

Valentine Awe — Sun, 25 Jul 2021 11:09:07 +0000

"Magic is just science that we do not understand yet"
...Arthur C. Clarke

Below are the directives that we will be looking at in this series.

ng-template
ng-container
ng-content
*ngTemplateOutlet

links to other articles in this series are below

The ng-content

The ng-content is used to create configurable components. If we use the ng-content tag in our template, the inner content of the tags that define our component are then projected into this space.

//app-modal.html

<div>
  <div class="header"> Amazing Header </div>
  <div class="body">
     <p> Hi Friends! How are you today </p>
  </div>
  <div class="footer">This is our footer</div>
<div>

The sample code above represents a modal. If there is a need to have this modal in multiple places in our application with different styles/content in the body, it means that we will have to create more modals for each of the use cases. This is not a problem for small apps. But imagine when you have to use similar modal in over 5 different places or more with dynamic content in the body. This is where the magical effects of ng-content comes to our aid.

//app-modal.html

<div>
  <div class="header"> Amazing Header </div>
  <div class="body">
    <ng-content> </ng-content>
  </div>
  <div class="footer">This is our footer</div>
<div>

In the sample code above, instead of hardcoding the content of the body, we used the <ng-content> </ng-content> tag.
If other components wants to use the app-modal component with a custom body, the components will project the content inside the app-modal and the content projected will be positioned in the place where we have specified the ng-content tag in the app-modal as seen below.

//app-parent.html

<app-modal> 
   <div>
      <h3> My body intro. </h3>
      <p> The perfect paragraph </p>
   </div>
</app-modal>

Instead of creating multiple modals for different use cases across our application, we are now able to create a single modal component that allows us to project whatever content we want in the body. This process is referred to as Content projection. With this, we can build reusable components for a single project or a reusable component library for all our projects.

There are three types of content projection

Single-slot content projection
Multiple-slot content projection
Conditional content projection

In order to keep our article dry, We will discuss the conditional content projection in the last session of this series *ngTemplateOutlet

The first example above covers the single-slot content projection, where we were only required to project a single dynamic content. What happens if the content of the header and footer are also dynamic?

//app-modal.html

<div>
  <ng-content> </ng-content>
  <div class="body">
    <ng-content> </ng-content>
  </div>
  <ng-content> </ng-content>
<div>

In this case, Angular is going to scream Wooooooooh. Because Angular wouldn't know the exact place to project the content that we are trying to project. The multiple-slot content projection comes to our rescue.

Multiple-Slot Content Projection

The multiple-slot content projection is what allows us to project multiple dynamic content to our component. The ng-content provides us with the select attribute that allows us to specify an identifier for a specific ng-content tag. Below are various ways in which we can achieve this with different selectors.

//app-modal.html

<div>
  <ng-content select=".header"> </ng-content>
  <div class="body">
    <ng-content select="#body"> </ng-content>
  </div>
  <ng-content select="span"> </ng-content>
<div>

Here, we have specified unique selectors for each content that needs to be projected. anytime we want to reuse this modal component, we just need to ensure that we specify a class with the name header, a body with an id of body and also a span tag. When Angular sees this, it will automatically know where to position or project the content that you have projected as seen in the example below.

//app-parent.html

<app-modal> 
   <div class="header"> Our header </div>
   <div id="body">
      <h3> My body intro. </h3>
      <p> The perfect paragraph </p>
   </div>
   <span> The footer</span>
</app-modal>

NOTE: If for some reasons there is an ng-content tag without an identifier (select), it will automatically serves as a default projector for any content that has no identifier.

Other examples of multiple-slot content projection

 //app-modal.html
 <div>
   <ng-content select="[slot=head]"></ng-content>
   <ng-content select="[slot=body]"></ng-content>
   <ng-content select="[slot=footer]"></ng-content>
 </div>

//app-parent.html
<app-modal>
   <div slot="head"> Our header </div>
   <div slot="body"> Our body </div>
   <div slot="footer"> Our footer </div>
</app-modal>

 //app-modal.html
 <div>
   <ng-content select="[head]"></ng-content>
   <ng-content select="[body]"></ng-content>
   <ng-content select="[footer]"></ng-content>
 </div>

//app-parent.html
<app-modal>
   <div head> Our header </div>
   <div body> Our body </div>
   <div footer> Our footer </div>
</app-modal>

you can also use custom components tags/selectors.

 //app-modal.html
 <div>
   <ng-content select="app-head"></ng-content>
   <ng-content select="app-body"></ng-content>
   <ng-content select="app-footer"></ng-content>
 </div>

//app-parent.html
<app-modal>
   <app-head> Our header </app-head>
   <app-body> Our body </app-body>
   <app-footer> Our footer </app-footer>
</app-modal>

Summary

With the ng-content You can build your own reusable components without you worrying about the contents or the styles of the contents the users needs to project.

Previous: ng-container
Next: *ngTemplateOutlet

ng-container

Valentine Awe — Sun, 20 Jun 2021 11:56:07 +0000

"Magic is just science that we do not understand yet"
...Arthur C. Clarke

Below are the directives that we will be looking at in this series.

ng-template
ng-container
ng-content
*ngTemplateOutlet

links to other articles in this series are below

The ng-container

The ng-container is a grouping element that does not introduce a new element in the DOM when used in our template. This means that it does not interfere with the layout and style of your application.

The ng-container is mostly used with the structural directives. However, it serves two major purposes:

Removal of redundant elements
Elimination of invalid HTML code

Removal of Redundant Elements

I am pretty sure that almost every Angular developer at some point in their learning stage encountered the below error

The error is very clear, and it is because we are trying to use two structural directives on the same element. Below is the most common way we try to resolve the error.

Well, while this is a very smart way to get rid of the error, there is a smarter way. Before we move forward, let us take a look at what is wrong with the above method of resolving the error.

Firstly, carefully look at the DOM below. You will notice that there is an empty div before the actual div that holds our values. This extra div has no purpose in our code, which makes it redundant. Also, this solution does not give you a cleaner DOM tree and depending on the structure of your template you may have to nest your styles in order to style the content of your target div i.e the div that holds the value.

This is where the ng-container comes into play. Remember we said that the ng-container does not interfere with the layout and style of you application, because it does not introduce a new element. If we replace our redundant div with the ng-container, below is what we will get when we inspect the DOM

Isn't that cool?.

Another example is using the ng-container to replace inline elements, which also helps to remove redundant elements and make your styling easier.

<div>
   <span> 
      The world is incomplete without you 
   </span>
</div>

In the code sample above, we have redundant inline element span which just holds a value. We can use the ng-container to eliminate the span by replacing the span with the ng-container

<div>
   <ng-container>
      The world is incomplete without you
   </ng-container>
</div>

Now, If you check the DOM tree, It will exactly look like what we have below

<div> The world is incomplete without you </div>

Eliminating invalid HTML

There are sometimes when we make little mistakes in our template without even knowing. But because the browser is our friend, it does a lot of cleaning up for us so that our mistakes do not reflect on our web pages. A typical example is this.

<ul>
  <div *ngFor="let hero of Heroes">
    <li *ngIf="hero.name !== 'val'">
      {{ hero.powers }}
    </li>
  </div>
</ul>

In the above, we used a div inside a list. The browser will ignore this and will successfully render our template without throwing any error. There are many other scenarios where we might be tempted to do something similar in order to get our logic right, but this is not good practice. The ng-container comes in very handy again in eliminating this. see sample code below

<ul>
  <ng-container *ngFor="let hero of Heroes">
    <li *ngIf="hero.name !== 'val'">
      {{ hero.powers }}
    </li>
  </ng-container>
</ul>

With this, if you inspect your DOM, you will notice that you have your list without the interference of any other element as seen with the previous example when we had the DIV.

Summary

With ng-container, we are sure of having cleaner style sheet and elimination of redundant HTML elements across our applications.

Previous: ng-template
Next: ng-content

ng-template

Valentine Awe — Sun, 13 Jun 2021 16:33:05 +0000

Magic is just science that we do not understand yet
...Arthur C. Clarke

Below are the directives that we will be looking at in this series.

ng-template
ng-container
ng-content
*ngTemplateOutlet

The ng-template

The ng-template directive simply represent an Angular template. Angular uses the ng-template under the hood in our structural directives( *ngIf, *ngFor) and ngSwitch. The ngSwitch controls the structural directives (*ngSwitchCase and *ngSwitchDefault ) and it is an attribute directive.

Whenever we use any of these structural directives, Angular does the below.

<!-- Your actual code with a structural directive -->

<div *ngIf="food">
  <p>some interesting contents</p>
<div>

<!-- What Angular does behind the scene-->

<ng-template [ngIf]="food">
  <div>
    <p>some interesting contents</p>
  </div>
</ng-template>

From the above code sample, Angular sees the asterisk (*) in the *ngIf and automatically recognizes it as a structural directive. It then wraps the host element inside an ng-template, this is the same for other structural directives. What makes it more beautiful is that, Angular comments the ng-template directive (as seen in green text in the image below), so the ng-template is never displayed as a tag in the DOM tree.

NB: Angular does not display the content of the ng-template by default. The ng-template only represents a template which you can then decide how you want it to be displayed.

From the image above, Angular converts the `*` into an ng-template which then result to a nested ng-template. Since Angular does not display the content of the ng-template, We will end up with just comments

If you decide to write your structural directives inside the ng-template, you will just have to replicate what Angular does when it sees a structural directive. E.g for *ngIf, it will be <ng-template [*ngIf]=""> </ng-template> As seen in the first code sample above. You can do the same for other structural directives and it will work just fine. Below is an example with ngSwitch.

<!-- ngSwtich with structural directives *ngSwitchCase and *ngSwitchDefault -->

<div [ngSwitch]="food">
    <div *ngSwitchCase="'Beans'"> yeah... Sweet Beans</div>
    <div *ngSwitchCase="'Rice'"> ummm.. Yummy rice</div>
    <div *ngSwitchDefault>No Food Selected</div>
</div>

<!-- ngSwitch with ng-template  -->

<div [ngSwitch]="food">
    <ng-template [ngSwitchCase]="'Beans'"> yeah... Sweet Beans</ng-template>
    <ng-template [ngSwitchCase]="'Rice'"> ummm.. Yummy rice</ng-template>
    <ng-template ngSwitchDefault>No Food Selected</ng-template>
</div>

Using the ng-template can help remove redundant elements from your DOM tree when necessary. As seen in the code sample with the ngSwtich and ng-template, there won't be an extra div created in the DOM tree compare to the first sample without the ng-template. Although, it could sometimes be easier and cleaner in most cases to use the * i.e instead of wrapping the host inside the ng-template.

But wait, there are other interesting ways that you can utilize the magical effect of the ng-template and one of them is with the ngIf-else and ngIf-else-then

Let us take for instance that you are working on an application where you want to display a certain template based on a condition. In this case, you can enclose the templates in an ng-template and add a reference to each template so that whenever a certain condition is met, the corresponding template will be displayed as seen in the image below.

A common use case is when you are waiting for a response from the server and you want to temporary display a loader until you receive the response.

<!-- use case for If else -->
<div *ngIf="result else loading">
   <p>{{result}}</p>
</div>


<!-- our loader template -->

<ng-template #loading>
    Loading ...
</ng-template>

Here, the default display will be 'Loading..' until we get the result from the server.

Summary

The magical effects of the ng-template cannot be over emphasized. In the rest of the series, we will see how to use the ng-template along with the other directives.

Next: ng-container

DEV Community: Valentine Awe

Antenatal for ng new - The mother of all angular applications both dead and alive

Why antenatal?

ng new : The mother of all angular applications dead and alive.

Why Should you Care?

Consulting

Company-Specific

1. Application Overview

2. Application features

3. CSS Framework

4. External Libraries

5. Device support

6. SEO

7. Analytics tools And Monitoring

8. Software management methodology

9. Internationalization and Localization

10. Testing

11. Deployment

12. Communication;

13. Storage

14. Documentation

Summary

Injecting Angular Environment Variables at Build Time

My Solution

s3 folder structure

Buildspec file

Do not add any secret to your frontend application

ngTemplateOutlet

links to other articles in this series are below

The ngTemplateOutlet

The second use case, is for the conditional content projection

Two examples of how we can utilize the power of *ng-templateOutlet in our books-view

Conclusion

ng-content

links to other articles in this series are below

The ng-content

In order to keep our article dry, We will discuss the conditional content projection in the last session of this series *ngTemplateOutlet

Multiple-Slot Content Projection

Summary

ng-container

links to other articles in this series are below

The ng-container

Removal of Redundant Elements

Eliminating invalid HTML

Summary

ng-template

The ng-template

NB: Angular does not display the content of the ng-template by default. The ng-template only represents a template which you can then decide how you want it to be displayed.

From the image above, Angular converts the * into an ng-template which then result to a nested ng-template. Since Angular does not display the content of the ng-template, We will end up with just comments

Summary

Two examples of how we can utilize the power of `*ng-templateOutlet` in our books-view

From the image above, Angular converts the `*` into an ng-template which then result to a nested ng-template. Since Angular does not display the content of the ng-template, We will end up with just comments