DEV Community: Nikos Anifantis

Managing Requests State in Angular with RxJS and Adapters

Nikos Anifantis — Fri, 11 Oct 2024 09:33:34 +0000

Managing the state of asynchronous operations is a common task in Angular applications. Whether you're fetching data from a server, handling errors, or showing loading spinners, it's important to maintain clear control over different states like loading, success, and error.

In this article, we’ll explore how to manage such states using adapters in Angular with RxJS, making it simple to handle server requests and display state directly in the template using the async pipe.

The Problem: Managing Multiple States

When dealing with server requests, we often encounter multiple states like:

Loading: When the request is in progress.
Success: When data is successfully retrieved.
Error: When something goes wrong, like a network or server error.

Typically, you might manage these states manually in your components, which can lead to repetitive code. The goal here is to abstract this logic into a reusable adapter that makes state management clean and consistent.

The Solution: Using an Adapter

An adapter is a reusable utility that helps manage these states without repeating code. Here, we’re going to create a command adapter that can handle the three key states (loading, success, error) and simplify their usage within an Angular component.

Step 1: Defining the Command Adapter interfaces

First, let's define the interfaces for the command adapter. We’ll create a CommandStatus type and a CommandState interface that holds the state of the command:

// @file: interfaces.ts

export type CommandStatus = 'pending' | 'loading' | 'success' | 'error';

export interface CommandState<T, E = unknown> {
  status: CommandStatus;
  error: E | null;
  data: T | null;
}

Step 2: Creating the Command Adapter

Next, let's look at the createCommandAdapter. This function will return an object with specific setters and getters for managing the state transitions.

Let's create a commandSetters function that returns an object with these state transition functions:

// @file: command-adapter.ts

import { CommandState, CommandStatus } from './interfaces';

export function commandSetters<T, E = unknown>() {
  return {
    setPending: (state: CommandState<T, E>): CommandState<T, E> => ({
      ...state,
      status: 'pending',
      error: null,
    }),

    setLoading: (state: CommandState<T, E>): CommandState<T, E> => ({
      ...state,
      status: 'loading',
      error: null,
    }),

    setSuccess: (state: CommandState<T, E>, data: T): CommandState<T, E> => ({
      ...state,
      status: 'success',
      error: null,
      data,
    }),

    setError: (state: CommandState<T, E>, error: E): CommandState<T, E> => ({
      ...state,
      status: 'error',
      error,
    }),

    reset: (state: CommandState<T, E>): CommandState<T, E> => ({
      ...state,
      status: 'pending',
      error: null,
      data: null,
    }),
  };
}

What about getters? Let's create a commandGetters function that returns an object with state selectors like selectData, selectError, and selectStatus:

// @file: command-adapter.ts

// Existing code...

export function commandSelectors<T, E = unknown>() {
  return {
    selectData: (state: CommandState<T, E>): T | null => state.data,
    selectError: (state: CommandState<T, E>): E | null => state.error,
    selectStatus: (state: CommandState<T, E>): CommandStatus => state.status,

    isPending: (state: CommandState<T, E>): boolean =>
      state.status === 'pending',
    isLoading: (state: CommandState<T, E>): boolean =>
      state.status === 'loading',
    isSuccess: (state: CommandState<T, E>): boolean =>
      state.status === 'success',
    hasError: (state: CommandState<T, E>): boolean => state.status === 'error',
    isDone: (state: CommandState<T, E>): boolean =>
      state.status === 'success' || state.status === 'error',

    // TIP: Add more selectors as needed
  };
}

Now, let's combine the setters and getters into a single createCommandAdapter function that returns an object with all the necessary functions:

// @file: command-adapter.ts

// Existing code...

export function createCommandAdapter<T, E = unknown>() {
  return {
    getInitialState: (
      data: T | null = null,
      initialState: Partial<CommandState<T, E>> = {}
    ): CommandState<T, E> => ({
      status: 'pending',
      error: null,
      ...initialState,
      data,
    }),

    ...commandSetters<T, E>(),
    ...commandSelectors<T, E>(),
  };
}

Step 3: Integrating with RxJS

Now that we have an adapter for managing state, we can integrate it into an RxJS stream using withCommandState. This higher-order function wraps any observable (like a server request) and handles the state transitions for you.

// @file: with-command-state.ts

import { Observable, catchError, map, of, startWith } from 'rxjs';
import { createCommandAdapter } from './command-adapter';

export function withCommandState<T, E = unknown>() {
  const adapter = createCommandAdapter<T, E>();
  const initialState = adapter.getInitialState();

  return (o: Observable<T>) =>
    o
      .pipe(
        map((data: T) => adapter.setSuccess(initialState, data)),
        catchError((error: E) => of(adapter.setError(initialState, error))),
        startWith(adapter.setLoading(initialState))
      )
      .pipe(
        map((state) => ({
          ...state,
          isLoading: adapter.isLoading(state),
          isSuccess: adapter.isSuccess(state),
          hasError: adapter.hasError(state),
          isDone: adapter.isDone(state),
        }))
      );
}

Step 4: Using the Adapter in a Component

Now that the heavy lifting is done, let's put it to work in an Angular component. We’ll simulate a server request using RxJS and apply withCommandState to manage the state.

Here’s how you can use it in a component:

// @file: server-request.component.ts

// Existing imports...

@Component({
  selector: 'app-server-request',
  standalone: true,
  imports: [AsyncPipe, JsonPipe],
  template: `
    <h1>Server Request Example</h1>

    @if (serverRequest$ | async; as state) {
      @if (state.isLoading) {
        🕦 Loading...
      }

      @if (state.isSuccess) {
        ✅ Data: {{ state.data | json }}
      }

      @if (state.hasError) {
        ❌ Failed to load data: {{ state.error | json }}
      }

      <!-- TIP: Add more state checks as needed -->

      @if (state.isDone && !state.hasError && !state.data) {
        🤷 No data available
      }
    }
  `,
})
export class ServerRequestComponent {
  private readonly http = inject(HttpClient);

  readonly serverRequest$ = this.http
    .get('https://api.example.com/data')
    .pipe(withCommandState()); // 👈 Apply state management
}

The magic of Angular’s async pipe allows us to subscribe to observables directly in the template and automatically handle unsubscribing. Here’s what happens in the template:

When the request starts, the status is set to loading, and the Loading... message appears.
Once the data is fetched, the status changes to success, and the Data: Server data message is displayed.
If an error occurs, the status changes to error, and the appropriate error message is shown.
Additional checks like isDone can be used to display fallback messages.

This approach keeps your component clean by managing the state transitions in the adapter, and the template naturally reflects the current state.

Benefits of This Approach

Cleaner code: Instead of manually setting loading, success, and error states in each component, the adapter centralizes this logic, making your code DRY (Don’t Repeat Yourself).
Easier testing: By separating state management from your component, you can easily test state transitions in isolation.
Reusability: The adapter can be reused across different parts of your application, making it simple to handle server requests consistently.
Reactive by nature: Leveraging RxJS streams allows you to build reactive UIs that respond to changes in real-time.

Bonus: Using `Angular Signals` and `toSignal()`

If you’re using Angular 18 or later, you can take advantage of the new Angular Signals feature to manage state transitions in your components. Here’s how you can use it with the command adapter:

// @file: server-request.component.ts

// Existing imports...
import { toSignal } from '@angular/core/rxjs-interop';

@Component({
  selector: 'app-server-request',
  standalone: true,
  imports: [],
  template: `
    <h1>Server Request Example with Signals</h1>

    @if (serverRequestSignal(); as state) {
      @if (state.isLoading) {
        🕦 Loading...
      }

      @if (state.isSuccess) {
        ✅ Data: {{ state.data | json }}
      }

      @if (state.hasError) {
        ❌ Failed to load data: {{ state.error | json }}
      }

      <!-- TIP: Add more state checks as needed -->

      @if (state.isDone && !state.hasError && !state.data) {
        🤷 No data available
      }
    }
  `,
})
export class ServerRequestComponent {
  private readonly http = inject(HttpClient);

  readonly serverRequest$ = this.http
    .get('https://api.example.com/data')
    .pipe(withCommandState()); // 👈 Apply state management

  // Convert the observable to a signal 👇
  readonly serverRequestSignal = toSignal(this.serverRequest$);
}

By using toSignal(), you can convert the observable into a signal that can be used directly in the template. Also, we removed the AsyncPipe imports since Angular Signals handle these automatically. This approach is more aligned with Angular’s reactive programming model and simplifies the handling of asynchronous operations.

Of course, you can implement your own custom implementation using Angular Signals directly instead of using the withCommandState operator, but this might be another topic for a future article. 😉

Conclusion

Managing the state of asynchronous operations in Angular doesn’t have to be complicated. By using an adapter and RxJS, we can abstract the logic for handling loading, success, and error states, allowing us to focus on building a clean and efficient UI.

By following the pattern of combining withCommandState with the async pipe, you can keep your components streamlined and handle server requests with ease. This approach is agnostic and can be extended or customized to fit various scenarios in your application.

If you found this article helpful, please support it with your ❤️ to help it reach a wider audience. 🙏

Feel free to reach out if you have any questions—leave your comments below or DM me on X @nikosanif or LinkedIn.

Angular Authentication: Upgrade to Angular 18 🚀

Nikos Anifantis — Tue, 18 Jun 2024 12:19:09 +0000

^{Cover Photo by Gareth Davies on Unsplash.}

An Angular application that demonstrates best practices for user authentication flow.

By @nikosanif

nikosanif / angular-authentication

An Angular application that demonstrates best practices for user authentication & authorization flows.

Angular Authentication

An Angular application that demonstrates best practices for user authentication & authorization flows.

By @nikosanif

Live Demo

Live application: angular-authentication.netlify.app

Getting Started

Prerequisites

Setup & Usage

Clone this repository: git clone git@github.com:nikosanif/angular-authentication.git
cd angular-authentication
Install dependencies: npm install
Serve the Angular app: npm start
Open your browser at: http://localhost:4200

Useful Commands

npm start - starts a dev server of Angular app
npm run build:prod - builds full prod build
npm run lint - linting source code of this project
npm run format:check - runs prettier to check for formatting errors
npm run format:write - runs prettier to format whole code base
npm run release - runs release-it to create new release

Features

Authentication Flows

Other Features

Lazy loading of Angular modules
API requests with @ngrx/effects
Responsive design
Custom In-memory Web…

View on GitHub

The Challenge 🤔

Three years ago, I created an open-source project called Angular Authentication to demonstrate authentication and authorization in Angular applications. The project was built with Angular 13 and featured user authentication & authorization flows, protected routes, etc. However, as Angular has evolved, new versions have been released with performance improvements, new features, and enhanced security. To keep the project up to date and leverage the latest advancements, I decided to upgrade it from Angular 13 to Angular 18.

Upgrading an Angular project can seem overwhelming, especially when spanning several major versions. However, the power of Angular CLI (ng update), the benefits of performance enhancements, new features, and improved security are well worth the effort. In this article, I'll walk you through the process I followed to upgrade an Angular auth open-source project from Angular 13 to Angular 18. We'll cover dependency updates, the adoption of new Angular features, and UI component migration.

TL;DR 🎯

✅ Angular Version: 13 ➡️ 18
✅ Dependencies: Update dependencies to the latest versions.
✅ UI Migration: Try new Angular Material Design Components (Material 3).
✅ Release Management: Migrate to release-it for versioning and changelog generation.
✅ Features: Adopt new Angular 18 features.
✅ Built-in Control Flow: Migrate to the new control flow syntax.
✅ Standalone Components: Utilize standalone components for modularity.
✅ Route Guards: Refactor route guards to functions.
✅ Typed forms: Use typed forms for improved type safety.
🕣 Use Signal APIs: Try migrating to the new signal inputs, signal-based queries, and a new output syntax.
🕣 Zoneless change detection: Remove zone.js as dependency.
🕣 Deferrable views: Use the new shiny feature for deferrable views.

Step-by-Step Upgrade Process 🚀

Initial Setup

[Step.1] ⏩ Visit the Angular Update Guide:

The Angular Update Guide provides detailed steps and information for each version upgrade.

[Step.2] ⏩ Install Dependencies for Node 16:



npm install

[Step.3] ⏩ Switch to Node 18: I used Node Version Manager (nvm) to switch to Node 18.



nvm use 18

Incremental Angular Updates

[Step.4] ⏩ Update to Angular 14:



ng update @angular/core@14 @angular/cli@14 --force

The --force flag bypasses version compatibility checks. We'll manually fix issues later.

[Step.5] ⏩ Sequential Updates:



ng update @angular/core@15 @angular/cli@15 --force
ng update @angular/core@16 @angular/cli@16 --force
ng update @angular/core@17 @angular/cli@17 --force

[Step.6] ⏩ Switch to Node 20:



nvm use 20

[Step.7] ⏩ Update to the Latest Angular Version (v18):



ng update @angular/core@latest @angular/cli@latest --force

Adjustments and Comparisons

[Step.8] ⏩ Create a New Angular Project for Comparison:

Generate a new Angular project with the latest version to compare configurations and identify necessary adjustments.



ng new new-angular-project

[Step.9] ⏩ Update Dev Dependencies:

Update all packages to their latest versions.
Fix any eslint issues.
Test all commands in package.json to ensure compatibility.

Final Angular Update

[Step.10] ⏩ Enforce Node Version 20:

Update the engines field in package.json to ensure Node 20.x is used.



"engines": {
  "node": "20.x"
}

[Step.11] ⏩ Isolate features and components:

Isolate features and start migrating them one by one to Angular 18. This approach helps to identify issues and fix them incrementally. - Use Angular CLI schematics to generate new components and services with the latest Angular 18 features. For example:



ng g @angular/core:control-flow # Migration to the new control flow

UI and Dependency Migrations

[Step.12] ⏩ Migrate UI from TaigaUI to Angular MDC:

Transition to Angular Material Design Components (MDC). Although TaigaUI is a great library, the new Material 3 components are now stable and I decided to try them.
Replace TaigaUI components with MDC counterparts.

[Step.13] ⏩ Remove Deprecated Dependencies:

Remove angular-in-memory-web-api and update the project to use alternative data mocking solutions or real backend services.
Implement a custom HTTP interceptor to handle API requests and responses.

[Step.14] ⏩ Adopt Standalone Components:

Utilize Angular's standalone components feature to simplify module management and improve code modularity.



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

@Component({
  selector: 'app-standalone',
  standalone: true,
  imports: [CommonModule],
  templateUrl: './standalone.component.html',
  styleUrls: ['./standalone.component.css'],
})
export class StandaloneComponent {}

[Step.15] ⏩ Use the new Built-in control flow:

Use the new built-in control flow features introduced in Angular 18 to simplify asynchronous operations and improve code readability. More specifically, use the @if keyword instead of ngIf and @for instead of ngFor.

[Step.16] ⏩ Refactor guards to functions:

Refactor route guards to functions to simplify the code and improve maintainability.



export const canActivate = (
  route: ActivatedRouteSnapshot,
  state: RouterStateSnapshot
) => {
  // Guard logic
};

[Step.17] ⏩ Typed Forms:

Use typed forms to improve type safety and reduce errors in form handling.



loginForm = new FormGroup({
  username: new FormControl(/* ... */),
  password: new FormControl(/* ... */),
});

Other Enhancements

[Step.18] ⏩ Migrate Releases to release-it:

Since the project standard-version is deprecated, I decided to migrate to release-it for versioning and changelog generation.
Simplify the release process with release-it, which automates versioning and changelog generation.



npm install --save-dev release-it

Configure release-it with a .release-it.json file:



{

  "git": {

    "commitMessage": "chore(release): ${version}",

    "requireBranch": ["main"]

  }

  // ... other configurations

}

Future Enhancements 💡

Adopt more new Angular Features: Explore new features and improvements introduced in Angular 18, such as enhanced performance, updated APIs, and improved tooling.
Use Standalone Components: Remove all @NgModule declarations from components and use standalone components for better modularity.
Zoneless change detection: Consider migrating to zoneless Angular to improve performance and reduce overhead.
Use Signal APIs: Explore the new Signal APIs introduced in Angular 18 to simplify asynchronous operations.
Deferrable views: Implement deferrable views to improve rendering performance and user experience.

Conclusion ✅

Upgrading an Angular project from version 13 to 18 involves multiple steps, including updating dependencies, fixing issues, and adopting new features. By following this structured approach, you can ensure a smooth upgrade path and leverage the latest advancements in Angular.

If you found this article helpful, please support it with your ❤️ 🦄 🔖 to help it reach a wider audience. 🙏

Feel free to reach out if you have any questions—leave your comments below or DM me on X @nikosanif or LinkedIn.

Angular Authentication: Best Practices 🏆

Nikos Anifantis — Thu, 11 Nov 2021 08:27:14 +0000

An Angular application that demonstrates best practices for user authentication flow.

By @nikosanif

nikosanif / angular-authentication

An Angular application that demonstrates best practices for user authentication & authorization flows.

Angular Authentication

An Angular application that demonstrates best practices for user authentication & authorization flows.

By @nikosanif

Live Demo

Live application: angular-authentication.netlify.app

Getting Started

Prerequisites

Setup & Usage

Clone this repository: git clone git@github.com:nikosanif/angular-authentication.git
cd angular-authentication
Install dependencies: npm install
Serve the Angular app: npm start
Open your browser at: http://localhost:4200

Useful Commands

npm start - starts a dev server of Angular app
npm run build:prod - builds full prod build
npm run lint - linting source code of this project
npm run format:check - runs prettier to check for formatting errors
npm run format:write - runs prettier to format whole code base
npm run release - runs release-it to create new release

Features

Authentication Flows

Other Features

Lazy loading of Angular modules
API requests with @ngrx/effects
Responsive design
Custom In-memory Web…

View on GitHub

Live Demo

Live application: angular-authentication.netlify.app

Getting Started

Prerequisites

Setup & Usage

Clone this repository: git clone git@github.com:nikosanif/angular-authentication.git
cd angular-authentication
Install dependencies: npm install
Serve the Angular app: npm start
Open your browser at: http://localhost:4200

Useful Commands

npm start - starts a dev server of Angular app
npm run build - builds full prod build
npm run lint - linting source code of this project
npm run format:check - runs prettier to check for formatting errors
npm run format:write - runs prettier to format whole code base
npm run release - runs standard-version to create new release

Features

Authentication Flows

Other Features

Lazy loading of Angular modules
API requests with @ngrx/effects
Responsive design
In-memory Web API

Tech Stack

Angular
NgRX - @ ngrx/{store,effects,component}
Taiga UI
Tailwind CSS
Other dev tools
- ESLint
- Prettier
- Husky
- standard-vesrion

High-level Design

Below is the high-level structure of the application.



./src

├── app

│   ├── app # root app component

│   │   ├── app.component.html

│   │   ├── app.component.scss

│   │   └── app.component.ts

│   │

│   ├── app-routing.module.ts

│   ├── app.module.ts

│   │

│   ├── auth # includes authentication logic

│   │   ├── auth.module.ts

│   │   ├── auth.service.ts

│   │   ├── guards

│   │   ├── interceptors

│   │   ├── login

│   │   └── store

│   │

│   ├── core # includes core utilities

│   │   ├── core.module.ts

│   │   ├── fake-api

│   │   └── services

│   │

│   ├── features # all features of application

│   │   ├── about

│   │   ├── home

│   │   └── secured-feat

│   │

│   └── shared # shared UI modules and utilities

│       ├── ui

│       └── util

│

├── assets

│   ├── ...

│

├── environments

│   ├── environment.prod.ts

│   └── environment.ts

│

├── ...

│

└── theme # global theme styles

    ├── _components.scss

    ├── _typography.scss

    └── index.scss

Contributing

Who is for this? I would love for you to contribute to Angular Authentication! Before you start, please read the Contributor Guide.

If you have found any bug in the source code or want to request a new feature, you can help by submitting an issue at GitHub. Even better, you can fork this repository and submit a PR with the fix or the new feature description.

Support

Star this repository ⭐️
Help it spread to a wider audience: Tweet

Author: Nikos Anifantis ✍️

Fullstack Software Engineer - I’m currently working on Angular & Node.js application development.
I write stuff at dev.to/nikosanif and nikosanif.medium.com
How to reach me:

License

Feel free to use this repository, but please star and put a reference to this repository. 🙏 ❤️

MIT

Generic CRUD Service in Angular: Part 4

Nikos Anifantis — Sat, 16 Oct 2021 11:27:46 +0000

^{Cover Photo by Xan Griffin on Unsplash.}

This article is a part of a series about how to create Generic CRUD Service & Models in Angular:

Part 1 - Understanding Generics
Part 2 - What is CRUD?
Part 3 - Generic CRUD Model
👉 Part 4 - Generic CRUD Service in Angular

Generic CRUD Service

Before we start generating and writing code, let’s take a step back and see the bigger picture. The generic service should accept the following arguments:

the HttpClient is used for the HTTP requests
the class of model for creating instances
the path of the API endpoints.

Also, all resources should have 5 main methods related to CRUD…

Create - Returns a new resource.
Get all - Retrieves all resources as a list.
Get by ID - Returns a specific resource by ID.
Update - Updates a specific resource by ID.
Delete - Removes a specific resource by ID.

Great, let’s create our methods step by step now.

1️⃣ Create

The create() method accepts a partial model as argument and returns the created model from server. We say "partial" because before we create the resource, some properties are not available (e.g. id, createdAt, etc). Also, it converts the result to an instance of model's class.

TIP: All methods try to create instances of model's class in order to apply and benefit extra functionality from them (e.g. convert string dates to actual Date in constructor or for future usage of their methods such as toJson() function).

public create(resource: Partial<T> & { toJson: () => T }): Observable<T> {
  return this.httpClient
    .post<T>(`${this.apiUrl}`, resource.toJson())
    .pipe(map((result) => new this.tConstructor(result)));
}

2️⃣ Get all

The get() method returns an Observable with a list of all existing resources. It accepts no arguments and iterates the list to create multiple instances instead of simple JSON objects.

public get(): Observable<T[]> {
  return this.httpClient
    .get<T[]>(`${this.apiUrl}`)
    .pipe(map((result) => result.map((i) => new this.tConstructor(i))));
}

3️⃣ Get by ID

The next method of "read" is getById(). As is obvious, it accepts as argument an ID of type number and returns an Observable of the existing resource instance.

public getById(id: number): Observable<T> {
  return this.httpClient
    .get<T>(`${this.apiUrl}/${id}`)
    .pipe(map((result) => new this.tConstructor(result)));
}

4️⃣ Update

When we want to update an existing resource, we'll use the update() method. It accepts a partial model (e.g. only properties that we want to update) and returns the updated instance as Observable.

public update(resource: Partial<T> & { toJson: () => T }): Observable<T> {
  return this.httpClient
    .put<T>(`${this.apiUrl}/${resource.id}`, resource.toJson())
    .pipe(map((result) => new this.tConstructor(result)));
}

5️⃣ Delete

Finally, the delete() method removes completely an existing resource from the server by a given ID. It accepts a number as argument that matches the ID of the model, but it does not return anything (Observable<void>).

public delete(id: number): Observable<void> {
  return this.httpClient.delete<void>(`${this.apiUrl}/${id}`);
}

➡️ Final result

Once we described one-by-one all methods, now it's time to see the final result of the generic service:

import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { map } from 'rxjs/operators';

import { ResourceModel } from 'your-path-to-model'; // see: Part 3

export abstract class ResourceService<T extends ResourceModel<T>> {
  constructor(
    private httpClient: HttpClient,
    private tConstructor: { new (m: Partial<T>, ...args: unknown[]): T },
    protected apiUrl: string
  ) {}

  public create(resource: Partial<T> & { toJson: () => T }): Observable<T> {
    return this.httpClient
      .post<T>(`${this.apiUrl}`, resource.toJson())
      .pipe(map((result) => new this.tConstructor(result)));
  }

  public get(): Observable<T[]> {
    return this.httpClient
      .get<T[]>(`${this.apiUrl}`)
      .pipe(map((result) => result.map((i) => new this.tConstructor(i))));
  }

  public getById(id: number): Observable<T> {
    return this.httpClient
      .get<T>(`${this.apiUrl}/${id}`)
      .pipe(map((result) => new this.tConstructor(result)));
  }

  public update(resource: Partial<T> & { toJson: () => T }): Observable<T> {
    return this.httpClient
      .put<T>(`${this.apiUrl}/${resource.id}`, resource.toJson())
      .pipe(map((result) => new this.tConstructor(result)));
  }

  public delete(id: number): Observable<void> {
    return this.httpClient.delete<void>(`${this.apiUrl}/${id}`);
  }
}

Finally, here a working example of users' service:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

import { User } from 'your-path-to-user-model';
import { ResourceService } from 'your-path-to-resource-service';

@Injectable({ providedIn: 'root' })
export class UsersService extends ResourceService<User> {
  constructor(private http: HttpClient) {
    super(http, User, `your-api-of-users-here`);
  }
}

You can find the final source code in stackblitz:

Conclusion ✅

Hooray! We made it to the end! 🙌

I hope you enjoyed this series of article and you will make your applications' code even more generic and reusable following the DRY principle. Also, I hope to use this article not only for the CRUD feature but whenever it's possible in your apps by using generics.

Please support this article (and the previous parts) with your ❤️ 🦄 🔖 to help it spread to a wider audience. 🙏

Also, don’t hesitate to contact me if you have any questions leaving here your comments or Twitter DMs @nikosanif.

Author: Nikos Anifantis ✍️

Generic CRUD Service in Angular: Part 3 - Generic CRUD Model

Nikos Anifantis — Tue, 12 Oct 2021 19:22:37 +0000

^{Cover Photo by Randy Fath on Unsplash.}

This article is a part of a series about how to create Generic CRUD Service & Models in Angular:

Part 1 - Understanding Generics
Part 2 - What is CRUD?
👉 Part 3 - Generic CRUD Model
Part 4 - Generic CRUD Service in Angular

Generic CRUD Model

Once we have walked about the theory of generics (Part 1) and we have understand the main CRUD methods (Part 2), now it's time to see it in action.

Before start to implement the generic service of CRUD. We must define the generic model of all resources.

In this article, we assume that all models have some common properties like id, createdAt, and updatedAt.

Thus, we create a generic abstract class that contains all these common properties.
Also we used the generic T type to identify the model that we are going to extend.

Last but not least, the class is going to apply logic in the constructor about property casting and provide a common method toJson() which allows us to return a pure JSON based on the instance.

Below we can see the full implementation of the generic CRUD model:

export abstract class ResourceModel<T> {
  public id?: number;
  public createdAt?: Date;
  public updatedAt?: Date;

  constructor(model?: Partial<T>) {
    if (model) {
      Object.assign(this, model);
    }
    if (this.createdAt) {
      this.createdAt = new Date(this.createdAt);
    }
    if (this.updatedAt) {
      this.updatedAt = new Date(this.updatedAt);
    }
  }

  public toJson(): any {
    return JSON.parse(JSON.stringify(this));
  }
}

Example

Do you remember the example of user model? Great! The same model will be used here. Below there is an example how we can extend the user model:

export class User extends ResourceModel<User> {
  public firstName!: string;
  public lastName!: string;
  public email!: string;

  constructor(model?: Partial<User>) {
    super(model);
  }
}

// ------ example ------
const johnDoe = new User({ firstName: 'John', lastName: 'Doe', ... });
const johnDoeAsJSON = johnDoe.toJson();

What's next?

Part 4 - Generic CRUD Service in Angular

Author: Nikos Anifantis ✍️

Generic CRUD Service in Angular: Part 2 - What is CRUD?

Nikos Anifantis — Sat, 09 Oct 2021 08:00:37 +0000

^{Cover Photo by Tobias Fischer on Unsplash.}

This article is a part of a series about how to create Generic CRUD Service & Models in Angular:

Part 1 - Understanding Generics
👉 Part 2 - What is CRUD?
Part 3 - Generic CRUD Model
Part 4 - Generic CRUD Service in Angular

What is CRUD?

Create, Read, Update, and Delete 👉 CRUD

Starting from the acronym, CRUD means create, read, update, and delete. These are the four main functionalities that must be provided by all models when building APIs.

Firstly let's explain some basics... An API is a set of definitions and protocols for building and integrating application software. It's the main contract between frontend and backend regarding their communication. An API in order to be RESTful, it should follow the constraints of REST architectural style and allows for interaction with RESTful web services. REST stands for representational state transfer and was created by computer scientist Roy Fielding.

So, talking about RESTful APIs, the CRUD feature usually corresponds to the HTTP methods POST, GET, PUT, and DELETE, respectively. These are the basic elements of a persistent storage system.

Important note: Keep in mind that this article recommends the most common approaches followed by developers for CRUD regarding responses, status codes, endpoints' paths etc. Follow this article for inspiration to create your rules according your needs. 🚀

Model Example

This series of articles examine a very common model for most of real-world applications, the model of User.

We simplify the model with the following properties:

{
  "id": 1,
  "firstName": "John",
  "lastName": "Doe",
  "email": "john@email.com",
  "createdAt": "2021-09-22T16:21:47.760Z",
  "updatedAt": "2021-09-22T16:21:47.851Z"
}

In this hypothetical database, let's assume that the id, createdAt, and updatedAt properties are handled only from our server's API. It's not important for now, but we'll notice in the next article that all models share the aforementioned properties.

➡️ Create

If we want to create a new user in our system, we use POST method and the endpoint path should start thi the base followed by the model name (usually in plural). The response should return 201 - Created status code.

Operation	Endpoint	Status Code
`POST`	`/api/users`	201 (Created)

Payload:

{
  "firstName": "John",
  "lastName": "Doe",
  "email": "john@email.com"
}

Response:

{
  "id": 1,
  "firstName": "John",
  "lastName": "Doe",
  "email": "john@email.com",
  "createdAt": "2021-09-22T16:21:47.760Z",
  "updatedAt": "2021-09-22T16:21:47.851Z"
}

➡️ Read

In order to retrieve all existing models from our database we request with GET method at base path of the user model. It's very similar to the previous endpoint, but here we changed the POST to GET. Also, this method accepts an empty payload as we cannot change users in our database. Finally, we get a list of users as response with 200 - OK status code.

Operation	Endpoint	Status Code
`GET`	`/api/users`	200 (OK)

Payload: None

Response:

[
  {
    "id": 1,
    "firstName": "John",
    "lastName": "Doe",
    "email": "john@email.com",
    "createdAt": "2021-09-22T16:21:47.760Z",
    "updatedAt": "2021-09-22T16:21:47.851Z"
  }
  {
    "id": 2,
    "firstName": "John",
    // ...
  }
]

Another use case is when we want to retrieve only one specific user by ID. Then, we call the same base model's path, but we add its ID at the end. Another difference is that instead of getting a list of users, the response returns an object with the found user.

Operation	Endpoint	Status Code
`GET`	`/api/users/{id}`	200 (OK)

Payload: None

Response:

{
  "id": 1,
  "firstName": "John",
  "lastName": "Doe",
  "email": "john@email.com",
  "createdAt": "2021-09-22T16:21:47.760Z",
  "updatedAt": "2021-09-22T16:21:47.851Z"
}

➡️ Update

The "update" functionality is used when we want to modify an existing user. We recommend to send only the values that we want to be updated to the server. The endpoint's path is similar with "read by ID", but we use the PUT method. The response should include the updated version of user, followed by a 200 - OK status code.

Operation	Endpoint	Status Code
`PUT`	`/api/users/{id}`	200 (OK)

Payload:

{
  "firstName": "Nikos"
}

Response:

{
  "id": 1,
  "firstName": "Nikos", // <-- Changed
  "lastName": "Doe",
  "email": "john@email.com",
  "createdAt": "2021-09-22T16:21:47.760Z",
  "updatedAt": "2021-09-23T12:13:07.651Z" // <-- Changed from server
}

➡️ Delete

Last but not least, we have the "delete" functionality which is used to delete an existing user by ID. Again the path is the same when reading/updating a model, but we use the DELETE method. Another important point here is that neither the payload nor the response transfers any data.

Operation	Endpoint	Status Code
`DELETE`	`/api/users/{id}`	204 (No Content)

Payload: None

Response: None

What's next?

Part 3 - Generic CRUD Model

References

Author: Nikos Anifantis ✍️

Generic CRUD Service in Angular: Part 1 - Understanding Generics

Nikos Anifantis — Tue, 05 Oct 2021 18:50:27 +0000

^{Cover Photo by Eugenio Mazzone on Unsplash.}

This article is a part of a series about how to create Generic CRUD Service & Models in Angular:

👉 Part 1 - Understanding Generics
Part 2 - What is CRUD?
Part 3 - Generic CRUD Model
Part 4 - Generic CRUD Service in Angular

Introduction

In this series of articles, we are going to learn how to create generic models and services step-by-step regarding the CRUD feature of resources in Angular.

In a nutshell, we're going to learn:

How to use generics in Typescript
What is CRUD operations in APIs
How to create generic models in Angular
How to create generic service for CRUD in Angular

The Problem 🤔

One of the most important principles in programming is the "Don't-Repeat-Yourself" (DRY) principle when it comes to writing dynamic and reusable code. We encounter this problem in the main functions provided by the models in real world applications. More specifically, when we are dealing with API endpoints a model can either be created, read, updated or deleted.

For example, let's say that we have two models in our app, "article" and "author". When we are faced with implementing the basics methods requesting the server's API for both models, we are must implement the same functionality twice. Thankfully, Typescript supports generics and allow us avoid code duplications.

Understanding Generics

First things first! Before we start to analyze our main content, we must understand how does generics work in Typescript and the definition of CRUD in APIs (Part 2).

Generics are awesome! It allows us to keep our code clean and reusable avoiding duplications. I believe that whoever has used it with Typescript, loves it. The rest of you will love it after this article 😆.

➡️ Example 1 - Type-Safe Generics

The first example that we will see, presents a method where it takes as arguments 2 parameters and returns an object based on them. It is a very simple method but with powerful types.

As you can see below, we use T and U as generic types which enforces both arguments and returned type to be the same type.
If we pass as first argument a value of type string, we are able to know that the property value1 of the result will be string as well. Maybe it looks like a little bit dummy but imagine a real world example (e.g. the main topic of this article - generic CRUD service).

Furthermore, if we look closer the following example, we can predefine the returned object by adding objectify<string, number>(...). Thus, we enforce the first argument to be of type string and the second of type number. If we try to pass a different type (e.g boolean), then we'll have a type error.

function objectify<T, U>(value1: T, value2: U): { value1: T; value2: U } {
  return { value1, value2 };
}

// ✅ - Correct
const obj1 = objectify<string, number>('Hello World', 10);
const obj2 = objectify<number, boolean>(10, true);

console.log(obj1); // Output: { value1: "Hello World", value2: 10 }
console.log(obj2); // Output: { value1: 10, value2: true }

// ❌ - Wrong
const obj3 = objectify<string, number>(10, 10);
const obj4 = objectify<string, number>(10, 'Hello World');

➡️ Example 2 - Generic Classes

The second example concerns class-es. Yes, classes! Generics work not only with functions but for class, interface, even type. In this example, we will create a custom class implementing a simple functionality of array. It can be initialized by a given array of items, add new item, and get all items.

We use T as generic type to declare the type of the stored items in our custom class. Thus, we ensure that all items will be the same type. For example, if we add the following new MyCustomArray<number>(), we restrict our instance to accept only values of type number at addItem() method. Also, we can infer that the getItems() method will return a list of values of type number.

class MyCustomArray<T> {
  private items: T[];

  constructor(initialItems: T[]) {
    this.items = initialItems;
  }

  getItems(): T[] {
    return this.items;
  }

  addItem(item: T) {
    this.items.push(item);
  }
}

// ✅ - Correct
const instance1 = new MyCustomArray<number>([1, 2]);
instance1.addItem(3);

const instance2 = new MyCustomArray<string>(['foo']);
instance2.addItem('bar');

console.log(instance1.getItems()); // Output: [1, 2, 3]
console.log(instance2.getItems()); // Output: ["foo", "bar"]

// ❌ - Wrong
instance1.addItem(true);
instance2.addItem(4);

➡️ Example 3 - Generic Constraints

In our third example, we'll learn how to add constraints at generic types. Bellow you will find a method that echoes a value, it accepts an argument and returns it as is. But the main difference is that the value must be either of type string or number. We use T generic type and we extend it to be string | number.

Thus, if we try to write something like echo<boolean>(true), Typescript will throw a type error. This functionality is very useful because sometimes our implementation requires specific criteria and we can limit the accepted values.

function echo<T extends string | number>(value: T): T {
  return value;
}

// ✅ - Correct
const result1 = echo<string>('Hello World');
const result2 = echo<number>(10);

console.log(result1); // Output: Hello World
console.log(result2); // Output: 10

// ❌ - Wrong
const result3 = echo<number>('Foo');
const result4 = echo<boolean>(true);

➡️ Example 4 - Bonus

We have succeeded so far! Let's see a bonus example in action with VSCode!

Let's create an Animal interface that can be extended by a Cat. But, the Cat can only have 2 colors - white or black (no grey zone here 😆).

interface Animal {
  name: string;
  voice: string;
}

interface Cat<T extends 'black' | 'white'> extends Animal {
  color: T;
}

When we are trying to create an object of type Cat, the editor will help us by suggesting us only the 2 main colors. You can see the picture below:

Now, let's create a black cat (I hope this does not mean bad luck for this article 😓). As you can see, we have set the generic type to black with Cat<'black'> and the editor give us as the only option to set color: 'black'.

Final model:

const myCat: Cat<'black'> = {
  color: 'black',
  name: 'Kitty',
  voice: 'meow',
};

Now let's forget cats and see a real world example... The following code is about how to apply generics at type. We have created a type that enforces an array to have a least one item.

We used T[] generic type which tell us that the type is an array of items and { 0: T } which indicates that the first item will not be empty. As you already noticed we have used the & operator that will enforce the NonEmptyArray type to fulfill both cases.

export type NonEmptyArray<T> = T[] & { 0: T };

function getFirstItemOfArray(items: NonEmptyArray<T>): T {
  return items[0];
}

// ✅ - Correct
const first1 = getFirstItemOfArray([1, 2]);

// ❌ - Wrong
const first2 = getFirstItemOfArray([]);
const first3 = getFirstItemOfArray(null);

What's next?

Part 2 - What is CRUD?

References

Author: Nikos Anifantis ✍️

Create Promises with Timeout Error in Typescript

Nikos Anifantis — Sat, 26 Jun 2021 06:23:21 +0000

^{Cover Photo by Immo Wegmann on Unsplash.}

The Problem 🤔

Sometimes we create promises that take too long to finish and we don't want to wait. For example, if we want to make a request and the response takes 20 seconds to finish and for any reason we may want to throw an error in the first 5 seconds and proceed to the next code block.

In this article, we will see how to implement a promise which throws an error after a specific time span. It supports typings with the power of Typescript and accepts a custom error to be thrown when the time comes.

Implementation 🚀

First of all, we create a new promise that rejects an error after a time span in milliseconds. The return type of the timeout promise is never which represents the type of values that never occur. For instance, never is the return type for a function expression or an arrow function expression that always throws an exception or one that never returns.

// create a promise that rejects in milliseconds
const timeout = new Promise<never>((_, reject) => {
  setTimeout(() => {
    reject(timeoutError);
  }, ms);
});

The next step is to use Promise.race() which returns a Promise that fulfills or rejects as soon as one of the promises in an iterable fulfills or rejects, with the value or reason from that promise. Here you can see that we have used <T> generic type that it will be defined in our final function.

Promise.race<T>([anyPromise, anyOtherPromise]);

Great, we saw all code blocks, let's see the full implementation below:

function promiseWithTimeout<T>(
  promise: Promise<T>,
  ms: number,
  timeoutError = new Error('Promise timed out')
): Promise<T> {
  // create a promise that rejects in milliseconds
  const timeout = new Promise<never>((_, reject) => {
    setTimeout(() => {
      reject(timeoutError);
    }, ms);
  });

  // returns a race between timeout and the passed promise
  return Promise.race<T>([promise, timeout]);
}

As you can see, we have created a function that accepts the following arguments:

promise: our actual promise
ms: the maximum time in milliseconds which we want to wait
timeoutError: (optional) we may pass a custom error to throw after timeout

You can find the final source code in stackblitz:

Conclusion ✅

Hooray, we made it to the end! I hope you enjoyed this post and do not wait for time consuming promises any more 😆.

Please support this article with your ❤️ 🦄 🔖 to help it spread to a wider audience. 🙏

Also, don’t hesitate to contact me if you have any questions leaving here your comments or Twitter DMs @nikosanif.

[4+1 ways] How to Unsubscribe from Observables in Angular like a 😎

Nikos Anifantis — Wed, 26 May 2021 10:41:33 +0000

Introduction

In this article, we will see some of the best practices to unsubscribe from subscriptions (aka Observables) and how to keep our code clean and nicely architectured avoiding memory leaks.

In a nutshell, we will use:

the async Angular build-in pipe
RxJS operators (e.g takeUntil)
custom array of subscriptions
the SubSink npm package
the @ngneat/until-destroy npm package

The Problem 🤔

If you have experience in Angular, you already know that RxJS is one of the most powerful packages. It uses the concept of Observables to handle and work with asynchronous and event-based code. More specifically, Observable is an entity that emits multiple data values over time and asynchronously.

It sounds cool, right? Yes, it is cool and powerful, but you already know that!

What's the problem with Observables then? Memory Leak!

Let me elaborate a bit on this, explaining a memory leak issue by an example. Below, we initialize 3 observables where they emit values every 1 second and we create a subscription for each one of them.

@Component(/* ... */)
export class ProblematicExampleComponent implements OnInit {
  constructor() {}

  ngOnInit() {
    interval(1000).subscribe((value) => {
      console.log('sub1', value);
    });
    interval(1000).subscribe((value) => {
      console.log('sub2', value);
    });
    interval(1000).subscribe((value) => {
      console.log('sub3', value);
    });
  }
}

Our code seems to work! BUT, what would happen if we destroy this component (e.g by navigating to an other route that doesn't contain this component)? The values will continue to be logged!

An even worse scenario is that if we go back to the previous route, the values will be printed twice, and so on. While we create more and more subscriptions without cleaning up them, it constitutes a typical example of a memory leak.

1. The `async` Pipe

As we know, Angular provide us a lot of built-in functionalities that we don't have to worry about by choosing third-party libraries (that's why we love ❤️ Angular after all, right?). Such a useful functionality is the async pipe.

Looking at the official documentation, we will see the following description:

The async pipe subscribes to an Observable or Promise and returns the latest value it has emitted. When a new value is emitted, the async pipe marks the component to be checked for changes. When the component gets destroyed, the async pipe unsubscribes automatically to avoid potential memory leaks.

Example:

// async-example.component.ts

import { Component } from '@angular/core';
import { interval } from 'rxjs';
import { tap } from 'rxjs/operators';
import { Logger } from '../utils/logger';

@Component(/* ... */)
export class AsyncExampleComponent {
  private logger = new Logger(AsyncExampleComponent.name);

  obs1$ = interval(1000).pipe(
    tap((value) => {
      this.logger.log('sub1', value);
    })
  );
  obs2$ = interval(1000).pipe(
    tap((value) => {
      this.logger.log('sub2', value);
    })
  );
  obs3$ = interval(1000).pipe(
    tap((value) => {
      this.logger.log('sub3', value);
    })
  );

  constructor() {}
}

<!-- async-example.component.html -->

<p>Observable 1 value: {{obs1$ | async}}</p>
<p>Observable 2 value: {{obs2$ | async}}</p>
<p>Observable 3 value: {{obs3$ | async}}</p>

<!-- Pro Tip -->
<ng-container *ngIf="obs1$ | async as val1">
  <p>Observable 1 value: {{val1}}</p>
</ng-container>

As we can see in the above example, during the creation of the component, 3 observables are initialized which emit values every 1 second using interval operator from RxJS.

At the same time we can see that these observables are piped with async to the template. This means that they will automatically subscribe during initialization and unsubscribe during component destruction. This constitutes a big advantage, because we do not bother to do it ourselves through code.

2. RxJS Operators

One more time RxJS is here to help us. It provides us a lot of useful operators that help us to to unsubscribe from subscriptions.

Firstly, let's look at some definitions with what we will use:

Subject: A Subject is a special type of Observable which shares a single execution path among observers. You can think of this as a single speaker talking at a microphone in a room full of people. Their message (the subject) is being delivered to many (multicast) people (the observers) at once. This is the basis of multicasting. Typical observables would be comparable to a 1 on 1 conversation.
interval: An operator that returns an observable which emits numbers in sequence based on provided timeframe.
takeUntil: A filtering operator that emits values until provided observable emits.

Example:

// take-until-example.component.ts

import { Component, OnDestroy, OnInit } from '@angular/core';
import { interval, Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
import { Logger } from '../utils/logger';

@Component(/* ... */)
export class TakeUntilExampleComponent implements OnInit, OnDestroy {
  private logger = new Logger(TakeUntilExampleComponent.name);
  private unsubscribe$ = new Subject<void>();

  constructor() {}

  ngOnInit() {
    interval(1000)
      .pipe(takeUntil(this.unsubscribe$))
      .subscribe((value) => {
        this.logger.log('sub1', value);
      });
    interval(1000)
      .pipe(takeUntil(this.unsubscribe$))
      .subscribe((value) => {
        this.logger.log('sub2', value);
      });
    interval(1000)
      .pipe(takeUntil(this.unsubscribe$))
      .subscribe((value) => {
        this.logger.log('sub3', value);
      });
  }

  ngOnDestroy() {
    this.unsubscribe$.next();
    this.unsubscribe$.complete();
  }
}

Now let us look in detail at the above example step by step:

First of all, we initialize a new Subject which does not emit any data type (void).
Then we created 3 observables with the help of interval operator.
We pass to these the takeUntil operator as pipe in order to filter values until the unsubscribe$ emits.
Last but not least step is to trigger unsubscribe$ during the ngOnDestroy. We call .next() method to trigger new value emission and .complete() to automatically unsubscribe all the observers.

Although we used only the takeUntil operator, there are other which can help us, too. For example we can use:

take: It emits provided number of values before completing. You can use it when you are interested in only the first emission, you want to use take. Maybe you want to see what the user first clicked on when they entered the page, or you would want to subscribe to the click event and just take the first emission.
takeWhile: It emits values until provided expression is false. You can use it when the optional inclusive parameter is set to true it will also emit the first item that didn't pass the predicate.

3. Custom Array of Subscriptions

Another way to unsubscribe a Subscription is to put them in an array. So we can iterate all items and call the .unsubscribe() method for each item in this array during component destruction.

Example:

// custom-array-example.component.ts

import { Component, OnDestroy, OnInit } from '@angular/core';
import { interval, Subscription } from 'rxjs';
import { Logger } from '../utils/logger';

@Component(/* ... */)
export class CustomArrayExampleComponent implements OnInit, OnDestroy {
  private logger = new Logger(CustomArrayExampleComponent.name);
  private subs: Subscription[] = [];

  constructor() {}

  ngOnInit() {
    const sub1 = interval(1000).subscribe((value) => {
      this.logger.log('sub1', value);
    });
    this.subs.push(sub1);

    const sub2 = interval(1000).subscribe((value) => {
      this.logger.log('sub2', value);
    });
    this.subs.push(sub2);

    const sub3 = interval(1000).subscribe((value) => {
      this.logger.log('sub3', value);
    });
    this.subs.push(sub3);
  }

  ngOnDestroy() {
    this.subs.forEach((s) => s.unsubscribe());
  }
}

This method works very well with multiple subscriptions without any third-party library. However, there are 3 important disadvantages:

We need to initialize an extra variable in the component
For each new Subscription we must add it to the array
We must not forget to iterate the array and unsubscribe its items at ngOnDestroy

4. `subsink` npm package

Now it's time to view some third-party libraries that facilitate us to unsubscribe our subscriptions. More specifically, SubSink library constitutes a RxJS subscription sink for unsubscribing gracefully in a component. Its usage is very simple and you can see it in action below.

Example:

// subsink-example.component.ts

import { Component, OnDestroy, OnInit } from '@angular/core';
import { interval } from 'rxjs';
import { SubSink } from 'subsink';
import { Logger } from '../utils/logger';

@Component(/* ... */)
export class SubsinkExampleComponent implements OnInit, OnDestroy {
  private logger = new Logger(SubsinkExampleComponent.name);
  private subs = new SubSink();

  constructor() {}

  ngOnInit() {
    this.subs.sink = interval(1000).subscribe((value) => {
      this.logger.log('sub1', value);
    });
    this.subs.sink = interval(1000).subscribe((value) => {
      this.logger.log('sub2', value);
    });
    this.subs.sink = interval(1000).subscribe((value) => {
      this.logger.log('sub3', value);
    });
  }

  ngOnDestroy() {
    this.subs.unsubscribe();
  }
}

As in the above examples, we initialize the subs variable as new instance of SubSink class. The second step is to use the sink property to collect the subscriptions using a setter. Finally, we call the unsubscribe() method to unsubscribe all of them, as we would do in our component OnDestroy lifecycle event.

As you can see, it has a dead simple usage and similar behaviour with the previous approach with custom array of subscriptions.

5. `@ngneat/until-destroy` npm package

👍 Personal Preference

Last but not least, we will see the @ngneat/until-destroy library.
Similar to the previous approach, we have very simple use within our source code.

Example:

// until-destroy-example.component.ts

import { Component, OnInit } from '@angular/core';
import { UntilDestroy, untilDestroyed } from '@ngneat/until-destroy';
import { interval } from 'rxjs';
import { Logger } from '../utils/logger';

@UntilDestroy()
@Component(/* ... */)
export class UntilDestroyExampleComponent implements OnInit {
  private logger = new Logger(UntilDestroyExampleComponent.name);

  constructor() {}

  ngOnInit() {
    interval(1000)
      .pipe(untilDestroyed(this))
      .subscribe((value) => {
        this.logger.log('sub1', value);
      });
    interval(1000)
      .pipe(untilDestroyed(this))
      .subscribe((value) => {
        this.logger.log('sub2', value);
      });
    interval(1000)
      .pipe(untilDestroyed(this))
      .subscribe((value) => {
        this.logger.log('sub3', value);
      });
  }
}

In this case, we have slightly different approach as it uses decorators. Firstly, we attach the @UntilDestroy() decorator at our component and then we pass the untilDestroyed operator in observable's pipe.

Although each case suits to different use cases, this is my favorite approach and I use it very often in my projects. Personally I prefer to install a third-party library and get clean and easy to read source code.

Conclusion ✅

Hooray! We made it to the end! 🙌

I hope you enjoyed this article and will make your applications even more clean without any memory leak issues by choosing the most suitable way to unsubscribe your observables.

I would be more than happy to hear your personal preference or suggest other ways, leaving your comments down below!

Please support this article with your ❤️ 🦄 🔖 to help it spread to a wider audience. 🙏

Also, don’t hesitate to contact me if you have any questions leaving here your comments or Twitter DMs @nikosanif.

You can find the final source code in stackblitz:

^{Cover Photo by Ali Kazal on Unsplash.}

How To Automate Code Tasks With Git Hooks 🔥

Nikos Anifantis — Mon, 19 Apr 2021 08:10:33 +0000

Introduction 🤔

Automation is awesome! It allows us to increase our productivity and achieve more in shorter amount of time. Thus, this article will teach you step-by-step how to install and use tools that automate processes which leave our limited attention span to focus on solving real challenges!

More specifically, we are going to learn how to:

Format automatically our source code, following rules with unique style
Build meaningful commit messages
Take advantage of the power of Git Hooks
Force our repository to accept specific structure of commits
Ensure that source code will be committed properly formatted
Automate new releases, generating versions, changelogs, Git tags, etc.

This article refers to any Git repository with Node.js, including Angular, React.JS, etc.

Prerequisites ⚡

Prettier constitutes an opinionated code formatter which supports many languages and integrations with most code editors. It allow us to format automatically our code on save saving time and making sure our code have only one, unique and clean format style.
Conventional Commits is a lightweight convention on top of commit messages, providing an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of.

  <type>[optional scope]: <description>

  [optional body]

  [optional footer]

Husky is a library that allows us to run specific commands and scripts at time of committing and pushing our code using Git hooks.
Standard Version is a utility library for versioning using semver and CHANGELOG generation based on conventional commits of your repository.

In this tutorial, we will also use commitlint and pretty-quick libs to check if your commit messages meet the conventional commit format and run prettier on changed files respectively.

Install Prettier 🌺

First of all we are going to install Prettier in our the project.

$ npm i -D prettier

Now let's add some configuration files that specify rules and ignore files from prettier formatting.

In your project at root directory create two files with names .prettierrc and .prettierignore.

# .prettierrc

{
  "useTabs": false,
  "printWidth": 80,
  "tabWidth": 2,
  "singleQuote": true,
  "trailingComma": "all",
  "semi": true
}

# .prettierignore

/dist
/coverage

Last step is to install Prettier extension at VS Code. Open "Quick Open" (CMD/CTRL + P), paste the following command, and press enter.

ext install esbenp.prettier-vscode

Great, now try to write some code (without 🐛 😆), save your file and let the magic begin!

Install Husky 🐕

First, to install Husky in your project, you have to run the following command:

$ npm i -D husky

Then, run the command below in order to initialize the configuration files.

$ npx husky install

It will generate a new folder at root directory as depicted below:

In order to ensure that husky is going to be initialized each time that you install your project, add the following postinstall script at your package.json file.

// package.json

{
  "name": "awesome-project",
  "version": "0.0.0",
  "scripts": {
    "postinstall": "husky install"
    // ...
  }
  // ...
}

Setup Git Hooks 🔀

Awesome, you made it so far! Let's combine them together and setup our project. 😏

It's time to add some scripts for:

commit message validation that meet conventional commit format
format with prettier the changed files before committing new code

Install all the required dev-dependencies, by running:

$ npm i -D @commitlint/cli @commitlint/config-conventional pretty-quick

Open your project and create a new file with name commitlint.config.js under the root folder. Then copy/paste commitlint configuration in your new file as depicted below.

// commitlint.config.js

module.exports = {
  extends: ["@commitlint/config-conventional"],
};

The next step is to tell Husky what command to execute on which Git Hook action. Create two files under the .husky folder with names commit-msg and pre-commit.

In order to validate commit messages on commit-msg Git Hook, we use commitlint command. This action allows us to verify if the new commit message meets the requirements of Conventional Commits specification.

If the commit message does not follow the rules, it will not allow us to commit our new code.

# commit-msg

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install commitlint --edit $1

The second action that we want to achieve is to format our code automatically before we commit our code to the repository. We use pretty-quick command to format our code depending on the defined configuration that we have specified.

Also, we use --staged command flag to format only those files that are changed in our new commit.

# pre-commit

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install pretty-quick --staged

[Optional] As final step, I recommend to install the Conventional Commits official plugin in your VS Code. It will help you to write structured commit messages through a step-by-step form without having to memorize all the rules.

Open "Quick Open" (CMD/CTRL + P), paste the following command, and press enter.

ext install vivaxy.vscode-conventional-commits

Once you have installed the plugin, open "Source Control" panel and click on the "circle" icon button at the top. A panel will appear and will guide you to write your commit message.

🔖 Tip

Although it may seem like a tedious process at first, it will help a lot and over time you will get used to it very easily writing well structured commit messages. 😉

Install Standard Version 📦

Before we proceed with the installation, let's do a small recap. At the previous step, we saw how to format commit messages and how to enforce validation of them with Git Hooks.

So, our commits look like this:

- feat(ui): add avatar component for users
- style(ui): add roundness at avatar component
- chore: update lodash to 4.17.21
- feat(layout): add navigation links at header
- fix(auth): pass valid token at authentication process

Although it's totally the best practice to follow specific message convention for your commits, it's also the only requirement to be able to fully use the standard-version package.

In brief, standard-version undertakes to:

Change versions at package.json and package-lock.json files
Track changes from your commits and generate/update automatically CHANGELOG.md
Commit changed files
Create appropriate tags with versions at your repository

To install standard-version run:

$ npm i -D standard-version

Then, let's create three scripts at our project. According to semver, we create one script for each version number (MAJOR.MINOR.PATCH).

Update your package.json file like:

// package.json

{
  "name": "awesome-project",
  "version": "0.0.0",
  "scripts": {
    // ...
    "release": "standard-version --release-as major",
    "release:minor": "standard-version --release-as minor",
    "release:patch": "standard-version --release-as patch"
  }
  // ...
}

Once you write some code and create 2-3 commits, try to run the following command:

$ npm run release -- --dry-run

We use the --dry-run command flag to demonstrate what commands would be run, without committing to git or updating files.

During your official release just run: npm run release

You will get an output similar to this:

✔ bumping version in package.json from 0.0.0 to 1.0.0
✔ bumping version in package-lock.json from 0.0.0 to 1.0.0
✔ outputting changes to CHANGELOG.md

---
### Features

* **ui:** add avatar component for users (...)
* **layout:** add navigation links to header (...)

### Fixes

* **auth:** pass valid token at authentication process (...)
---

✔ committing package-lock.json and package.json and CHANGELOG.md
✔ tagging release v1.0.0
ℹ Run `git push --follow-tags origin master` to publish

You have created a new release version for your project. 👏

Keep in mind that you have a ton of options to customize according to your needs from the official documentation.

Conclusion ✅

Hooray! We made it to the end! 🙌

I hope you enjoyed this article and boost your projects with some magic.
All aforementioned tools can help you to enrich the endless automation possibilities in an excellent way and make you and your team even more productive!

Please support this article with your ❤️ 🦄 🔖 to help it spread to a wider audience.

Also, don’t hesitate to contact me if you have any questions leaving here your comments or Twitter DMs @nikosanif.

^{Cover Photo by rhondak on Unsplash.}

Using shared settings between multiple environments in Angular 🚀

Nikos Anifantis — Fri, 02 Apr 2021 13:03:03 +0000

The problem 😕

When we create a new Angular project, by default Angular CLI creates two environment files for development and production.

But in real world software development workflow, we may need more custom environments (e.g. staging, qa). Moreover, there are some environmental variables that are common between these environments. For example, API URL to fetch data from server. Thus, we must find a way to share the base settings across all environments and override them as needed.

In this article, we are going to learn:

How to add custom environments (e.g. staging)
How we can share some common settings between environments

Create a custom environment 💎

Open your Angular project and create a new file under environments folder. In this example, we create a new environment for staging (environment.staging.ts file).

🔖 TIP: The name of the file should follow the naming convention:

environment.<your-env-name>.ts

Great, let's add some configuration in our new env file...



// environment.staging.ts

export const environment = {
  production: true,
  environmentName: "staging",
  apiUrl: "<your-api-url-here>",
};

Update `angular.json` config file 👈

Once you have created the new environment file, you have to specify file replacements for different environments. In your angular.json file find the following paths:

projects.<your-project-name>.architect.build.configurations
projects.<your-project-name>.architect.serve.configurations

Update the sections as the following example:



// angular.json

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "version": 1,
  "newProjectRoot": "projects",
  "projects": {
    "<your-project-name>": {
      // ...

      "architect": {
        "build": {
          //...
          "configurations": {
            //...
            "staging": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.staging.ts"
                }
              ]
            }
          }
        },
        "serve": {
          //...
          "configurations": {
            "staging": {
              "browserTarget": "<your-project-name>:build:staging"
            }
          }
        }
      }
    }
  }
}

The problem is still out there 💥

Although we have created a new custom environment, in a typical project setup we may have duplication of environmental settings in which the values may be shared between them.

An example is depicted below where the API URL is common for all environments:



// environment.ts

export const environment = {
  production: false,
  environmentName: "development",
  apiUrl: "https://my-api.com/api", // common setting
};



// environment.prod.ts

export const environment = {
  production: true,
  environmentName: "production",
  apiUrl: "https://my-api.com/api", // common setting
};



// environment.staging.ts

export const environment = {
  production: true,
  environmentName: "staging",
  apiUrl: "https://my-api.com/api", // common setting
};

In this example, the common settings is not a real problem, since there is only one shared value between the existing environments.

But... Imagine a real world Angular project which has at least 4-5 environments and a bunch of settings that developers have to maintain. This is really a problem, believe me... 😟😥

Create a common environment 💦🔥

Let’s make our life easy by using a base configuration file for common settings across all environments.

First, in your project create a new file with name environment.common.ts under the environments folder.

The next step is to add all base configuration in there...



// environment.common.ts

export const commonEnv = {
  production: false,
  environmentName: "development",
  apiUrl: "https://my-api.com/api",
};

Last step is to change the existing environment files by importing the common file and override only the necessary settings.

In this example we don't need to override anything for the default environment (development).



// environment.ts

import { commonEnv } from "./environment.common";

const env: Partial<typeof commonEnv> = {};

// Export all settings of common replaced by dev options
export const environment = Object.assign(commonEnv, env);

But, for production and staging we have to override some settings from the base.



// environment.prod.ts

import { commonEnv } from "./environment.common";

const env: Partial<typeof commonEnv> = {
  production: true,
  environmentName: "production",
};

// Export all settings of common replaced by dev options
export const environment = Object.assign(commonEnv, env);



// environment.staging.ts

import { commonEnv } from "./environment.common";

const env: Partial<typeof commonEnv> = {
  production: true,
  environmentName: "staging",
};

// Export all settings of common replaced by dev options
export const environment = Object.assign(commonEnv, env);

We use the Object.assign() method that allows you to copy all enumerable own properties from one or more source objects to a target object, and return the target object.

🔖 Pro Tip

Instead of Object.assign() method, you can use the spread operator.
export const environment = { ...commonEnv, ...env };
As an alternative, if you have more advanced setting with nested properties, I recommend to use merge function from lodash library.
export const environment = _.merge(commonEnv, env);

There is one more extremely useful trick here to preserve typings with typescript.
We use Partial<typeof commonEnv> in order to help us to track the properties of the common environment and override them correctly.

Use environment settings inside project ✨

Great! We have created multiple environments and now is time to use them in our project.

You can import environment settings in your services/components like the following example:



import { Component } from "@angular/core";
import { environment } from "src/environments/environment"; // here is the import

@Component({
  selector: "app-root",
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"],
})
export class AppComponent {
  private apiUrl: string;

  constructor() {
    this.apiUrl = environment.apiUrl;
    // ...
  }
}

Please be careful! Don't import your settings from the direct environment file!

For example:



// DO NOT
import { environment } from "src/environments/environment.staging";

// DO
import { environment } from "src/environments/environment";

❗ Attention

We saw how to import environment settings in our project...
But it's NOT good idea to import them directly at your components or services.

I suggest to create a new Angular service (e.g. ConfigService) and handle all settings from there by injecting it in your components.
Thus, you will have a cleaner and more maintainable code.

Run/Build your project 📦

We are reaching the end, the hard work is done!
Now it's time to run and build your application for targeted environment by specific --configuration parameter with Angular CLI.

In order to build our application in staging mode, run one of the following commands:



# Builds and serves your app, rebuilding on file changes.

$ ng serve --configuration staging



# Compiles an Angular app into an output directory

$ ng build --configuration staging

Conclusion ✅

Hooray! We’re done! 👏

I hope you enjoyed this guide and will make your applications even more clean and maintainable by splitting environments to separate reusable configuration files! This approach can help in an excellent way in the enterprise organization setting!

Please support this article with your ❤️ 🦄🔖 to help it spread to a wider audience 🙏.

How To Set Dynamic Height At Element With Angular Directive 📐

Nikos Anifantis — Fri, 19 Mar 2021 11:47:42 +0000

The Problem

Interactive web designs require elements with dynamic height that depends on their location in the window viewport. More specifically, their height starts at the top offset position of the element inside the window and ends at the end of the window. In this article we will try to implement dynamic height using Angular directives.

Implementation

Create New Angular Directive

First of all, we create an Angular directive by injecting the the native element from ElementRef.



@Directive({
  selector: "[fluidHeight]",
})
export class FluidHeightDirective implements AfterViewInit {
  @Input("fluidHeight") topOffset: number;
  // ...

  private domElement: HTMLElement;

  constructor(private elementRef: ElementRef) {
    this.domElement = this.elementRef.nativeElement as HTMLElement;
    // ...
  }
}

Calculate Top Offset Of The Element

The next step is to calculate the top offset of the HTML element depending on the window. We use the .getBoundingClientRect() method that returns a DOMRect object which is the smallest rectangle which contains the entire element, including its padding and border-width.



private calcTopOffset(): number {
    try {
      const rect = this.domElement.getBoundingClientRect();
      const scrollTop =
        window.pageYOffset || document.documentElement.scrollTop;

      return rect.top + scrollTop;
    } catch (e) {
      return 0;
    }
  }

Set Dynamic Height To Element

This method sets the calculated height to the host HTML element, using the Angular Renderer (Renderer2). If the user knows the to offset we don't need to recalculate it.



private setHeight() {
  const windowHeight = window?.innerHeight;
  const topOffset = this.topOffset || this.calcTopOffset();
  let height = windowHeight - topOffset;

  // set min height instead of the calculated
  if (this.minHeight && height < this.minHeight) {
    height = this.minHeight;
  }

  this.renderer.setStyle(this.domElement, 'height', `${height}px`);
}

Observe Window Resize

We need to observe the window resize event in order to calculate the height on any change. We use the fromEvent method from rxjs to register at window's resize events and it converts them to observable. The problem here is that the events are too many when we resize the window and we have to decrease them. Thus, we use throttleTime and debounceTime from rxjs/operators to minimize the re-calculation of the dynamic height.

Tip: Unsubscribe on destroy to avoid memory leaks.



// register on window resize event
fromEvent(window, "resize")
  .pipe(throttleTime(500), debounceTime(500))
  .subscribe(() => this.setHeight());

Final Result 😉

Great, we have done it! We have created an Angular directive that sets dynamic height to its host HTML element in a very short time.



import {
  AfterViewInit,
  Directive,
  ElementRef,
  Input,
  Renderer2,
} from "@angular/core";
import { fromEvent } from "rxjs";
import { debounceTime, throttleTime } from "rxjs/operators";

@Directive({
  selector: "[fluidHeight]",
})
export class FluidHeightDirective implements AfterViewInit {
  @Input() minHeight: number;
  @Input("fluidHeight") topOffset: number;

  private domElement: HTMLElement;

  constructor(private renderer: Renderer2, private elementRef: ElementRef) {
    this.domElement = this.elementRef.nativeElement as HTMLElement;

    // register on window resize event
    fromEvent(window, "resize")
      .pipe(throttleTime(500), debounceTime(500))
      .subscribe(() => this.setHeight());
  }

  ngAfterViewInit() {
    this.setHeight();
  }

  private setHeight() {
    const windowHeight = window?.innerHeight;
    const topOffset = this.topOffset || this.calcTopOffset();
    let height = windowHeight - topOffset;

    // set min height instead of the calculated
    if (this.minHeight && height < this.minHeight) {
      height = this.minHeight;
    }

    this.renderer.setStyle(this.domElement, "height", `${height}px`);
  }

  private calcTopOffset(): number {
    try {
      const rect = this.domElement.getBoundingClientRect();
      const scrollTop =
        window.pageYOffset || document.documentElement.scrollTop;

      return rect.top + scrollTop;
    } catch (e) {
      return 0;
    }
  }
}

We made it to the end!👏👏👏 Hope you found this article helpful! 😉

DEV Community: Nikos Anifantis

Managing Requests State in Angular with RxJS and Adapters

The Problem: Managing Multiple States

The Solution: Using an Adapter

Step 1: Defining the Command Adapter interfaces

Step 2: Creating the Command Adapter

Step 3: Integrating with RxJS

Step 4: Using the Adapter in a Component

Benefits of This Approach

Bonus: Using Angular Signals and toSignal()

Conclusion

Angular Authentication: Upgrade to Angular 18 🚀

nikosanif / angular-authentication

An Angular application that demonstrates best practices for user authentication & authorization flows.

Angular Authentication

Table of Contents

Live Demo

Getting Started

Prerequisites

Setup & Usage

Useful Commands

Features

Authentication Flows

Other Features

The Challenge 🤔

TL;DR 🎯

Step-by-Step Upgrade Process 🚀

Initial Setup

Incremental Angular Updates

Adjustments and Comparisons

Final Angular Update

UI and Dependency Migrations

Other Enhancements

Future Enhancements 💡

Conclusion ✅

Angular Authentication: Best Practices 🏆

nikosanif / angular-authentication

An Angular application that demonstrates best practices for user authentication & authorization flows.

Angular Authentication

Table of Contents

Live Demo

Getting Started

Prerequisites

Setup & Usage

Useful Commands

Features

Authentication Flows

Other Features

Live Demo

Getting Started

Prerequisites

Setup & Usage

Useful Commands

Features

Authentication Flows

Other Features

Tech Stack

High-level Design

Contributing

Support

Author: Nikos Anifantis ✍️

License

Generic CRUD Service in Angular: Part 4

Generic CRUD Service

1️⃣ Create

2️⃣ Get all

3️⃣ Get by ID

4️⃣ Update

5️⃣ Delete

➡️ Final result

Conclusion ✅

Generic CRUD Service in Angular: Part 3 - Generic CRUD Model

Generic CRUD Model

Example

What's next?

Generic CRUD Service in Angular: Part 2 - What is CRUD?

What is CRUD?

Model Example

➡️ Create

Payload:

Bonus: Using `Angular Signals` and `toSignal()`

1. The `async` Pipe

4. `subsink` npm package

5. `@ngneat/until-destroy` npm package

Update `angular.json` config file 👈