I started using Angular in 2017 when version 4 was released. And I have seen this framework growing since then. In this blog, let’s see why Angular is a framework of Past, Present, and Future.

AngularJS and the Start of Angular

AngularJS was released in 2010 and was one of Google’s first Open Source front-end frameworks. It was open-sourced and lived for 12 years before reaching the end of life in 2022.

AngularJS introduced a new way to write the html templates. It introduced directives like “ng-for, ng-if,” which paved the way for many other frameworks and rendering engines.

The AngularJS team quickly realized it’s difficult to maintain a vast codebase written in JavaScript. And a rewrite of AngularJS called Angular was announced in 2014.

Choosing the best tool for the job

Angular is known for deep diving into the existing tools before picking the best for the job. Let’s see the tools chosen by the Angular team over the years.

Past

When Angular development started, Angular Team decided to use Typescript, which was very new in 2014, and many didn’t like it. Some chose not to use it and moved to another framework where they could use Javascript.

But everyone has realized the true power of Typescript over the years, and most developers now choose and prefer Typescript over Javascript.

2014 was the time many build tools for Javascript started appearing. I remember using Grunt and Gulp. Even when the early version of Angular appeared (2.0), SystemJS was used, and developers had to configure everything independently. With Angular 4.0 Angular team introduced Webpack and CLI, and all the configuration was hidden from the developers. Webpack served as the best and most stable tool over the years. It became a tool trusted by many other frameworks and developers.

There was a time the Angular team considered introducing Bazel as the build tool. Bazel is a great tool, but introducing it might have complicated the development effort, as it is hard to understand. The angular team decided not to take that path.

Present

Angular still uses Webpack and has experimental support for esbuild. The team realized its time to move on and chose other tools better than Webpack.

CLI has improved over the years, enabling smooth migrations between Angular versions. Check out https://update.angular.io/

Future

After considering many build tools, Angular will invest in esbuild, which will be used for building Angular applications.

But vite is the hottest tool now; you said, yes team decided not to use it as it was not the best fit for building Angular applications. Still, it will serve applications using vite when you are doing the dev build.

Rendering Engines

Angular uses a compiler to build and produce the final build output, which generally goes through multiple tools. One of them is the rendering engine; the Angular team has iterated over the rendering engines numerous times, and Ivy is the current generation which has unblocked the Angular team to introduce great features like the Standalone component.

Focus on Reactivity

Past

Angular wanted developers to write more reactive code from Day 1 and chose the best tool present RxJs. For APIs like HTTP and Router, Angular used RxJs internally; even for EventEmitter RxJs Subject was used.

Present

RxJs usage has grown over the years, and more and more developers are using this powerful library. Still, many developers asked for Angular without RxJs. Many want better integration of Angular with RxJs.

Future

The angular team is experimenting with Signals, and there will be a public RFC soon. Signals will reduce the learning curve, which was required for RxJs. Still, it will also introduce APIs to better integrate with RxJs.

Change Detection

Past

Change Detection has always been a very critical part of any framework. The angular team introduced zone.js very early to take care of change detection.

Present

Angular still uses zone.js, but soon it started giving performance issues for large apps, and developers had to figure out how to improve the performance. OnPush change detection strategy is widely used to improve performance. Libraries like RxAngular allow you to disable zone.js but need some refactoring.

Future

We, developers, should focus on writing more quality code rather than caring about change detection. Yes, this is the policy the Angular team has decided to go with. With the introduction of Signals, zone.js will become optional, and you can care less about Change Detection strategies.

Do not leave anyone behind policy.

Angular has a release cycle of 6 months, which means there will be a new major release every 6 months. And the version has support for the next 18 months, which means if you have been on an Angular version for more than 18 months, chances are the version is not supported anymore.

But Angular has your back. For any new version release, Angular CLI offers an automatic migration. You need to run ng update and relax.

You can read the docs to update Angular between multiple versions

ng update

Enter fullscreen mode Exit fullscreen mode

Great Set of features

Over the years, the Angular team has interacted more with the community and worked on some excellent features.

inject function

One of the most loved features of Angular is DI (Dependency Injection). We all love it. With inject, function Angular team made the developer experience even better.

Let’s see an example before and after:

@Component({
  selector: 'app-employee-details',
  templateUrl: './employee-details.component.html',
  styleUrls: ['./employee-details.component.scss'],
})
export class EmployeeDetailsComponent {

  modes$ = this.route.queryParamMap.pipe(
    map((params: ParamMap) => params.get('mode'))
  );
  userName$ = this.route.paramMap.pipe(
    map((params: ParamMap) => params.get('username'))
  );

  employeeId$ = this.route.paramMap
    .pipe(
      map((params: ParamMap) => params.get('employeeId'))
    );
  constructor(private route: ActivatedRoute) { }

}

Enter fullscreen mode Exit fullscreen mode

With inject function

@Component({
  selector: 'app-employee-details',
  templateUrl: './employee-details.component.html',
  styleUrls: ['./employee-details.component.scss'],
})
export class EmployeeDetailsComponent {
  modes$ = inject(ActivatedRoute).queryParamMap.pipe(
    map((params: ParamMap) => params.get('mode'))
  );
  userName$ = inject(ActivatedRoute).paramMap.pipe(
    map((params: ParamMap) => params.get('username'))
  );

  employeeId$ = inject(ActivatedRoute).paramMap.pipe(
    map((params: ParamMap) => params.get('employeeId'))
  );
  constructor() {}
}

Enter fullscreen mode Exit fullscreen mode

Template:

<h1>
   Employee Details for EmployeeId: {{employeeId$ | async}}
</h1>

<h2>Current Mode: {{ modes$ | async }} </h2>

Enter fullscreen mode Exit fullscreen mode

Standalone components

The angular community has been asking Angular Module less Angular for a long time. I still love Angular Modules, it still has their place when structuring your apps, but we can usually work without them. Not having Angular Modules reduces the mental modal and learning curve. So now we have Standalone Components, Standalone Component does not require to be registered with any Angular Modules, and it still has backward compatibility, meaning you can use them in an Angular Module.

import { Component, OnInit } from '@angular/core';
import { MatTableModule } from '@angular/material/table';
import { MatPaginatorModule } from '@angular/material/paginator';
import { MatSortModule } from '@angular/material/sort';

@Component({
  selector: 'app-user',
  templateUrl: './user.component.html',
  styleUrls: ['./user.component.scss'],
  standalone: true, // Standalone flag to differentiate between component with module
  imports:[
    MatTableModule,
    MatPaginatorModule,
    MatSortModule
  ] // you can import Angular Module, Standalone Component/Directive/Pipe here
})
export class UserComponent implements OnInit{

  constructor() {
  }

}

Enter fullscreen mode Exit fullscreen mode

Standalone APIs

To take the Standalone Component experience to the next level, Angular introduced Standalone APIs, its already available for Router and HttpClient, and even libraries like NgRx also introduced the Standalone APIs.

Let’s see the code sample below to use Standalone APIs for Http and Router

providers: [
    provideHttpClient(),
       provideRouter(
      routes,
      withDebugTracing(),
      withEnabledBlockingInitialNavigation() //required for SSR
      withHashLocation(),
      withPreloading( PreloadAllModules),
      withRouterConfig({
        onSameUrlNavigation: 'reload',
      })
    ),
]

Enter fullscreen mode Exit fullscreen mode

Standalone Component Migration

Of course, we now have Standalone Components but think about the effort you and your team have to go through to convert all components to Standalone, dont worry; the Angular teams have your back, run the below command and migrate all components, directives, and pipes to Standalone, Happy migration.

ng generate @angular/core:standalone

Enter fullscreen mode Exit fullscreen mode

functional guards

Router guards are great, but we had to write a service every time we had to write a guard. It all changed with the introduction of the functional guard. Guards can be a function now. No need to write a class anymore.

const authGuard: CanMatchFn = () => {
  const authService = inject(LoginService);
  const router = inject(Router);

  if (authService.isLoggedIn) {
    return true;
  }

  return router.parseUrl('/login');
};

Enter fullscreen mode Exit fullscreen mode

New Image Directive

It’s 2023, and images are among the most critical reasons for bad LCP(Largest Conentful Page). You dont need to care about this anymore with the introduction of the NgOptimizedImage directive.

Listening to Community

Optional ZoneJS

If you are an Angular developer, you know what zone.js is. It is responsible for all the magic in Angular around change detection.

But it starts giving performance hits in large enterprise applications, and enterprise is where Angular shines.

Finally, we will have an optional zone for our Applications. Signals are coming to Angular, and it will make zone.js optional, and a good thing it’s backward compatible. It means you can still have an existing app with zone.js and run these new components, which are signals side by side. There are ways to disable zone.js, but it’s not very straightforward.

In the below sample signals: true property will land soon, but not available with 16.0.0-next.7 version

import { Component, signal } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-counter',
  standalone: true,
  signals: true, // you can still try this code by commenting this line
  imports: [CommonModule],
  templateUrl: './counter.component.html',
  styleUrls: ['./counter.component.scss']
})
export default class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(n => n + 1);
  }

}

Enter fullscreen mode Exit fullscreen mode

<p>counter works!</p>
{{ count() }}

<button (click)="increment()">Increment</button>

Enter fullscreen mode Exit fullscreen mode

But Signals will bring more than just optional zone.js. you can read more on the RFC

https://github.com/angular/angular/discussions/49685

• [Complete] RFC: Angular Signals🚦 · angular angular · Discussion #49685
• [Complete] Sub-RFC 1: Signals for Angular Reactivity · angular angular · Discussion #49684
• [Complete] Sub-RFC 3: Signal-based Components · angular angular · Discussion #49682
• [Complete] Sub-RFC 2: Signal APIs · angular angular · Discussion #49683
• [Complete] Sub-RFC 4: Observable and Signal Interoperability · angular angular · Discussion #49681

SSR in Angular has many issues today. SSR in Angular is less famous than other React or Vue-based SSR frameworks. The Angular team has started improving the SSR experience and released the first feature.

Minko Gechev

@mgechev

We just landed hydration in Angular! You can try it in the prerelease of v16 on Wednesday 🔥

- No flicker due to rerendering when using SSR
- Better Core Web Vitals. 45% improvement in LCP based on early testing

github.com/angular/angula…

18:49 PM — 04 Apr 2023

Typed Forms

Angular has types of forms ReactiveForms and Template Driven forms. The community wanted forms to be typed for a long time, and it finally landed in Angular 14.

Yes, you can create typed forms now, and chances are you are already using them.

form: FormGroup = this.fb.group({
    name: new FormControl<string>(''),
    salary: new FormControl<number>(0),
    age: new FormControl<number>(0),
    dob: new FormControl<Date>(new Date()),
  });
constructor(private fb: FormBuilder) {}

Enter fullscreen mode Exit fullscreen mode

Conclusion

I tried to summarize all the fantastic things Angular is going to bring to you as a developer. I am looking at a great future investing in Angular as I did six years ago when I picked up Angular and transitioned from a .Net developer to Angular Developer.

Investing my time in learning and supporting the Angular framework was worth it in the Past, which is still rocking in the present, and I am sure with features like Signals, it will keep shining in the future.

This article is published w/ Scattr ↗️

I had planned an Angular Course for the community for a very long time, last year I even decided to stream it. But all efforts were unsuccessful.

There was too much in my plate, I decided to move to a new country, which caused lot of changes in my plan.

New Plan

I decided to publish it around May again, but due to other factors and depression. I decided to put it on hold again. The plan was to publish it as paid course, but with pay what you want model.

Finally Publishing It

I decided to leave my job in the mid July, which gave me some free time. I decided to utilize this free time and publish the course.

Why this course is Free

Lot of people may have this question why free, when I had decided to make it paid.

There is one reason — community, Last 7 months were really rough for me, staying away from your loved ones is hard, specially when they are stuck in different country and you can not visit them.

During this time, I got so much support from community, I decided to do something in return.

This is my small way to say think you for everything you all have done for me.

Where to get this course

You can access it on YouTube

What if you want to pay

This course will remain free forever, but if you decide to support my work, so I can invest more time creating content for community, you can use GitHub Sponsors link below:

Sponsor @santoshyadavdev on GitHub Sponsors

Finally thanks to some amazing folks for sponsoring me:

• Chau Tran — https://twitter.com/Nartc1410
• Anand Chowdhary — https://twitter.com/AnandChowdhary
• Sunil — https://twitter.com/sunil_designer
• Trung Vo — https://twitter.com/tuantrungvo
• Umair Hafeez — https://twitter.com/_UmairHafeez_
• Pavan Kumar Jadda — https://twitter.com/pavankjadda
• Pabio — https://twitter.com/PabioHQ
• Maarten Tibau — https://twitter.com/maartentibau

This article is published w/ Scattr ↗️

This is Learning was started in 2020 by @layzee. I presented how we built this community at the GDE summit in Berlin in Jan 2023. Over the last 3 years, this-is-learning and this-is-angular have grown over 150+ contributors and more than 2.5M views.

How It Started

In 2020 @layzee had a vision of starting a publication that is free and open to everyone. And he wanted to ensure everyone was free to express their views, and there should not be any gatekeeping.

I also joined the publication when it started, so I was one of the early contributors to this community.

Joining TIL as Co-Founder

In 2020 I was running my show called Tech Talks with Santosh, where I was streaming every week. After doing it for a year, I was getting burned out. I also called my friend Amandeep, and he suggested it’s better to collaborate as you won’t be able to scale it up.

When I was thinking about collaboration, there are 2 things I can do.

• Onboard someone to run Tech Talks with Santosh together, but the show was in my name, and I wanted to keep using this channel in the future.
• Collaborate with @layzee as I have known him since 2019, and admire his work for the community.

I decided to reach out to Lars and proposed that I join this-is-learning, and Lars was convinced, as we can focus on more areas other than blogs.

During our call, we exchanged thoughts on the values of the community,

• We both wanted to ensure we kept the community free from any influence from outside.
• Which means we will never take sponsorship.
• Anyone interested in sharing knowledge can join the community with no gatekeeping.
• Keep the bar low. No one needs to be an expert to join our publication; dedication and effort matter.

Other Initiatives

After joining the this-is-learning as co-founder, we decided to bring more initiatives to grow the community.
We started

• This Is Tech Talks Podcast (https://www.youtube.com/@ThisisTechTalks)
• This is Learning Newsletter (https://thisislearning.substack.com/)
• Community Discord Server (https://discord.gg/REY2x8SJYk)
• This is Angular guides (https://this-is-learning.github.io/rxjs-fundamentals-course/)
• NgRx Essentials (https://this-is-angular.github.io/ngrx-essentials-course/)
• RxJS Fundamentals (https://github.com/this-is-learning/rxjs-fundamentals-course)

How we added more contributors

Growing a community takes work. Our motto was to have a community that promotes Free, open, and honest software education.

To grow the community, we started reaching out to folks on Twitter and LinkedIn, and we reached out to the community members who were already writing blogs.

Reaching out to community members works excellently for us. Most of the community members writing and publishing our blogs came via this channel.

We also got some great contributors, like Deep, who took the initiative and started writing the newsletter, which he has been writing for over a year.

We also have Jay, who joined us as co-host for our podcast.

And 100s of other contributors who are very active in writing for the publication.

Where are we now

The community is growing monthly, and we have seen incredible growth over the years.

The community servers crossed 300 members, and our private discord of contributors struck 150+ members.

The blog post crossed 2.5M reads.

The podcast crossed 350 subscribers and 8k views.

How to join
We run multiple initiatives, and you can help the community in several ways.

• Write blogs for TIL or TIA
• Podcast.
• Newsletter
• Help writing educational content on GitHub (https://github.com/this-is-learning)

If you want to be part of the community reach out to Me or Lars , our community discord is open to everyone.

This article is published w/ Scattr ↗️

Note: Due to NDA, we won’t mention the client’s name.

We finished migrating to Nx from Angular CLI last year, and it was one of the biggest restructure we did. This post will cover why we decided to do it and what we did.

Our challenges

• Code Sharing: We had code shared across the applications. We had most of the reusables as part of our App, and we kept adding more reusable code as part of our main Application.
• Refactoring: We had started perf optimization as mentioned. It was challenging to refactor the codebase in the existing state. It was challenging to determine which part of the code needed to touch. Or where to add a new feature.
• Build Time: Our build time was high; we had to wait a lot of time post every PR/MR. More build time means more time stuck at a task and fewer changes to shipping every release cycle.
• Adding new features: It was challenging to add new features in the App that was already too big.
• Code Review: It was hard to add code owners with a single app holding all the codebase.

The above pain points gave us a clear idea that NxDevTools is the best option for us, and we should go ahead with it.

Why we did it

It was a big decision to move to Nx from Angular CLI. We had a single project for the main app created using Angular CLI and some smaller separate applications within the same workspace before migrating to Nx. It was like a massive piece of code sitting inside a single code base, so we had a lot of challenges migrating, and even more if we never migrated to Nx.

When I joined the team, there was a decision to tackle the performance issues in the App, so we had a lot of refactoring of code coming soon.

What is Nx

Nx is a DevTools for managing mono-repos. The advantage of using mono-repos is you can create and manage multiple applications inside a single workspace and maintain/share libraries.
Nx does more than a mono-repo. It gives you access to the devkit to write your generators and builders/executors (custom command).

Nx also provides caching for your builds, so you don’t have to compile your unchanged code every time you run your build. And Nx Cloud is a fantastic product if you want to get the caching advantages on your CI pipeline.

Concern before we started

Before starting the migration, it was essential to identify what part of the code needed to be moved from App and created as libraries.

We decided to do the following:

• Breaking everything was not what we wanted to do. We decided in the first iteration we would only move a big folder named common/legacy, which had a most reusable code base, and create a new library.
• As soon as we moved the large legacy folder to another library, we ended up with another issue. The plan to move legacy code was the right choice in the end. The problem was an increase in the bundle size, and it grew exponentially. And we couldn’t go ahead with this.

We were on the drawing board again, and we decided to assemble and discuss.
We had the below choices:

• I had used secondary entrypoints in the past. My suggestion was to go with secondary entrypoints.
   — This sounds like the best idea, and I will go with this option in most cases.
   — The problem was we had extensive code to be moved to libraries.
   — If we went with this option, it might have taken us more than a year considering the large codebase, as we had three people team and only me doing this full-time.
• Considering the complexity of Solution one, we decided to go with another solution
   — We decided to use wild card paths in `tsconfig.base.json` like below
  `”@domain/common-legacy/*”: [“libs/common/legacy/src/lib/*”]`
   — This was a good idea as we import only what we need.
   — But it has its challenges

Little about the Solution

We decided to split the entire migration into 3 parts:

- Move the common/legacy and solve the issue we come across.
- Move the rest of the code after the first step is a success.
- Take care of Circular Dependency.

Initial Solution

- We dont need to create secondary entrypoints less work. We can just have folders for each `component/module/service/` etc. And use it as

```
import { HomeModule } from ‘@domain-common-legacy/home.module’
```

- We dont get the entire lib as part of the bundle. We only get the code that we need. Keeping bundle budget under control. And as we move new code, we need to configure the path correctly.

- But it introduced an issue, the libraries created were not buildable. But we decided to move ahead as having buildable libraries was not part of Part 1 of this migration process.

- We decided to disable the Circular Dependency checks.

The Final solution

Once we figured out how our initial Solution works, we decided to go through the codebase, identify all the features we have, and split them into libs.

We identified most of the features we have consist of 3 parts:
- feature/common: Common components/directives used within the feature and other features.
- Core: We lazy load our features, so we don’t end up with a large bloated application. The core-libs consisted of components/services/directives/modules which are part of the lazy-loaded feature and not shared outside.
- State: Every feature has a state, we use NgRx for global state and RxAngular for handling local state, the state library holds the NgRx code for feature and is sometimes shared with other features.

We also decided the shared code will be part of a folder called core so we have
- core/directive
- core/shared-components
- core/state
- core/model

and many more, these libs are used across the libraries and multiple applications inside the organization.

What after creating Libraries

As I mentioned, creating libs was only part one of the entire migration. During this exercise, we figured out a huge chunk of state management/ NgRx code with our main bundle.

We decided we could parallelly handle this by splitting them and only loading the states we need as part of the main code.

We started with around 2.9MB in the main bundle down to 2.30MB with the build for the evergreen browser.

Handling Circular Dependency

Once we were done creating libraries, we ended up with 180+ libraries, which we had started with a single application.

Now it was time to handle the Circular Dependency issues. It was not possible to do it in one go.
So we decided to start with core libs and figured out, that the large codebase responsible for the Circular Dependency issues was part of core-libs, mostly interfaces/services and states.

We kept the Circular Dependency check disabled, even though we were fixing one of the mistakes we made.

We realized we could enable the check for new code, and we enabled the check for an entire repo by adding in the root eslint config and disabled it for all the libs which had Circular Dependency. In this way, now new libraries can only be merged if they dont have a Circular Dependency issue.

We decided to enable the Circular Dependency check for libraries as we kept fixing it.

The Circular Dependency fix required us to create more libraries and finally, we ended up with more than 250+ libraries.

Building Libraries

As we mentioned earlier, one of the issues with the approach as we can not build these libraries.

Our teammate decided to take this matter into his own hands and ended up writing a builder to build all the new libraries created with this approach.

Matt also wrote a Library Generator so we create all the libraries using the same structure, so we don’t end up with entire libs as part of the bundle.

What we achieved

After this migration, we have

• Code Owners: We decided to create a CODEOWNERS file to split the responsibility for code review and which group owns the specific part of the code.
• Custom eslint rules: As a part of our process, we have some checks for our code review process; moving to Nx allowed us to convert all those checks to custom eslint rules, saving more time for us.
• Easy to refactor code: We fix/add a lot of code weekly, and having those libs made our life easier, as now it’s easy to find out which part of the code needs to be touched.

Conclusion

The choice to move to NX worked well for us, and we were able to identify features and move them to libraries, giving us the advantage of having small PRs. Also, we could identify the unused and duplicate code.

Adding custom rules and code owners was a great help for us. We were able to identify the code we needed to review.

Please share your experience on Twitter migrating to Nx and how it helped you.

You can Join Nx Community Slack: https://go.nrwl.io/join-slack

Special thanks to Juri for giving his precious time to review this article. Love you and your work Juri 💙

Shoutout to my [GitHub Sponsors](https://github.com/sponsors/santoshyadavdev)

- [Sunil](https://twitter.com/sunil_designer)
- [Fahad](https://twitter.com/fahadqazi)
- [Digger.dev](https://digger.dev/)

AngularInDepth is moving away from Medium. This article, its updates and more recent articles are hosted on the new platform inDepth.dev

In this blog post, I will talk about a mistake I have made and have seen many developers doing it as well, which is a shared Material Module. I am sure if you used Angular Material, you still have a SharedMaterial Module in your project, time to remove it.

What is my Motivation

I am working on a new project which has many modules. It has more than 20k Lines of Code. I was working on making some modules as Lazy Loaded modules. I realized we are using the SharedMaterial module in all modules. First, I thought it’s ok, but I tried to do an experiment which proved its a bad idea.

Time To Prove Ourselves Wrong

In my last project where we had our custom components like Grid, Tables, Forms and I did ended up using a big Shared Material Module, as all the components were written on top of Angular Material Component. And now it’s time to prove myself wrong that it was not a good approach.

Let’s create a new App, and we will cover what’s wrong with this approach and how it increases the bundle size. We will be using webpack-bundle-analyzer to check the bundle size. Run the below command to create a new App. Make sure you are using the latest Angular CLI

ng new demoapp

next install webpack-bundle-analyzer using the below command

npm i webpack-bundle-analyzer -D

now add the given script in package.json

"analyze": "ng build --prod --stats-json && webpack-bundle-analyzer ./dist/demoapp/stats-es2015.json"

now run the below command to view the stats.

npm run analyze

The above command opens a page, as shown in the image above.

Now, let’s add Angular Material using the below command:

ng add @angular/material

Run the npm run analyze command again and see the main bundle size. It's already increased by around 70 KB without using even a single component from Angular Material.

Now let’s add 2 modules employee and department, respectively, using the below command. We will not lazy load them for the first example.

ng g m employee --routing --module app
ng g c employee --export true
ng g m department --routing --module app
ng g c department --export true

Open app.component.html and replace the default template data with

<app-employee></app-employee>

<app-department></app-department>

If we analyze the bundle again at this point as we hardly have any code, there is a very small change in size, and it has reduced as the default template contains lots of markups and CSS.

Now let’s add some code in both the component, we will copy some code from Material documentation.

Add the below code into department and employee component respectively

One more change is needed in department.component.ts add the below property :

panelOpenState = false;

Now, we need to add some Material module into our employee, and department module as well to avoid the build error, and this is where most of us decide to create a SharedMaterial module like one below.

ng g m shared/material --flat true

and add the below code into the new module:

Now include the newly create MaterialModule into employee and department module.

imports: [
   CommonModule,
   MaterialModule
]

Now run the analyzer again, you can see 216 KB has increased.

Now to optimize the app, the next approach we take is lazy load the modules. Let’s convert the employee and department module to a lazy loaded module.

Remove the EmployeeModule and DepartmentModule from app.module.ts remove the import statement and from the import array as well.

This is the code after removing both modules

Next, configure the employee and department as a lazy-loaded module. Add the below code to app-routing.module.ts

Next, add the below code in employee-routing.module.ts

import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';
import { EmployeeComponent } from './employee.component';

const routes: Routes = [
    { path: '' , component : EmployeeComponent }
];

@NgModule({
    imports: [RouterModule.forChild(routes)],
    exports: [RouterModule]
})
export class EmployeeRoutingModule { }

And similar changes in department-routing.module.ts

import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';
import { DepartmentComponent } from './department.component';

const routes: Routes = [
    { path: '', component: DepartmentComponent }
];

@NgModule({
    imports: [RouterModule.forChild(routes)],
    exports: [RouterModule]
})
export class DepartmentRoutingModule { }

Let’s change app.component.html to use routerLink to lazy-load these 2 modules.

<a [routerLink]="['/employee']" routerLinkActive="router-link-active">Employee</a>

<a [routerLink]="['/department']" routerLinkActive="router-link-active">Department</a>

<router-outlet></router-outlet>

Now run the analyzer again and check the bundle size. After lazy loading, the bundle size should be reduced, but it increased by around 70KB.

Now, let’s remove the Shared Material module and import only the modules which are needed. In employee.module.ts import MatFormFieldModule and MatSelectModule and in department.module.ts import MatExpansionModule and MatFormFieldModule delete the shared module and run the command to analyze the bundle size. In this example, we save around 40KB.

CONCLUSION

I did a similar experiment in my current project and the bundle size was reduced by around 200 KB. Remember when it comes to the web every single KB matters. So, I would suggest and try in your app refactor and share your experience.

GitHub Repo: https://github.com/santoshyadav198613/sharedmodule-demo

Stop Using Shared Material Module was originally published in Angular In Depth on Medium, where people are continuing the conversation by highlighting and responding to this story.

AngularInDepth is moving away from Medium. This article, its updates and more recent articles are hosted on the new platform inDepth.dev

In this blog post we will explore 2 values for providedIn property used with Angular provider Scope.

Introduction

If you are following Angular 9 release, you may have heard about providedIn has few more properties, module injector scope has been possible since version 2, tree-shakable module scope became available in version 6 with providedIn: MyServiceModule,and now we have ‘any’ and ‘platform’ .

Manfred Steyer on Twitter

Did you know, #Angular 9 introduces providedIn:'any': 💥Gives you a separate service instance per lazy module (+ one for 'root') 💥Can replace the need to force consumer to call forRoot and forChild in some cases

In this blog post we will see the example why we needed 'any' and how it is useful. Will leave ‘platform’ for next blog-post.

Tree-shakable Providers

In Angular 6 providedIn property was added to providers, to make services tree shakable. If you are new to Angular, let me give you an simple explanation what we mean by tree shaking. It is a process to remove unused code from our application. It means if you created a service but do not use it, in your application the code will not be part of final production build. To learn more you can refer to this blog post from Lars Gyrup Brink Nielsen:

Tree-shakable Dependencies in Angular Projects

Why the any scope?

So we now know why 'root' was introduced, the idea was to make services tree-shakable. To understand providedIn: 'any' we have to talk a little bit about implementation of forRoot, forChild and lazy loading. If you have used Angular Router or NgRx then you know about these methods.

The problem of working with lazy loaded module is that if we use providedIn: 'root' even though we think we should get a new instance of a service, it gives the same instance and that might not be the behavior we expect. When working with a lazy-loaded module, a new instance should be created when we load the module.

Let’s write some code to see what was the issue earlier and how 'any' resolves that for us.

What we are going to achieve

• A config service which will take some config parameter apiEndpoint and timeout.
• 2 lazy-loaded modules: employee and department. They want to use the config service, but with different values.

The problem with using the root scope

• Create a new Angular 9 app using the below command

npx -p @angular/cli@next ng new providerdemo

• Now let’s create 2 new lazy-loaded modules with components. Run the below commands

npx -p @angular/cli@next ng g module employee --routing --route employee

npx -p @angular/cli@next ng g module department --routing --route department --module app

• Create a new value provider and an interface. You can add it in a new shared folder, as this code will be shared between multiple modules.

• Next, create a new service. We will call it ConfigService which will read the value from token and use it to perform some operation. Use the below command to create it.

npx -p @angular/cli@next ng g service shared/config

• Once created, add the below code to your service

• Now let’s use this service in the Employee and Department Components we created with their respective modules. We are just printing the values received from Token.

• Next, let’s try to pass 2 different configuration for Employee and Department, add the below code into both the modules.

• As seen, the difference is in the config values. Let’s run the application and see what we get. Remember the providedIn value is still 'root'. To test the application in it’s current state, let’s add links to the routes. Add the below snippet in app.component.html

<a routerLink="employee">Employee</a>
<br>
<a routerLink="department">Department</a>
<router-outlet></router-outlet>

• Next, run the application using the below command

npx -p @angular/cli@next ng serve -o

• The application works, but when we click on a link, boom we have an error. Our expectation was to see the different config values, but we have the below error.

So what went wrong here?

We did everything right. Our expectation was to get different config values for both the employee and department components, but we ended up getting an error. This is due to the providedIn: 'root' value. Refer to Figure 1 to visualize what happened.

When we provide the service with providedIn: 'root', it is registered with our AppModule. As soon as we tried to activate one of the routes, the service expected the config value which was not provided. So let’s make it work by making changes to our AppModule.

Add the below code to your app.module.ts

Now the application works, but when we click on the links, we see the below 2 values for both the employee and department components. This is the expected behavior as per Figure 1.

apiEndPoint: 'def.com'
timeout: 5000

What we wanted to achieve

In reality, we wanted something like Figure 2 , where each module has their own instance. With providedIn: 'root', this was not possible.

• To resolve this issues, the previous solution was implementing forRoot and forChild static methods, so each component can have their own instances.
• The other way to achieve this was to provide the ConfigService in each and every module. The problem is then, that the service is no longer tree-shakable.

@NgModule({
  providers: [
    ConfigService,
    { provide: CONFIG_TOKEN, useValue: CONFIG_VALUE }
  ]
}
export class EmployeeModule { }

• Now let’s change the providedIn option for ConfigService to below

@Injectable({
  providedIn: 'any'
})

• Run the application again and notice the console now.

• Bingo, we got the separate instances without implementing forRoot or forChild static methods or compromise regarding tree-shakable providers.

So what happened after changing to providedIn: 'any'? As shown in Figure 3, now all eagerly loaded modules will share one common instance and all lazy-loaded modules will have their own instance of ConfigService.

Conclusion

Earlier for all developers it was a challenge whenever they wanted to make sure they get a new instance of a service for lazy-loaded modules. Now with the 'any' option to provide services in injector scopes, it’s simplest thing to do. We can provide any tokens and developers can provided the values per lazy-loaded module. The service will always create a new instance per lazy-loaded module.

You can download the code from GitHub.

Angular’s ‘root’ and ‘any’ provider scopes was originally published in Angular In Depth on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before you read this article, I want to make it very clear, I am not blaming anyone here. Keeping this in mind, let’s move ahead.

Background

I have been working in Tech Industry from last 11 years, and have seen a big change in technology, I started my career in asp.net web forms era, moved to MVC and then worked with .net Web APIs, and now working with mostly Javascript/Typescript. When I started my career in 2008, I was not even aware of what Open Source means, the only term I had heard was Java is Open Source.

I started contributing to Open Source in 2019, and believe me its fun, and you get to learn a lot while helping many developers across the world. I also received the opportunity to speak at conferences, which I really wanted to, so I can share my knowledge on a bigger stage.

What is the problem

I was working for a big Financial Institution, and all Financial Institutions have strict rules for their employees to get involved in community-related work, which does make sense, as it may create an issue if someone shares some confidential information, which may include the code as well. Even there are developers, contributing to Open Source, who wants to be low profile in their own organization, as they are scared, they will be treated in a different way or the organization may expect something more, like providing free training’s, or working for more hours, rather than investing their time contributing to OSS, and I know few people from the community, they are going through this.

How it can be changed

Time is changing if you see the Octoverse data from 2019, the number of developers is increasing so do developers contributing to open source. See the below stats from 2019.

And all tech companies including Financial Institutions are using and trying to be part of this change. Many financial institutions have Open Source projects, including where I used to work and many startups have there owned Open Source products.

These are few things which Organization especially Financial Institutions should do, to adopt the change to support developers contributing or speaking at conferences:

• Training Sessions: If disclosing some confidential information is a problem, provide the training to developers, who are going to speak at the conference. They should be given training, what they can talk about, how they should present themselves.
• Better Expectations: If an organization is ready to pay 15–20k (per day rate in India), for acquiring the services from outside, to train their employees, than you should not expect your employees to do it for free.
• Support OSS: Only making some projects open source is not enough to support the community. There are organizations with billion $ in profit, using open source projects. But when it comes to supporting those projects they don’t even invest a single dollar.
• Motivate Developers: If you are a Tech lead, rather than asking them “what you get by doing OSS, or writing blog post, you even don’t get paid”, please motivate them to do it, and I have heard from many developers, their tech leads, did used these words, once they came to know about there OSS or blog posts. And the change in this culture should come from management.
• Support Community Driven Conferences: There are many conferences which happen across the world, support them my becoming sponsor, motivate your employees to attend those conferences.

When it comes to the biggest IT companies in the world, Microsoft and Google is Sponsor for almost every other conference around the globe. But the same is not true for others. You can search for any community-driven conference and try to find any other Organization from Top 10, you will see the reality.

Conclusion

Supporting Open Source does not mean, making some projects Open Source, It includes supporting them financially, or helping them fix the issues as well. It also means the employees, who are contributing to Open Source from your organization should be treated better and given the opportunity to showcase their talent. Every organization wants the best developer to work for them, but as an employer, it is your responsibility to help your employees become best too.

Let’s see why we should and how we can use in-memory-db, you can access the source code on GitHub.

Why

Below are two scenarios where you may need in-memory-db.

• POC (Proof of Concept): When you need to create a quick POC for an upcoming project and you want to create an API with NestJS, for integration with a UI.
• Mock: You need to write the test cases and you want to mock the DB operations. This is the perfect use case for using in-memory-db.

How

Follow the below steps to create an API with in-memory-db.

• Run the below command to create a NestJS project.

nest new in-memory-demo

• Once the app is ready, run the below command to install in-memory-db support.

nest add @nestjs-addons/in-memory-db

• We will create a ProductController with CRUD operations, so we will add a module and controller for the same.

nest generate module product
nest generate controller product

• Next, we need an entity. Create a new folder entities inside the product folder.
• Create a new file product.entity.ts and add the below code.

• In the above code, InMemoryDBEntity adds an id property to any interface that extends this interface.
• Next, we need to add some code to the controller and the module. There are two ways in which you can perform CRUD operations, by providing your own implementation or using the built-in InMemoryDBEntityAsyncController or InMemoryDBEntityController.

We will see both approaches, let’s see how to implement our own.

• Open app.controller.ts and add the below code, this file already exists.

You can see in the above code that we have added the below code to provide the Post method.

@Post()
AddProduct(@Body() product: ProductEntity): ProductEntity {
    return this.productService.create(product);
}

• The ProductService is instantiated from InMemoryDBService. It comes with many built-in methods to perform CRUD operations, without writing a single line of code. The service contains two types of methods, sync and async which return an observable.
• In the above code, the below-highlighted code is needed to create an instance of service which takes the entity ProductEntity and provides all methods.

constructor(private readonly appService: AppService,                           private productService: InMemoryDBService<ProductEntity>) {}

The methods that we are going to implement are:

• getAll(): Retrieve all records.
• create(): Insert new records. Use createMany to insert multiple records.
• update(): Update the record for the provided id in the request body.
• delete(): Delete the record for the provided id.
• query(): Query the data from the records added.

Below is the complete code:

Now, in most cases, you just want to provide CRUD operations and if we keep adding the same code, it will cause code duplication and the package keeps that in mind.

It has InMemoryDBEntityAsyncController orInMemoryDBEntityController to achieve the same.

• To implement CRUD operations using the above interface, you can just add the below lines of code.

The InMemoryDBEntityAsyncController provides the implementation for the below methods by default.

• create
• update
• updateMany
• delete
• deleteMany
• get
• getMany

For Feature Modules

In case you have a different feature module, you need to use the forFeature method to register InMemoryDBModule. The below code gives an example of how to use it for ProductModule.

You can also use the feature-specific instances of InMemoryDBService. You need to use the below code in the constructor.

constructor(@InjectInMemoryDBService('product') private productService: InMemoryDBService<ProductEntity>)

Seeding Test Data

For testing, you may need to create some dummy data and we don’t expect you to create all records manually, this is where you can use seed method to create dummy data.

• Create a new Module, Controller, and Entity by using the below command.

nest generate module employee
nest generate controller employee

• Next, add a new entities folder in the employee folder and add a new file employee.ts and add the below code.

• Next, register the InMemoryDBModule for employee Module, add the below code in employee.module.ts

• Final Step is to use seed method to create 10 dummy records.

Next, trigger the seed method by accessing the http://localhost:3000/employee/seed which will create 10 records.

You can update the count, in the below method to create more records.

this.employeeService.seed(recordFactory, 10);

You can use postman to test out the APIs. In the next article, we will see how we can add swagger capabilities to create a test page for testing.

You can refer to the code for this demo at:

santoshyadav198613/nest-in-memory-demo

Conclusion

in-memory-db is widely used in other frameworks like .Net, Java, and Angular to create POCs or create a mock back end.

This package brings the same capability to the NestJS ecosystem and you can easily plugin the same with existing NestJS projects to create POCs.

Thanks to Wes Grimes and the team for creating this package.

Using in-memory-db With NestJS was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my previous piece, we discussed NestJS services. In this piece, we’ll look at the injection scope.

Provider Scope

There are three modes to define the scope. We can either define the scope properties on the service level or module level. It can be used with a class-based and nonclass-based service and with controllers. The three modes are:

• DEFAULT
• REQUEST
• TRANSIENT

The syntax for defining the scope is as below:

For service

@Injectable({
    scope: Scope.TRANSIENT
})

For module

providers : [{
    provide : PRODUCT,
    useValue: Product_Token,
    scope : Scope.REQUEST
}]

For controllers

@Controller({ path: 'product', scope: Scope.REQUEST })

Now that we’e aware of how to use the scope property, let's see each one of them in detail.

The Default Scope

You don’t need to define the scope to DEFAULT. When you don’t define the property, it’s set to DEFAULT, and the instances will be singleton (which means once the connection is established, the same instance will be used for all requests).

For most of cases, like database connection and logger services, singleton is the best option to use.

In the below example, showing a LoggerService in singleton, any controller/service using LoggerService will get the same instance.

The Request Scope

In a REQUEST scope, the same instance will be shared for the same request.

You can see in the below diagram that LoggerService is shared for each request. The GetProduct action and ProductService will share the same instance, and if we try to access an AddProduct action, another instance will be created.

A real-time use case is if we want to share the Request object between the controller and the service for each request.

The Transient Scope

In a TRANSIENT scope, a new instance will be created for every controller or service where we’re using it. The below diagram shows the same scenario where the scope is changed to TRANSIENT. Here a new instance of LoggerService is created for every action and service.

Code

Create a new LoggerService using the below command:

nest generate service Logger

Next, inject the service into the ProductController and the ProductService.

Next, run the application. Change the scope, and see how the scope gets changed in action.

Conclusion

Though it’s OK to have a singleton instance, using REQUEST and TRANSIENT scopes can impact the performance, as per docs.

But there may be scenarios where we need to change the scope — but until you’re sure, just use the DEFAULT scope.

A Deep Dive Into the NestJS Injection Scope was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Service

In enterprise applications, we follow the SOLID principle, where S stands for Single Responsibility.

The controllers are responsible for accepting HTTP requests from the client and providing a response. For providing the response, you may need to connect to some external source for data.

If we add the code to connect to the external source inside, we are not following the single responsibility principle.

To avoid this issue, you use services, which will be responsible for providing some data, which can be reused across the application. It can also hold some validation logic or logic to validate users.

Creating and Using the Service

There are two types of services that can be created in NestJS:

• Class-based Provider
• Non-class-based Provider

Note: If you are coming from Angular, there are high chances you already know these concepts.

Class-based Provider

To create a class-based provider, we can use the CLI command below, the command will create the service inside the product folder.

nest generate service product

In the product folder, you will find two files:

• product.service.ts (For logic.)
• product.service.spec.ts (For unit testing.)

You may end up using multiple services for a feature or even multiple types of providers.

Using a class-based Provider

Now open the product.service.ts file and add the below code, we will move some code from ProductController to ProductService.

As the service is ready now, open product.controller.ts and make the below changes.

The way ProductService is used here is known as dependency injection.

Like Controllers, Services need to be registered as well, the CLI does this for us, you can do it manually by adding it to the providers array of the module.

providers: [AppService, ProductService]

There is more about class-based services which we will cover in upcoming articles.

Non-class-based Providers

We can also create a service that is not a class-based service. There are two types:

• Tokens: We can use string value as the token.
• Factory: Useful when we have a service that needs some data from another service.

Creating tokens

You can create an injection token to use as service, to do that, create a new file product.token.ts inside the product folder and add the below code:

Now open app.module.ts and register the token using the providers property.

import { PRODUCT, Product_Token } from './product/product.token';

providers: [
{
    provide : PRODUCT,
    useValue: Product_Token
}]

Next, open the product.service.ts and let’s use this token and add the below code. This is just for demo purposes, in the real-time application we may want to use this value.

import { Injectable, Inject } from '@nestjs/common';
import { PRODUCT, Product } from './product.token';

constructor(@Inject(PRODUCT) product: Product) 
{
    console.log(product.endPoint);
}

Once you run the application using the value, endPoint will be logged on the console.

Using factory

Factories are another type of provider and are available for a very special use case.

Generally, when we provide a service, they are resolved when the modules are loaded, but there may be instances where we need to create the instance dynamically, this is where we need factories.

For example, getting the database connection, for a client at runtime deciding which database to connect to.

Run the below commands to create two services:

nest generate service dbprovider
nest generate service client

Add the below code in client.service.ts.

Next, open dbprovider.service.ts and add the below code.

In dbprovider.service.ts, here we are using a string property, if you try to run this application, you will get the error as this is not allowed.

We want to create the instance of DbproviderService at runtime, so we need to make one more change. Open app.module.ts and remove DbproviderService from the providers property.

Nest lets us create the factory, create a new file connection.provider.ts, and add the below code.

Here we are creating a new instance of DbproviderService by getting db from ClientService. You can use multiple services here, you just need to pass them comma-separated in useFactory and the same services need to be added in the inject property.

Now we are done with the factory, let’s register and use it. Open app.module.ts and add dbConnectionFactory in the providers property.

Next, open product.service.ts and add the below code.

constructor(@Inject(PRODUCT) product: Product,
    @Inject('ClientConnection') dbProviderService: DbproviderService){
    console.log(product.endPoint);
    console.log(dbProviderService.getProductsForClient())
}

Conclusion

We learned about how to create and use different types of providers in NestJS, we used the dependency injection design pattern to use services, which lets you achieve Singel Responsibility as well.

The services are singleton, but we can also control the scope of Services, which we will see in the next article.

Introduction to NestJS Services was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.