Introduction to the Building Angular applications with NX

Speaker introduction and course overview

What is NX?

Difference between Repository and Monorepo

Repository vs Monorepo

Angular and NX - Why?

Advantages of NX

Disadvantages of NX

First module summary

Introduction

Second module introduction

Short lesson about NX installation methods

NX installation

A quick overview of the default suggested directory structure of NX repository.

NX repository folder layout

Second module summary

How to install NX

How to build a simple application and how to create libraries in NX

Third module introduction

Adding the first app

Adding the first library

Code session for the first application and library in NX.

Time tracker code

Third module summary

The first NX Angular application

What else you can keep in monorepo...? Multiple apps using multiple frameworks, built-in Storybook and Cypress configuration

Fourth module introduction

How can you add more apps to monorepo, which frameworks are available at the time, and advantages of keeping them together

Built-in app types in NX

What are buildable and publishable libraries

Built-in library types in NX

Storybook

End-to-end testing

Fourth module summary

More built-in NX features

This module will present a real-life example of an NX mono repository with multiple libraries and three applications.

Fifth module introduction

Presenting the current module's plan, highlighting crucial backend details for the frontend to illustrate the problem domain.

Backend overview

How to migrate simple existing applications to NX

Migrating backend app to NX

How to extract library with DTOs classes from backend app and prepare it to be shared with frontend application

Extracting shared DTO library

Let's look at how our final application should look like

Design overview

Add new Angular apps to the existing NX repository

Adding new Angular apps to existing monorepo

Adding Storybook to monorepo - different approach

Using previously configured Storybook in this lesson we will create and prepare a few common components that later we’ll use in apps.

Adding common components. Card, Button, Input, List, ListItem

Adding a domain library for RoomList, RoomBackground and RoomTimelineList that I missed in previous lessons

Constructing the services of the application

Constructing the application - Services

Constructing the Admin application

Constructing the Room application

How to prepare the application to work offline

Preparing the Room applications to work offline

Summary of building a real-life application with NX

Lessons learned and homework

Building a real life application with NX

Sixth module introduction

What is the dependency graph in NX, and how does it help you with developer experience

Dependency graph - what is it?

Why it’s important to keep the dependencies organized

Importance of keeping dependencies in order

How to run unit tests and lint only on the affected parts of the dependency graph

Affected

How to deal with the most common examples of circular dependencies

Dealing with circular dependencies

Sixth module summary

Dependency graph

Seventh module introduction

How to automatically migrate simple applications to the NX mono repository

Automatic migration of existing applications

How to manually migrate complex applications to the NX mono repository

Manual migration of existing applications

What may be the problem during migration of big, stale existing codebases

Analysis of potential problems in migration of big existing codebases

Tips. The migration plan

Why defining a target architecture may be an important step of the migration process

Tips. Target architecture

Seventh module summary

Migrating existing applications to NX

What you have learned from this course

Contact info and final words from the author

Final words

Summary

### Challenges and solutions in building large Angular apps

In large Angular applications, developers face several significant challenges. One major issue is managing complexity. These apps have lots of components, services, and modules that all need to work together smoothly. Keeping everything organized and easy to understand can be tough, especially with a big team.

Another problem is build times. As the app grows, it can take longer and longer for changes to show up during development. This can slow down the development process and make it harder to stay productive.

Dependency management is another headache. This involves making sure all the different parts of the app work well together and play nicely with outside libraries. 

### Tool limitations

Even experienced teams can struggle with managing large Angular applications without using the right tools. Organizing numerous components, services, and modules becomes challenging without tools that aid in clarity and team collaboration. Utilizing appropriate tools is key for experienced teams to successfully navigate the complexities of large Angular projects.

### Fixing problems with NX

NX offers several benefits for managing large Angular applications. It helps reduce the time it takes to build projects and keeps code well-organized by managing dependencies and structuring code into reusable parts. This makes it easier to maintain and expand applications over time.

One of NX's strengths is its ability to speed up builds. It does this by remembering previous build results and doing multiple tasks at the same time. This saves developers time and lets them make changes quickly.

NX also comes with tools for testing and checking code quality. It works well with common testing tools and helps keep code clean and consistent. This catches mistakes early and ensures code stays high-quality.

Furthermore, NX makes it easy to work together on projects. It keeps all code and shared parts in one place, making it simpler to share code between different projects or teams. This improves teamwork, reduces problems with combining code, and makes development smoother overall.

Comprehensive guide to Angular and NX: Build, migrate, and decompose your Applications

Learn how to create and maintain Angular applications using NX. 
Designed for Angular developers, this course covers best practices, improving workflow, and migrating existing applications to NX. 
Discover how to configure tools like Cypress for end-to-end testing and Storybook for UI component development. 
By the end of this course, you will have the knowledge and experience to work comfortably with NX on a daily basis.

Building Angular applications with NX

Build a simple time tracker application using NX monorepo.

Create a real-life NX monorepo with three applications. The main goal of these applications is to display the schedule for conference rooms on screens mounted to the doors of the respective rooms.

Build an admin panel as one of the applications to manage the schedule data for the conference rooms.

Use NX graph feature to visualize application architecture.

What is a monorepo approach and how it might help you

Differences between Angular CLI projects and NX projects

How to create Angular applications using NX

How to add Cypress and Storybook to your NX monorepo

How to migrate existing Angular applications to NX monorepo

What is a dependency graph and how to use it to save your time

How to prepare migration even for big and complicated projects

In this lesson, you'll learn what circular dependencies are,
why you should avoid them, and what is the most popular way of solving them.

Circular dependency happens when you have a cycle on the dependency graph. It means that some libraries are dependent on other libraries that are dependent on the first ones, like an infinite loop without any exit condition.

In this case, NX will not be able to build Library 1 or Library 2. If another code depends on that library, building the whole application won't be possible.

Circular dependencies are a popular problem. Luckily, we have methods of solving them, and in this lesson, you'll learn about two of them.

More than two libraries can create a cycle. In fact, there's no limit to the number of libraries taking part in the cycle.

when you have a cycle created by more than three libraries, it may be problematic to fix

, and you should consider refactoring some parts of your code.

Let's create a simple circular dependency. Let's start with a new NX mono repository, then we'll add two libraries:

To generate a new NX mono repository, application, and libraries, I used the commands presented below.

npx create-nx-workspace --pm yarn
yarn add -D @nx/angular
yarn nx g @nx/angular:app apps/app --prefix app
yarn nx g @nx/angular:lib libs/shared/services/auth --prefix auth --buildable --publishable --importPath "shared/services/auth"
yarn nx g @nx/angular:lib libs/shared/components/auth --prefix auth --buildable --publishable --importPath "shared/components/auth"

After generating libraries, it's time for a little cleanup. When everything is prepared, I'll create two files. We don't need to focus on the code, but imports are important.

import {ComponentFactoryResolver, inject, Injectable} from "@angular/core";
import {AuthDialogComponent} from "shared/components/auth";

@Injectable({providedIn: "root"})
export class AuthService {

  private readonly componentFactoryResolver = inject(ComponentFactoryResolver);

  openLoginDialog(): void {
    const factory = this.componentFactoryResolver
      .resolveComponentFactory(AuthDialogComponent);

    // not important code
  }

  closeLoginDialog(): void {
    // not important code
  }

}

import {Component, inject} from "@angular/core";
import {CommonModule} from "@angular/common";
import {AuthService} from "shared/services/auth";

@Component({
  selector: 'auth-dialog',
  template: `
    <button (click)="authService.closeLoginDialog()">Close</button>
    <button>Login</button>
  `,
  standalone: true,
  imports: [
    CommonModule
  ]
})
export class AuthDialogComponent {

  readonly authService = inject(AuthService);

}

If you check the code, you'll notice a simple circular dependency. 

. I visualized the situation in the image below.

---
title: Dealing with circular dependencies
description: How to deal with the most common examples of circular dependencies
code: https://gitlab.com/fullstackio/books/newline-course-apps/building-angular-applications-with-nx-app/-/tree/main/manuscript/code/05.05-circular?ref_type=heads
privateVideoUrl: https://stream.mux.com/twdJY132y9Ty2Bfkx1ssT3JM009hHZHwCV6FMRuAOLXQ.m3u8
---

In this lesson, you'll learn what circular dependencies are,
why you should avoid them, and what is the most popular way of solving them.

## What are circular dependencies

Circular dependency happens when you have a cycle on the dependency graph. It means that some libraries are dependent on other libraries that are dependent on the first ones, like an infinite loop without any exit condition.

![Simple circular dependency](https://d2uusema5elisf.cloudfront.net/courses/building-angular-applications-with-nx/module_06/lesson_06.05/public/images/05-05-01.png)

In this case, NX will not be able to build Library 1 or Library 2. If another code depends on that library, building the whole application won't be possible.

Circular dependencies are a popular problem. Luckily, we have methods of solving them, and in this lesson, you'll learn about two of them.

:::note

More than two libraries can create a cycle. In fact, there's no limit to the number of libraries taking part in the cycle.

In my experience, **when you have a cycle created by more than three libraries, it may be problematic to fix**, and you should consider refactoring some parts of your code.

![More complex circular dependency](https://d2uusema5elisf.cloudfront.net/courses/building-angular-applications-with-nx/module_06/lesson_06.05/public/images/05-05-02.png)

:::

## How to create a circular dependency

Let's create a simple circular dependency. Let's start with a new NX mono repository, then we'll add two libraries:

-   `shared/services/auth` - library with service `AuthService` containing two methods: `openLoginDialog()`, which is dynamically creating the `AuthLoginDialog` component, and `closeLoginDialog()`, which closes the dialog.
-   `shared/components/auth` - library with component `AuthLoginDialog`, which uses `AuthService` to close the dialog.

To generate a new NX mono repository, application, and libraries, I used the commands presented below.

```bash
npx create-nx-workspace --pm yarn
yarn add -D @nx/angular
yarn nx g @nx/angular:app apps/app --prefix app
yarn nx g @nx/angular:lib libs/shared/services/auth --prefix auth --buildable --publishable --importPath "shared/services/auth"
yarn nx g @nx/angular:lib libs/shared/components/auth --prefix auth --buildable --publishable --importPath "shared/components/auth"
```

After generating libraries, it's time for a little cleanup. When everything is prepared, I'll create two files. We don't need to focus on the code, but imports are important.

```typescript
import {ComponentFactoryResolver, inject, Injectable} from "@angular/core";
import {AuthDialogComponent} from "shared/components/auth";

@Injectable({providedIn: "root"})
export class AuthService {

  private readonly componentFactoryResolver = inject(ComponentFactoryResolver);

  openLoginDialog(): void {
    const factory = this.componentFactoryResolver
      .resolveComponentFactory(AuthDialogComponent);

    // not important code
  }

  closeLoginDialog(): void {
    // not important code
  }

}
```

```typescript
import {Component, inject} from "@angular/core";
import {CommonModule} from "@angular/common";
import {AuthService} from "shared/services/auth";

@Component({
  selector: 'auth-dialog',
  template: `
    <button (click)="authService.closeLoginDialog()">Close</button>
    <button>Login</button>
  `,
  standalone: true,
  imports: [
    CommonModule
  ]
})
export class AuthDialogComponent {

  readonly authService = inject(AuthService);

}
```

If you check the code, you'll notice a simple circular dependency. `AuthService` imports `AuthDialogComponent` from `shared/components/auth`, and `AuthDialogComponent` imports `AuthService` from `shared/services/auth`. I visualized the situation in the image below.

galczo5

In this lesson, you will learn what circular dependencies are, how to create

them, and what's more important, how to fix them.

Circular dependency happens when you have a cycle on the dependency graph.

So, let's consider that you have two libraries.

To build library one, you need to import component two from library two.

And to build library two, you have to import component one from library one.

You cannot build library one without library two, and you cannot build library

And circular dependencies are a popular problem, not only in NX, but in front

Luckily, we have methods of solving them, and in this lesson, you learn about

It's worth mentioning that more than two libraries can't create a cycle.

In fact, there is no limit of number of libraries taking part in cycle.

What is important that every time you have that strange loop on the graph.

So, let's create some circular dependencies.

I'm going to start by creating a new NX monorepo.

Then I will add necessary dependencies for NX Angular.

I will generate a new app and two libraries.

First library will be called shared services.

So, the difference is that the library will contain a service that will mock

The second library will be called shared components.

So, the difference is between services and components.

And the second library will contain component called "of dialog".

So, service will dynamically create a component, a dialog component,

that will use the same service to close itself on close function.

All the comments that I'm going to execute, you see on screen,

I will clean up a little bit the monorepo, and then we will start adding some

So, everything was generated in my app's directory.

I have my app, and in my leaps directory, I have two more libraries called

And inside both of them, I have "of library".

So, let's list "leaps shared components of".

As you can see, it's just a standard library.

Let me switch to the IDE, and I walk you through the code that generates a

And as you can see, I removed "generated code", and I have "of service.ts" file

I have "open login dialog", that is using component factory resolver to create

We should only focus on dependencies between libraries.

So, let's go to the "of dialog" component.

As you can see, we have that red wave here, and it means that there is

So, it's "leaps shared component of source sleep and of dialog component".

And it's a simple component that is using "of service".

So, we have a circular dependency between "shared components of" and "shared

because I'm using this method "close login dialog".

The last part, in my app, in app component, I'm injecting that "of service"

So, now we can go to our console, and we can type a build comment and check how

So, I have "yarn and xrun app build with configuration production".

And as you can see, immediately, we have an error that says that "build command

executed", because there is a circular dependency.

And you can even check the dependency chain that creates a cycle.

So, we have "app build" to "shared services out" to "shared components out" and

How to solve a circular dependency problem?

I promise you two methods today, so first one is merging libraries.

If you merge two libraries, for example, "shared services out" and "shared

if you merge them, there is no circular dependency, because you have only one

And I know that it's not the perfect solution, like we very often don't want to

we want to have it separated for, for any other channel reasons, we want to

And you can even imagine if you will use merging libraries method to solve

problem, you will end with one huge library.

To sum up, the biggest disadvantage of this method is that it's bad for code to

If you created two libraries, most often you want to have two libraries instead

So the second method is by splitting libraries.

So you can take the problematic part and split it to the first library.

And both "shared services out" and "shared components out" will depend on that