DEV Community: Dino Dujmovic

Angular Architecture - Abstraction layers

Dino Dujmovic — Fri, 05 May 2023 15:26:17 +0000

Angular Architecture - Organizing modules

Dino Dujmovic ・ Apr 18 '23

Now that we have explored how modular design can be achieved in a standalone Angular application, let's take a closer look at how our application operates and functions by examining it through the lens of abstraction layers.

Abstraction Layers

The concept behind this pattern is to divide the application into discrete layers and establish communication protocols between them.

The pattern aims to split the application into three distinct layers, namely:

Core Layer
Abstraction Layer
Presentation Layer

Core Layer

Angular Architecture - Core Module

Dino Dujmovic ・ Apr 28 '23

#angular #architecture #frontend #webdev

The Core Layer is the central implementation hub for the core application logic, including all data manipulation and external communication. This layer also includes essential business logic, such as API calls for data retrieval.

It's main parts are services for making API calls and/or state management which in case of Angular could be NgRx, NgXs, custom implementation using Subjects or other.

API Services have sole purpose to facilitate communication with API endpoints and nothing more.

Movie Service example used only for defining API calls

State Management Solution serves as a centralized, immutable data store for the application. By incorporating an Abstraction Layer, we can render our components independent of both the State Management Solution and API/Data Services. This approach makes it much easier to migrate to other data management solutions in the future, as we won't need to modify the Presentational Layer (i.e., the Components).

Movie State example using Ngxs

Abstraction layer

The abstraction layer sits between the presentation and the core layer and handles communication between them.
Since, the goal is not to inject API and state providers directly in the presentation layer, rather, we can inject the facade service and use it to interact with the core layer.

So abstraction layer:

is implemented as Angular providers/services named facades (example: movies.facade.ts)
exposes streams of state and interface
is used to store and dispatch actions, observable emissions and expose observables and signals for components to use.

Movies Facade - exports observables, subscribes to store and dispatches store actions

Presentation layer

The presentation layer (UI) layer is where all Angular components reside. Its primary responsibility is to present the application's UI and delegate user actions to the core layer through the abstraction layer.

Inside of presentation layer we have:

Smart/container components:

can pass data down to dumb components
have facade/s and other services injected
communicate with core layer through facades
react to events from dumb components
are usually page components (meaning they are routable but it is not case)

Movies Page smart component - injects facade and knows about the state

Angular Architecture - Page Modules

Dino Dujmovic ・ Apr 25 '23

#angular #architecture #frontend

Dumb/presentational components:

recieve their data through @Input() and pass events and data through @Output()
do not contain any application logic
mostly kept in SharedModule or at specific module components folder

Movie Card presentational component - used only to show data passed from parent component

Angular Architecture - Shared Module

Dino Dujmovic ・ Apr 30 '23

#angular #architecture #frontend #webdev

References:

Angular Architecture - Shared Module

Dino Dujmovic — Sun, 30 Apr 2023 14:24:55 +0000

🎯 Introduction

Shared Module will contain declarations for reusable components, directives, and pipes, as well as any common services that may be required by multiple feature modules. It may also export third-party modules, like Angular Material or ngx-translate, that are used throughout the application.

To use the Shared Module in other modules, it must be imported into each module that requires access to the shared components, directives, pipes, or services.



// Shared Module and export example
@NgModule({
  imports: [CommonModule],
  declarations: [
    MovieCardComponent,
    MovieBackdropColorDirective,
    MovieFilterPipe
  ],
  exports: [
    MovieCardComponent,
    MovieBackdropColorDirective,
    MovieFilterPipe,
    CommonModule,
    FormsModule,
    MatAutocompleteModule,
    MatInputModule,
    MatListModule,
  ],
})
export class SharedModule {}



// Shared Module import example
@NgModule({
    declarations: [
        ...MovieRoutingModule.components
    ],
    imports: [
        SharedModule,
        MovieRoutingModule,

    ],
    providers: [
        MovieResolver
    ]
})
export class MovieModule { }

Note: You could as well create your shared components as standalone components or export each component as it's own module.
But I believe that if you have a large number of shared components or your application is more complex, exporting shared components through a SharedModule is generally preferred as it's much easier to mantain.

🎯 The Benefits

It's usually a common requirement of many projects to have customized building blocks for the applications such as usual UI elements like buttons, dropdowns, alerts, cards, tables, checkboxes, text inputs, file inputs, select elements and so on.

One of the key benefits of using a SharedModule is that it allows you to consolidate your presentational dummy components, which can be treated as a 3rd party library project. This makes it easier to manage and reuse your components across multiple projects (if needed), as well as share them with other developers or teams.

You can easily update and test your components in isolation, and make changes without affecting the functionality of your main application.

So it's a great place to start writing your unit tests and use something like Storybook stories.

Although it can be tempting to skip unit testing, starting with the smaller parts like testing your presentational components can help you get in the habit and reap the benefits of more robust and reliable code.

Storybook is a powerful tool that enables you to:

Develop and test your components independently of your main application
Define multiple use cases for your components, providing a clearer overview of the various scenarios in which they can be utilize
Document your components thoroughly
Enhance communication between team members by providing a centralized location for component viewing and collaboration.

Angular Architecture - Core Module

Dino Dujmovic — Fri, 28 Apr 2023 21:46:04 +0000

🎯 Introduction

CoreModule is a module that is used to encapsulate the core functionality of an application. The purpose of the CoreModule is to provide a central place for defining services, single instance components, configuration settings, util and helper classes and functions and any other code that is used across the entire application.

The CoreModule is typically imported only once, in the AppModule. This ensures that its services and components are available throughout the application.

This is where the core application logic is implemented, including all data manipulation and communication with external systems. If we are using a state management solution like Ngrx or Ngxs this is the place to define our state, actions, and reducers.

🎯 Core folder example

Core folder will contain things like:
helpers
Various helper classes, functions, and modules that are specific to your application's domain like auth-helper.ts, form-helper.ts, manual-subs.ts

interceptors
Interceptors are classes that can intercept HTTP requests and responses from the client to the server and vice versa.

models
Interface and Types definitions for API returned models, dtos. I prefer to prefix my interfaces with I and types with T. For example IMovie, TTime.

services
Singleton services with @Injectable({providedIn: "root"}) decorator for handling API calls, error handling, logging etc.

shell
Shell components are standalone components used only inside of app.component.ts like layout components (header, footer, menu) or some of the placeholder components like toasters or modals (if decided to be implemented that way).

store
State, actions and reducer definitions for state management solution implementation

utils
Various helper functions, classes, and modules that can be reused across different parts of the application like date-utils.ts, string-utils.ts.

Note: Some developers prefer to keep utility functions and helper classes in the SharedModule since they are typically shared across different parts of the app and don't have any dependencies on Angular, nor they are singletons. However, it's just a preference

In the beginning, I tend to keep data-related code in the core folder to ensure easy accessibility and organization to avoid getting lost in thought process of what could be used somewhere in the future too early.

As I continue working on the application, I evaluate which services, models, types, and state definitions are only relevant to a specific module and will only be used within that module. In those cases, I move them to the appropriate module to keep the code organized and maintainable.

Angular Architecture - Page Modules

Dino Dujmovic — Tue, 25 Apr 2023 18:38:10 +0000

🎯 Introduction

A page (or view) module is a module that represents a page or a view of an application. It is a collection of related components, directives, pipes, and services, routes and other page modules (sub-pages) that work together to form a cohesive user interface.
Page modules serve the purpose of organizing and encapsulating a page's functionality. They are the first component rendered after a user lands on a specific route defined in our app routing module, simplifying the management and maintenance of the page.



@Injectable()
export class PreloadModulesStrategy implements PreloadingStrategy {
    preload(route: Route, load: () => Observable<any>){
        if (route.data && route.data.preload) {
            return load();
        }
        return of(null);
    }
}

I almost always use lazy loading for my entry page modules, which results in a smaller entry file bundle and faster loading times. Additionally, I recommend a custom preload module strategy, allowing me to specify which pages I want to fetch over the network when app is initially loaded (so they will be fetched even if user didn't land on the specific route). This ensures that the modules are loaded quicker when accessed by the user later.

Quick example in my little app shows how JS chunks for Home and Movie pages are loaded and ready to use when application is loaded, while Settings page JS chunk is loaded after user has navigated to it.

🎯 Page Module Content

Page module also contains collection of components, services (http services, resolvers, guards, etc..) and all of the other Angular building blocks specific for that page that goes under the same starting route.

It also contains routing (sub-routes) definitions relative to page module path defined in app-routing.module.ts which means it will also contain other Page modules.

We are currently grappling with an ongoing issue of determining the most suitable level of nesting for our subpages. While it may seem intuitive to arrange our folders based on our routing definitions, I can attest that this can quickly become unwieldy and result in excessively nested files, which can be frustrating to navigate and runs counter to our primary goal of simplifying the folder structure.

So, my proposition is that we put all of the subpages into a single folder labeled "modules". Additionally, it is my recommendation that we place all components intended for use in the page module and its sub-modules in a folder titled "components", even if they are only utilized within a specific subpage.

🎯 Example

I will use this awesome page TheMovieDB as a reference for my example of setting up folder structure and routing:

TMDB - Movie Overview Page

TMDB - Movie Discussion Page

I hope that folder structure is self-explanatory.

shell (contain all of the components used for _hosting page sub modules that may share some repeatable layout like menus)_
modules (contain all of the modules referenced in movie.module.ts in this case)
components (contain all of the components used across any module - shared or not)
services (contain all of the movie services)
... etc

The main objective is to ensure effortless access and customization of our codebase by simplifying the directory hierarchy and keeping it flatten as possible.

Angular Signals Introduction

Dino Dujmovic — Sat, 22 Apr 2023 23:45:57 +0000

In essence, a signal is a combination of a variable and a change notification. Unlike observables, signals are synchronous and always possess a value.

🎯 Working with signals

There are three distinct methods that can be used to manipulate signal values in Angular.

set() method allows for the replacement of a signal's current value with a new one.



numb = signal(1);

numb.set(2);

update() method can be used to modify a signal's value based on its current value.



name = signal('Dino');
name.update((value) => value + '1337') // Dino1337

mutate() method is used to modify the content of a signal value, without replacing the signal value itself. When working with arrays, you can use this method to modify individual array elements. Similarly, when working with objects, this method can be used to modify specific object properties.



arr = signal([]);
arr.mutate((v) => v.push(i));

obj = signal({ name });
obj.mutate((v) => v.name = 'Dino');

Computed signals

I believe this is the strongest use case for basic work signals so far, and here is why:



@Component({ 
  template: `
    {{ fullnameA }} // will not update
    {{ fullnameB() }} // will update

    <button (click)="changeSurname()">Change surname</button>
  `
})
export class App {
  nameA = 'John';
  surnameA = 'Doe';
  fullnameA = this.nameA + this.surnameA;

  nameB = signal('Jane');
  surnameB = signal('Doe');
  fullnameB = computed(() => this.nameB() + this.surnameB());

  changeSurname() {
    this.surnameA = 'Haaland';
    this.surnameB.set('Ibrahimovic');
  }
}

At first glance, many might assume that modifying the surnameA variable would automatically update the fullnameA variable, just as it would if we were using an Angular expression like {{ nameA + surnameA }}. However, this is not the case.

Using signals (computed signals), which automatically recalculate whenever any of their dependent signals change, we can achieve this.

But hey, of course this works! Signals are functions and we are binding to function call here. And we all know it's a golden rule not to do that.
We could as well do something like this:



  {{ fullnameA() }}

  fullnameA = () => this.nameA + this.surnameA;

And that will work to... but!

This demonstrates that fullnameA() will be called whenever change detection is triggered, whereas signal fullnameB() will only be called when its dependent signal is updated. This feature is remarkable because using signals allows for more precise management of change detection, which can lead to better performance.

Moreover, computed signals are re-calculated under two conditions: when one or more of its dependent signals are altered, and when the value of the computed signal is read.

Using effect

Signal effect are pretty much useful for getting notified when your signal gets updated (changed), so you can log it or make API calls (like you would be able to do with React's useEffect.. kinda).



effect(() => console.log(this.selected()));
effect(() => apiCall(this.param());

🎯 Summary

So far, my favorite feature has been computed signals, as explained earlier. Additionally, effects now offer a convenient way for us to watch and react to our signal updates.

Until then, I recommend trying to learn how both of these tools play together so you can pick best tool for the job in order to write more simple, readable and performant code.

I recommend this video from Josh Morony:

As well as this video from Deborah Kurata:

to check out possible comparisons between using signals vs observables.

Angular Architecture - Organizing modules

Dino Dujmovic — Tue, 18 Apr 2023 22:08:48 +0000

Are you among the many who find themselves wondering about the most effective approach for organizing folders and files in Angular applications? The answer may be right in front of you, "hidden" in plain sight.

"Do structure the application such that you can Locate code quickly, Identify the code at a glance, keep the Flattest structure you can, and Try to be DRY (Do Not Repeat Yourself)." - Angular Style Guide

... and working with Angular will be like playing with LEGO blocks.

My goal for this series is to establish a consistent mindmap and clear starting point for each application I work on and to achieve early satisfaction in the development process.

🎯 Starting point

You probably noticed that almost every web application has a standard page layout that includes common UI elements such as the header, footer and possibly a navigation menu, as well as routes that define the path for different pages (features, views) of the application.

These components are often referred to as "shell" components and are typically designed to be rendered only once per page load meaning that we will import them inside of our app component (root).



// app.component.ts
@Component({
    selector: "app-root",
    template: `
        <app-header></app-header>
        <app-menu></app-menu>
        <main>
           <router-outlet></router-outlet>
        </main>

        <app-footer></app-footer>
    `,
})
export class AppComponent {
}

Note:
router-outlet can be described as a placeholder that displays the page (features/views/modules or whichever naming you prefer) components associated with different routes defined in Angular application - in this case inside of app-routing.module

🎯 Folder structure

My apps will usually consist of these 3 folders (core, pages and shared) as well as app module file.
It's worth noting that some developers prefer to use alternative folder names to page, such as features, modules, or views. Others may choose to flatten the folder structure entirely and place all routable modules at the root level of app folder. Ultimately, the folder structure should be organized in a way that makes the most sense for the specific project and team.

🎯 App module

While the AppModule is responsible for bootstrapping the application, it's generally best to keep it as small as possible and delegate most of the application logic to other modules, such as the CoreModule or page modules.



// app.module.ts
@NgModule({
    declarations: [
        AppComponent
    ],
    imports: [
        AppRoutingModule,
        CoreModule
    ],
    bootstrap: [AppComponent]
})
export class AppModule { }

In this case, the main responsibility of the AppModule would be to import and define the main app routing.
Because we created each page as a module, it can be lazily loaded.



const routes: Routes = [
    {
        path: "",
        pathMatch: "full",
        redirectTo: "/"
    },
    {
        path: "",
        data: { preload: true },
        loadChildren: () => import("@pages/home/home.module").then((m) => m.HomeModule)
    },
    {
        path: "movies",
        data: { preload: false },
        loadChildren: () => import("@pages/movies/movies.module").then((m) => m.MoviesModule)
    },
    {
        path: "settings",
        data: { preload: false },
        loadChildren: () => import("@pages/settings/settings.module").then((m) => m.SettingsModule)
    },
    { path: "**", redirectTo: "/" },
];

@NgModule({
    imports: [RouterModule.forRoot(routes, { preloadingStrategy: PreloadModulesStrategy })],
    exports: [RouterModule]
})
export class AppRoutingModule { }

Note the data preload property passed to the every route. This is cool technique you can use by creating custom preload modules strategy.



@Injectable()
export class PreloadModulesStrategy implements PreloadingStrategy {
    preload(route: Route, load: () => Observable<any>){
        if (route.data && route.data.preload) {
            return load();
        }
        return of(null);
    }
}

With this you have the ability to choose which pages will be automatically preloaded and which ones will only be loaded when the user lands on a specific route.

🎯 Page modules

I will write about the content of page modules in the future but for it's clear that:

our top level modules are referenced inside of application route
page modules are organised into their own folder
it is easy to find everything related to a page such as subpages, components

🎯 Core and shared modules (folders)

Core module

The CoreModule is usually imported only once in the root module of an Angular application, and it is typically not imported into any other module. By doing so, the CoreModule ensures that the Angular's services and components it provides are only created once and are available to all components and modules within the application.

One of the techniques you can use to ensure that CoreModule is imported only once is by creating a guard.



// guards/ensure-module-loaded-once.guard.ts

export class EnsureModuleLoadedOnceGuard {
    constructor(targetModule: any) {
        if (targetModule) {
            throw new Error(
                `${targetModule.constructor.name} has already been loaded. Import this module in the AppModule only.`
            );
        }
    }
}



// shell/layout.module.ts

@NgModule({
    imports: [CommonModule, RouterModule],
    exports: [HeaderComponent, FooterComponent],
    declarations: [HeaderComponent, FooterComponent]
})
export class LayoutModule extends EnsureModuleLoadedOnceGuard { 
    constructor(@Optional() @SkipSelf() parentModule: LayoutModule) {
        super(parentModule);
    }
}



// core.module.ts
@NgModule({
    imports: [
        HttpClientModule,
    ],
    exports: [
        BrowserModule,
        LayoutModule,
    ],
    providers: [
        PreloadModulesStrategy,
        { provide: HTTP_INTERCEPTORS, useClass: HttpInterceptor, multi: true }
    ]
})
export class CoreModule extends EnsureModuleLoadedOnceGuard {
    constructor(@Optional() @SkipSelf() parentModule: CoreModule) {
        super(parentModule);
    }
}

Some examples of what might be included in a CoreModule are:

Shell components (as header, menu, footer)
Logging and error-handling services
Data services (for API calls)
Interceptors for HTTP requests and responses
Store / application state (like ngrx, ngxs, custom observable store)
Global configuration settings
Models/interfaces/classes
Helper and util classes, methods ...

Services that are specific to a page module can be placed within that module, but it's often better to delay moving them until you're sure they are only used by that specific module.

Shared module

The shared module is typically used to contain presentational components, directives, pipes that can be imported and shared across different modules.

If you look into some examples of typical presentational a.k.a dumb components:

you may notice that these components do not possess any application logic and are not doing actions like such as API calls or being subscribed to state observables. Instead, they obtain data and event handlers as inputs from their parent or container components.

How to set up aliases for module imports in TypeScript (Angular)

Dino Dujmovic — Mon, 17 Apr 2023 15:30:39 +0000

Aliases can be helpful to simplify imports and make the code more readable and maintainable, especially in larger projects with many nested directories.

So, instead of importing files using relative file paths (using the sequence of characters "../../../") that could be looking something like this (or worse):

import { environment } from "../../environment";
import { TTime } from "../../../core/models/types/TTime";
import { GetMovies } from "../../../store/movies/movies.action";
import { MoviesModule } from "../../pages/movies/movies.module"

We can have something more beautiful and consistent like:

import { environment } from "@environment/environment";
import { TTime } from "@core/models/types/TTime";
import { GetMovies } from "@store/movies/movies.action";
import { MoviesModule } from "@pages/movies/movies.module"

We can achieve this by adding paths property to our tsconfig.json (usually placed in root folder of our TS projects).

tsconfig.json (Angular project example):

{
    "compilerOptions": {
        "paths": {
            "@environment/*": [
                "./src/environments/*"
            ],
            "@pages/*": [
                "./src/app/pages/*"
            ],
            "@store/*": [
                "./src/app/store/*"
            ],
            "@core/*": [
                "./src/app/core/*"
            ],
            "@shared/*": [
                "./src/app/shared/*"
            ]
        },
}

The aliases are defined using the paths option, which maps each alias to one or more file paths.

VSCode possible problem

If config doesn't work as expected in VSCode add

"typescript.preferences.importModuleSpecifier": "non-relative"

to your VSCode settings.json.

Install TailwindCSS and DaisyUI CSS Plugin with Angular

Dino Dujmovic — Sat, 15 Apr 2023 20:27:33 +0000

This blog post is dedicated to giving a well-deserved shoutout to DaisyUI.

DaisyUI is a free, open-source plugin for Tailwind CSS that offers a collection of beautiful, pre-designed UI components and breathtaking themes (that are easily customisable).

With over 45 components (and growing), daisyUI makes it easy to create stunning web pages without having to write any custom CSS. DaisyUI includes components like carousels, modals, and dropdowns. And the best part is that many of these components are interactional and working without any JavaScript involved.

With daisyUI, I can quickly create a visually appealing user interface. This is especially useful when I am working on my learning or teaching projects, where I don't want to spend any time on styling the page with custom CSS but still want my application to look super nice.

Here is an example of little side project I created for my students and thanks to DaisyUI adding beautiful styles was effortless!

Installation

I am going to assume that your project is created using Angular CLI.



ng new my-project
cd my-project

Install Tailwind and DaisyUI via npm:



npm install -D tailwindcss daisyui

Add the tailwind directives for each of Tailwind’s layers to your ./src/styles.scss file.



/* You can add global styles to this file, and also import other style files */

@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';

Create tailwind.config.js (manually or use npx tailwindcss init command and add daisyui plugin:



/** @type {import('tailwindcss').Config} /

module.exports = {

  content: [

    "./src//.{html,ts}",

  ],

  theme: {

    extend: {},

  },

  plugins: [require("daisyui")],

  daisyui: {

    themes: true,

    styled: true,

    themes: true,

    base: true,

    utils: true,

    logs: true,

    rtl: false,

  },

}

References:

How to Unsubscribe from observables in Angular (many ways)

Dino Dujmovic — Fri, 14 Apr 2023 16:21:11 +0000

There are many posts and videos out there discussing how to unsubscribe from Observables in Angular, so I was thinking - why shouldn't I write another one?

Introduction

Here are some important things to keep in mind when working with Observables in Angular:

In order to retrieve the value from an Observable, we need to subscribe to it.
Unsubscription does not happen automatically. We are responsible for unsubscribing from the Observable when we no longer need it.
We need to unsubscribe from our Observables because if we don't, they can continue to emit values even after the component is no longer present in the DOM (i.e., destroyed). This can cause memory leaks, as the subscription and associated resources will still be active in memory, even though they are no longer needed.

Async Pipe

The most safe way to approach subscribing and rendering the data in Angular is using async pipe.

When we use the async pipe in our template to bind to an Observable, Angular takes care of subscribing to and unsubscribing from the Observable for us. This means that we don't need to manually subscribe to the Observable in our component code, and we don't need to worry about manually unsubscribing and it also simplifies the code quite a bit.

Note: For examples below MovieService makes HTTP call with Angular's HttpClient module that returns observable

@Component({ 
  template: `
    <div class="movies">
       <div *ngIf="popularMovies$ | async as movies" class="popular-movies">
          <div *ngFor="let movie of movies">{{ movie.title }} </div>
       </div>

       <div *ngIf="trendingMovies$ | async as movies" class="trending-movies">
          <div *ngFor="let movie of movies">{{ movie.title }} </div>
       </div>
    </div>
  `
})
class MovieComponent implements OnInit, OnDestroy {
    popularMovies$: Observable<IMovie[]>;
    trendingMovies$: Observable<IMovie[]>;

    constructor(private movieService: MovieService) { 
       this.popularMovies$ = movieService.getPopularMovies()
       this.trendingMovies$ = movieService.getTrendingMovies()
    }
}

Given the benefits that it provides, I believe that the async pipe should be used wherever possible in Angular applications, but there may be situations where you would need to subscribe/unsubscribe manually and here is how:

1) Basic approach using unsubscribe

@Component({...})
class MovieComponent implements OnInit, OnDestroy {
    popularMoviesSub: Subscription;
    trendingMoviesSub: Subscription;

    constructor(private movieService: MovieService) {
        this.popularMoviesSub = movieService.getPopularMovies().subscribe();
        this.trendingMoviesSub = movieService.getTrendingMovies().subscribe();
    }

    ngOnDestroy() { 
       this.popularMoviesSub.unsubscribe()
       this.trendingMoviesSub.unsubscribe()
    }
}

The problem with this approach is that we could be creating many Subscription properties and we may also easily forget to unsubscribe from all of them.

2) RxJS takeUntil

@Component({...})
export class MovieComponent implements OnInit, OnDestroy {
    destroy$ = new Subject<boolean>();

  constructor(private movieService: MovieService) {
       movieService.getPopularMovies()
            .pipe(takeUntil(this.destroy$))
            .subscribe()
       movieService.getTrendingMovies()
                   .pipe(takeUntil(this.destroy$))
                   .subscribe()
    }

    ngOnDestroy() {
        this.destroy$.next();
    }
}

This is considered to be the most correct reactive programming approach.

However, in my humble opinion it can result in code that is less aesthetically pleasing and harder to understand for many.

3) Simple solution I like to use

My personal belief is that simplicity and readability are critical to writing high-quality code. It's important to strive for code that is clear, concise, and easy to follow, regardless of whether the intended audience is a beginner or an advanced developer.

@Component({...})
export class MovieComponent implements OnInit, OnDestroy {
    private subs = new ManualSubs();

    constructor(private movieService: MovieService) {
       this.subs.add = movieService.getPopularMovies().subscribe();
       this.subs.add = movieService.getTrendingMovies().subscribe();
    }

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

Here is how ManualSubs class looks like:

// manual-subs.ts

export class ManualSubs {
    private subs: Subscription[] = [];

    private isValidSubscription(sub: Subscription) {
        return sub && typeof sub.unsubscribe === "function";
    }

    set add(sub: Subscription) {
        if (this.isValidSubscription(sub)) {
            this.subs.push(sub);
        }
    }

    public unsubscribe() {
        this.subs.forEach((sub: Subscription) => this.isValidSubscription(sub) && sub.unsubscribe());
        this.subs = [];
    }
}

Never forget to test!

// manual-subs.spec.ts

describe("ManualSubs", () => {
    let manualSubs: ManualSubs;
    let sub1: Subscription;
    let sub2: Subscription;

    beforeEach(() => {
        manualSubs = new ManualSubs();
        sub1 = jasmine.createSpyObj("Subscription", ["unsubscribe"]);
        sub2 = jasmine.createSpyObj("Subscription", ["unsubscribe"]);
    });

    it("should unsubscribe from all subscriptions", () => {
        manualSubs.add = sub1;
        manualSubs.add = sub2;
        manualSubs.unsubscribe();
        expect(sub1.unsubscribe).toHaveBeenCalledTimes(1);
        expect(sub2.unsubscribe).toHaveBeenCalledTimes(1);
    });
});

Existing libraries using this approach:

However, it's worth considering whether you truly need an external npm module for a relatively small amount of code, especially when you could easily write, manage, expand, and use your own naming conventions.

Summary

The approaches discussed are some of the most straightforward and commonly used methods for managing subscriptions.
However, there are also other more "advanced" techniques available that can simplify subscription management and reduce boilerplate code, such as using Angular decorators.

As always we can implement those ourselves, but there are some nice solutions out there if some would prefer.

Set Up ESLint with Angular and the Airbnb Style Guide (effortlessly)

Dino Dujmovic — Thu, 13 Apr 2023 19:22:07 +0000

In this post I will walk you through my usual ESLint setup for Angular projects.
If you want to do this effortlessly just jump to Summary.

As a starting point I will assume that your project is created using Angular CLI.

ng new my-project

Our starting point is going to be a very cool and easy to use
@angular-eslint/eslint-plugin.

🎯 1. Installing ESLint

Change directory into your new workspace and then use the Angular CLI to add @angular-eslint/schematics.

ng add @angular-eslint/schematics

This will:

add ng lint command to your package.json and angular.json
create starting .eslintrc.json configuration file
add schematic collection to angular.json file so files generated by Angular CLI will be created using ESLint rules
install and add eslint and angular-eslint packages to your package.json dev dependencies

 // package.json devDependencies

 "@angular-eslint/builder": "15.2.1",
 "@angular-eslint/eslint-plugin": "15.2.1",
 "@angular-eslint/eslint-plugin-template": "15.2.1",
 "@angular-eslint/schematics": "15.2.1",
 "@angular-eslint/template-parser": "15.2.1",
 "@typescript-eslint/eslint-plugin": "5.48.2",
 "@typescript-eslint/parser": "5.48.2",
 "eslint": "^8.33.0",

You can find more information about @anguar-eslint plugin here.

🎯 2. Setting up linting rules with Airbnb Style Guide

Setting up linting rules for your codebase is a matter of personal preference and team agreement. With hundreds of potential rules to choose from, manually configuring them all from scratch can be a daunting task that requires significant time and resources.

One popular and widely used style guide for writing clean and consistent JavaScript code is the Airbnb style guide. This guide provides a comprehensive set of guidelines that can help ensure your code is readable, maintainable, and bug-free. Personally, I prefer to use the Airbnb style guide for my projects.

To ensure that ESLint works well with Angular, I use two following packages.

I also prefer to have my used imports arranged in a consistent order. To achieve this, I use ESLint plugins with self-explanatory names.

npm install eslint-config-airbnb-base eslint-config-airbnb-typescript eslint-plugin-simple-import-sort eslint-plugin-unused-imports --save-dev

My final .eslintrc.json version would look like this.

{
    "root": true,
    "ignorePatterns": [
        "projects/**/*"
    ],
    "plugins": ["unused-imports", "simple-import-sort"],
    "parserOptions": {
        "project": "./tsconfig.json"
    },
    "overrides": [
        {
            "files": [
                "*.ts"
            ],
            "extends": [
                "airbnb-base",
                "airbnb-typescript/base",
                "plugin:@typescript-eslint/recommended",
                "plugin:@angular-eslint/recommended",
                "plugin:@angular-eslint/template/process-inline-templates"
            ],
            "rules": {
                // ESLint rules
                "import/prefer-default-export": "off",
                "import/first": "error",
                "import/newline-after-import": "error",
                "import/no-duplicates": "error",
                "max-len": [
                    "error",
                    120
                ],
                "simple-import-sort/imports": "error",
                "simple-import-sort/exports": "error",
                // eslint-plugin-unused-imports rules
                "unused-imports/no-unused-imports": "error",
                "unused-imports/no-unused-vars": [
                    "warn",
                    { "vars": "all", "varsIgnorePattern": "^_", "args": "after-used", "argsIgnorePattern": "^_" }
                ],
                // TypeScript Eslint rules
                "@typescript-eslint/indent": [
                    "error",
                    4
                ],
                "@typescript-eslint/comma-dangle": "off",
                "@typescript-eslint/lines-between-class-members": "off",
                "@typescript-eslint/quotes": ["error","double"],
                "@typescript-eslint/no-shadow": "error",
                "@typescript-eslint/no-explicit-any": 0,
                // Angular ESLint rules
                "@angular-eslint/directive-selector": [
                    "error",
                    {
                        "type": "attribute",
                        "prefix": "app",
                        "style": "camelCase"
                    }
                ],
                "@angular-eslint/component-selector": [
                    "error",
                    {
                        "type": "element",
                        "prefix": "app",
                        "style": "kebab-case"
                    }
                ]
            }
        },
        {
            "files": [
                "*.html"
            ],
            "extends": [
                "plugin:@angular-eslint/template/recommended"
            ]
        }
    ]
}

🎯 Summary

1) Create Angular project using Angular CLI

ng new my-project

2). Change directory to your project and run

ng add @angular-eslint/schematics

3) Install Airbnb ESlint and plugins for import handling

npm install eslint-config-airbnb-base eslint-config-airbnb-typescript eslint-plugin-simple-import-sort

4) Copy my .eslintrc.json configuration specified above

5) Run

ng lint

While you are working you may discover rules that you don't agree with, or that aren't necessary or appropriate for your particular project. When this happens, you can easily enable or disable specific rules by adding them to the "rules" property inside your .eslintrc.json file.

The right rules are your own rules.
Have fun configuring your linter!