Forem: Rens Jaspers

Looks like we can finally let our AI assistants use modern Angular techniques without the hassle!

Rens Jaspers — Sun, 23 Mar 2025 06:01:03 +0000

Getting Better LLM Responses Using AI-Friendly Documentation

Gergely Szerovay for This is Angular ・ Mar 19

#ai #llm #angular #mcp

[Boost]

Rens Jaspers — Sun, 23 Mar 2025 05:58:48 +0000

Getting Better LLM Responses Using AI-Friendly Documentation

Gergely Szerovay for This is Angular ・ Mar 19

#ai #llm #angular #mcp

How to Easily Notify Users About Task Progress in Angular

Rens Jaspers — Wed, 09 Oct 2024 17:38:35 +0000

I found myself repeatedly writing the same code to notify users of the status of asynchronous tasks — whether the task was still in progress, completed successfully, or had failed.

In this post, I’ll show you how to create a TaskStatusNotifierService to handle these notifications, reducing the amount of repetitive code and letting you focus on the task’s actual logic.

I'll use Ionic in my example, but you can modify the service to work with any Angular project.

The Problem

In every component, I kept doing the following:

Injecting these three controllers:

LoadingController (to show a spinner while the task runs)
ToastController (to show a message when the task completes)
AlertController (to show an alert if the task fails)

2. Using the controllers:

Create and present a loader before the async task starts, and wait for it to appear on the screen.
Run the task, then dismiss the loader and wait for it to disappear.
After dismissing the loader, show a toast if the task was successful, or an alert if it failed.

All the Ionic controllers are asynchronous and follow a create/present/dismiss pattern, which adds more code.

The code looked like this:

@Component({})
class MyComponent {
  constructor(
    private loadingController: LoadingController,
    private toastController: ToastController,
    private alertController: AlertController,
    private apiService: ApiService
  ) {}

  async save(data: any) {
    const loader = await this.loadingController.create({
      message: "Saving..."
    });
    await loader.present();

    try {
      await this.apiService.save(data);
      await loader.dismiss();
      const toast = await this.toastController.create({
        message: "Saved successfully",
        duration: 3000,
      });
      await toast.present();
    } catch (error) {
      await loader.dismiss();
      const alert = await this.alertController.create({
        header: "Failed to save",
        message: error.message,
        buttons: ["OK"],
      });
      await alert.present();
    }
  }
}

Even in this simple example, you can see that the code is repetitive and hard to maintain. If I want to change how I display the loader, toast, or alert globally, I'd have to update every component.

The Solution

Let's create a TaskStatusNotifierService that contains all the repetitive code. This service has a method called run that takes a task and runs it.

Now, I only need to inject the TaskStatusNotifierService in my components and call the run method with the task I want to execute:

@Component({})
class MyComponent {
  constructor(
    private taskStatusNotifierService: TaskStatusNotifierService,
    private apiService: ApiService
  ) {}

  save(data: any) {
    this.taskStatusNotifierService.run(() => this.apiService.save(data));
  }
}

The TaskStatusNotifierService handles showing the loader, running the task, and showing the toast or alert when the task finishes.

Here's how the TaskStatusNotifierService looks:

@Injectable({ providedIn: "root" })
export class TaskStatusNotifierService {
  constructor(
    private loadingController: LoadingController,
    private toastController: ToastController,
    private alertController: AlertController
  ) {}

  async run(task: () => Promise<any>) {
    const loader = await this.loadingController.create({
      message: "Loading..."
    });
    await loader.present();

    try {
      await task();
      await loader.dismiss();
      const toast = await this.toastController.create({
        message: "Task completed successfully",
        duration: 3000,
      });
      await toast.present();
    } catch (error) {
      await loader.dismiss();
      const alert = await this.alertController.create({
        header: "Task failed",
        message: error.message,
        buttons: ["OK"],
      });
      await alert.present();
    }
  }
}

Using Observables

If your apiService.save returns an Observable instead of a Promise, you can convert it using lastValueFrom from rxjs:

import { lastValueFrom } from "rxjs";

@Component({})
class MyComponent {
  constructor(
    private taskStatusNotifierService: TaskStatusNotifierService,
    private apiService: ApiService
  ) {}

  save(data: any) {
    this.taskStatusNotifierService.run(() =>
      lastValueFrom(this.apiService.save(data))
    );
  }
}

Why `lastValueFrom`?

Some Observables may emit multiple values. In our TaskStatusNotifierService, we care about the last value. We don't want to show a success message and dismiss the loader on the first emission if there are more to come, so we use lastValueFrom.

Customizing Messages

We can update the service to allow customizing the loading, success, and error messages by passing them as parameters:

@Component({})
class MyComponent {
  constructor(
    private taskStatusNotifierService: TaskStatusNotifierService,
    private apiService: ApiService
  ) {}

  save(data: any) {
    this.taskStatusNotifierService.run(() => this.apiService.save(data), {
      loadingMessage: "Saving...",
      successMessage: "Saved successfully",
      errorMessage: "Failed to save",
    });
  }
}

Update the TaskStatusNotifierService to accept these parameters:

@Injectable({ providedIn: "root" })
export class TaskStatusNotifierService {
  constructor(
    private loadingController: LoadingController,
    private toastController: ToastController,
    private alertController: AlertController
  ) {}

  async run(
    task: () => Promise<any>,
    options: {
      loadingMessage?: string;
      successMessage?: string;
      errorMessage?: string;
    } = {}
  ) {
    const loadingMessage = options.loadingMessage || "Loading...";
    const successMessage =
      options.successMessage || "Task completed successfully";
    const errorMessage = options.errorMessage || "Task failed";

    const loader = await this.loadingController.create({
      message: loadingMessage
    });
    await loader.present();

    try {
      await task();
      await loader.dismiss();
      const toast = await this.toastController.create({
        message: successMessage,
        duration: 3000,
      });
      await toast.present();
    } catch (error) {
      await loader.dismiss();
      const alert = await this.alertController.create({
        header: errorMessage,
        message: error.message,
        buttons: ["OK"],
      });
      await alert.present();
    }
  }
}

If you need more control over the messages, you can pass functions that generate messages based on the result or error:

@Component({})
class MyComponent {
  constructor(
    private taskStatusNotifierService: TaskStatusNotifierService,
    private apiService: ApiService
  ) {}

  save(data: any) {
    this.taskStatusNotifierService.run(() => this.apiService.save(data), {
      loadingMessage: "Saving...",
      getSuccessMessage: (result) => `Saved item. ID: ${result.id}`,
      getErrorMessage: (error) => `Something went wrong: ${error.message}`,
    });
  }
}

Update the TaskStatusNotifierService accordingly:

@Injectable({ providedIn: "root" })
export class TaskStatusNotifierService {
  constructor(
    private loadingController: LoadingController,
    private toastController: ToastController,
    private alertController: AlertController
  ) {}

  async run(
    task: () => Promise<any>,
    options: {
      loadingMessage?: string;
      getSuccessMessage?: (result: any) => string;
      getErrorMessage?: (error: any) => string;
    } = {}
  ) {
    const loadingMessage = options.loadingMessage || "Loading...";
    const getSuccessMessage =
      options.getSuccessMessage || (() => "Task completed successfully");
    const getErrorMessage = options.getErrorMessage || (() => "Task failed");

    const loader = await this.loadingController.create({
      message: loadingMessage
    });
    await loader.present();

    try {
      const result = await task();
      await loader.dismiss();
      const toast = await this.toastController.create({
        message: getSuccessMessage(result),
        duration: 3000,
      });
      await toast.present();
    } catch (error) {
      await loader.dismiss();
      const alert = await this.alertController.create({
        header: getErrorMessage(error),
        message: error.message,
        buttons: ["OK"],
      });
      await alert.present();
    }
  }
}

You can even extend the service to allow full control over the success and error modals by passing functions that return options for the controllers.

With this TaskStatusNotifierService, you can simplify your code and focus on what really matters—the logic of your tasks. Feel free to expand and customize the service to suit your needs. It's a great starting point for handling asynchronous tasks in your Angular projects.

How to Dockerize an Angular App for Production

Rens Jaspers — Mon, 05 Aug 2024 10:43:45 +0000

In this article, we will learn how to containerize an Angular app for production. Our goal is to use the same build for all environments: test, staging, and production, and make sure it is easy to configure, secure, and fast.

Requirements

Single Build for All Environments: We want to build our Angular app once and use that same build for every environment. Normally, Angular encourages you to create different environment files like environment.ts, environment.staging.ts, and environment.prod.ts, which requires creating different builds for different environments. We want to avoid that and use system environment variables instead.
Easy Reverse-Proxy Configuration: Our backend APIs do not support CORS. We prefer to keep everything on a single origin.
Secure and Good Performance: We want to use a web server that is easy to configure, secure, and offers good performance. Using the development server (ng serve) is not recommended for production due to security and performance issues.
Redirects: For deep links in our Angular app, we want to redirect to the Angular app's index.html file.

Using Caddy

Caddy is a web server that is easy to configure and offers good performance. It allows us to set up reverse proxies easily with a Caddyfile and environment variables.

Most guides out there use Nginx as the server component, but I found it very tedious to create a configuration that lets me configure reverse proxy URLs through environment variables.

Example Caddy Configuration

To configure Caddy for our Angular app, we create a Caddyfile that specifies how to serve our app and set up reverse proxies:

# Caddyfile

{
    # Global options can be specified here if needed
    # (currently none are needed)
}

# Angular app server configuration block:
:80 {
    root * ./www
    file_server

    handle_path /api/* {
        reverse_proxy {$API_URL} {
            header_up Host {upstream_hostport}
        }
    }

    handle_path /telemetry/* {
        reverse_proxy {$TELEMETRY_COLLECTOR_URL} {
            header_up Host {upstream_hostport}
            header_up X-API-KEY {$TELEMETRY_API_KEY}
        }
    }

    # Rewrite for deep links if the file does not exist.
    # Without this rule, deep links to Angular routes will return
    # a 404 error (unless you use Angular's HashLocationStrategy).
    @notFound {
        not path /api/*
        not path /telemetry/*
        not file {path}
    }

    rewrite @notFound /index.html
}

This Caddy configuration file does the following:

Serve the Angular App: The root * ./www directive tells Caddy to serve files from the ./www directory. This is where we will copy the Angular build output.
Reverse Proxy Configuration: The handle_path directives set up reverse proxies for the API and telemetry endpoints. We use placeholders like {$API_URL} and {$TELEMETRY_COLLECTOR_URL} to specify the URLs. We can set these placeholders using environment variables.
Rewrite for Deep Links: The rewrite directive handles deep links in the Angular app. If the requested file does not exist, Caddy will rewrite the request to index.html. This is necessary for Angular's HTML5 routing mode.

Example Dockerfile

Next, we need to create a Dockerfile that will build our Angular app and configure Caddy to serve it.

In this example, we have an Angular 18 app set up.

Important: The output path of the Angular build depends on your Angular version and the project name! In my case, it is dist/my-containerized-angular-app-example/browser. This is important because we need to copy the Angular build output to the correct location in the final image. Be sure to check where your Angular build outputs the files (by running ng build manually) and adjust the Dockerfile accordingly.

Here is an example Dockerfile:

# Dockerfile

# Stage 1: Build the Angular app
FROM node:20-alpine as build-angular

# Set the working directory for the build
WORKDIR /build

# Copy package.json and package-lock.json to leverage Docker cache for npm install
COPY package*.json ./

# Install the dependencies
RUN npm install

# Copy the source code for the Angular app to the build directory
COPY . .

# Install the dependencies and build the Angular app
RUN npm install
RUN npm run build

# Stage 2: Create the final image
FROM caddy:latest

# Set the working directory for the final container
WORKDIR /app

# Copy the Angular build output to the final location
COPY --from=build-angular /build/dist/my-containerized-angular-app-example/browser ./www

# Copy the Caddyfile to the final location
COPY Caddyfile /etc/caddy/Caddyfile

# Expose the port for Caddy
EXPOSE 80

# Command to start Caddy
CMD ["caddy", "run", "--config", "/etc/caddy/Caddyfile"]

The Dockerfile has two stages:

Build the Angular app: In this stage, we use the node:20-alpine image to build the Angular app. We copy the source code to the build directory, install the dependencies, and build the Angular app using npm install and npm run build.
Create the final image: In this stage, we use the caddy:latest image as the base image. We set the working directory for the final container to /app. We copy the Angular build output from the previous stage to the final location in the container (./www). We also copy the Caddyfile to the final location in the container (/etc/caddy/Caddyfile). We expose port 80 for Caddy, and we specify the command to start Caddy.

Example Docker Ignore File

To keep our Docker image clean and small, we create a .dockerignore file to exclude unnecessary files from the build context:

# .dockerignore

# Ignore node_modules
node_modules

# Ignore build outputs
dist
build

# Ignore environment files (secrets)
*.env
.env.*

# Ignore local Angular cache
.angular/cache

Example Docker Compose File

We can use Docker Compose to manage our Docker containers. Here is an example docker-compose.yml file that defines our Angular app service:

services:
  my-containerized-angular-app-example:
    # Build the Docker image using the Dockerfile in the current directory
    build:
      context: .

    # Map port 80 in the container to port 3000 on the host machine
    ports:
      - "3000:80"

    # Load environment variables from the .env file
    env_file:
      - .env

Example Environment File

Finally, we need to create an .env file to store our environment variables. Here is an example .env file:

# .env
API_URL=https://api.example.com
TELEMETRY_COLLECTOR_URL=https://telemetry.example.com
TELEMETRY_API_KEY=your-telemetry-api-key

Building and Running the Docker Container

To build and run the Docker container, we can simply run:

docker compose up

Then our app will be accessible at http://localhost:3000.

If we want to deploy the container to our staging or production environment, we simply change the API_URL and TELEMETRY_COLLECTOR_URL environment variables in the .env file. No rebuild is necessary!

Working Example

For a complete working example, you can visit the GitHub repository: github.com/rensjaspers/containerized-angular-app-example. This repository includes all the files and configurations discussed in this article.

I hope this article helps you containerize your Angular app for production. If you have any questions or feedback, feel free to leave a comment below. Happy coding!

How To Easily Expand or Collapse All Accordion Items in IonAccordionGroup at Once Without Adding Complexity

Rens Jaspers — Wed, 19 Jun 2024 11:49:24 +0000

The Ionic Accordion Group and the ion-accordion are awesome. Accordions provide collapsible sections in your content to reduce vertical space while organizing and grouping information.

However, I feel there's an important feature that's missing: the ability to easily expand or collapse all accordion items at once.

While it's technically possible to expand or collapse all items at once, the current method is quite cumbersome. You have to use <ion-accordion-group [value]="valuesOfTheAccordionsThatShouldBeExpanded"> and pass an array of all the values of the accordions (or an empty array if you want to collapse all). This approach is problematic for several reasons:

Typically, you don't want to assign a value to each accordion manually. Ionic already handles this automatically, but as a developer, you can't easily see these values.
Your component suddenly has an extra responsibility: managing the state of each accordion group. This adds unnecessary complexity to your app.

Generally, I appreciate that the Ionic team keeps things lean and leaves extra functionalities to the developer. However, in this case, I would have liked to see an accordionGroup.toggleAll / expandAll / collapseAll method.

Fortunately, with Angular directives, it's relatively simple to add this functionality cleanly.

Here's an example:

import { ContentChildren, Directive, QueryList } from "@angular/core";
import { IonAccordion, IonAccordionGroup } from "@ionic/angular/standalone";

@Directive({
  selector: "[appAccordionGroupToggle]",
  exportAs: "appAccordionGroupToggle",
  standalone: true,
})
export class AccordionGroupToggleDirective {
  @ContentChildren(IonAccordion) accordions!: QueryList<IonAccordion>;

  get isCompletelyExpanded() {
    const groupValue = this.host.value;
    return (
      Array.isArray(groupValue) && groupValue?.length === this.accordions.length
    );
  }

  constructor(private host: IonAccordionGroup) {}

  toggle() {
    if (this.isCompletelyExpanded) {
      this.collapse();
    } else {
      this.expand();
    }
  }

  expand() {
    this.host.value = this.accordions.map((accordion) => accordion.value);
  }

  collapse() {
    this.host.value = [];
  }
}

The directive works by using @ContentChildren to get a reference to all ion-accordion items within the accordion group. This allows the directive to access the state (and thus the values) of all the accordions collectively. The constructor injects the host IonAccordionGroup, providing access to the group’s properties and methods.

In the expand method, the directive sets the value of the host accordion group to an array containing the values of all the individual accordions, effectively expanding all of them. In the collapse method, it sets the value to an empty array, collapsing all the accordions.

The toggle method first checks if all accordions are already open by checking the value of isCompletelyExpanded. If it equals true, it collapses them; if not, it expands them.

You can use the directive as follows (don't forget to import the directive in your component):

<ion-content>
  <ion-button (click)="toggler.toggle()">Toggle all</ion-button>
  <ion-button (click)="toggler.expand()">Expand all</ion-button>
  <ion-button (click)="toggler.collapse()">Collapse all</ion-button>
  <ion-accordion-group
    appAccordionGroupToggle
    #toggler="appAccordionGroupToggle"
  >
    <ion-accordion>
      <ion-item slot="header">
        <ion-label>First Accordion</ion-label>
      </ion-item>
      <div slot="content">😎</div>
    </ion-accordion>
    <ion-accordion>
      <ion-item slot="header">
        <ion-label>Second Accordion</ion-label>
      </ion-item>
      <div slot="content">🤩</div>
    </ion-accordion>
    <ion-accordion>
      <ion-item slot="header">
        <ion-label>Third Accordion</ion-label>
      </ion-item>
      <div slot="content">💪</div>
    </ion-accordion>
  </ion-accordion-group>
</ion-content>

In the above example, we use #toggler to create a reference to the instance of the Group toggle. This is possible because we set exportAs: 'appAccordionGroupToggle' in our directive. Now, we can call any of the public methods (toggle, expand, and collapse) directly from our template.

That's it! Now you can use this directive to easily toggle all accordions at once anywhere you like. While I hope the Ionic team will add expand, collapse, and toggle methods to ion-accordion-group in the near future, it's great that Angular components make it so easy to add the desired functionality yourself.

Stop Pretending The Error Never Happened! Be Explicit About Loading State

Rens Jaspers — Tue, 27 Feb 2024 18:02:09 +0000

We all need to stop using placeholder values that look like correctly resolved values in RxJS streams that error out!

This is a pattern you see in many tutorials:

items$ = this.http.get("api/items").pipe(
  catchError(() => of([]))
);

It loads data asynchronously with RxJS, making an HTTP call to fetch a list of items from an API, and then uses the catchError operator to catch errors. But then instead of passing on an error value, it just returns a value as if it came from the API: of([]).

This approach is very dangerous and confusing for your users. For example, in your template, if you have:

@for(item of items$ | async; track item.id) {
  <div>{{ item.title }}</div>
} @empty {
  You have no items
}

...it’ll show you have no items even if there was an error. It’s misleading! How is the user going to know what is going on? Do they really have zero items or is something wrong?

I get it: those tutorials probably want to skip proper error handling to keep videos or blog posts short, but it's better to omit catchError entirely than to teach incorrect practices. Errors should be displayed as errors!

So, how should it be done correctly?

Easy: just be explicit about returning error values. Be explicit about loading state. This can be as simple as mapping your resolved value to a loading state object such as (items) => ({ data: items, state: "loaded" }) and your errors to (error) => ({ error, state: "error" }).

The full type could be something like:

type LoadingState<T = unknown> =
  | { state: 'loading' }
  | { state: 'loaded'; data: T }
  | { state: 'error'; error: Error };

In your template, you can then clearly show an error if there is one, avoiding misleading the user.

For example:

emails$ = this.emailService.getEmails().pipe(
  map(emails => ({ state: "loaded", data: emails })),
  catchError(error => of({ state: "error", error })),
  startWith({state: "loading"})
);

Just like you should be explicit about error states, you should be explicit about load completion. I recommend always including a state property that explicitly indicates that the loading process is complete. This is another area poorly explained in tutorials: a loaded state is often implicitly equated with truthy values, which is not always accurate.

Avoid having to assume the loading state based on the raw value of your stream. Instead of guessing:

@if(emailCount$ | async; as count) {
  {{ count }} emails
} @else {
  Loading…
}

…which wrongly shows "Loading…" when the resolved email count equals a falsy 0, just be clear about the state by using explicit indicators.

Here’s a full example of how you could track loading and error states so you can accurately show your user what’s going on:

@Component({
  selector: 'app-root',
  template: `
    @if (emails$ | async; as emails) {
      @switch (emails.state) {
        @case ("loading") { Loading... }
        @case ("error") { Error: {{emails.error.message}} }
        @case ("loaded") {
          @for (let email of emails.data; track email.id); {
            <div>{{email.title}}</div>
          }
          @empty { You have no emails. }
        }
      }
    }
  `
})
export class AppComponent {
  private emailService = inject(EmailService);
  emails$ = this.emailService.getEmails().pipe(
    map(emails => ({data: emails, state: "loaded"})),
    catchError(error => of({error, state: "error"})),
    startWith({state: "loading"})
  );
}

As you can see, being explicit about loading state and handling all the different outcomes does lead to a lot of boilerplate, and you should probably create some kind of reusable code for it.

This is exactly what I set out to do when I created *ngxLoadWith, a structural directive that lets you do all of the above in a declarative way.

Loading data will be as simple as this:


@Component({
  selector: 'app-root',
  …
})
export class AppComponent {
  private emailService = inject(EmailService);
  emails$ = this.emailService.getEmails();
}

<div *ngxLoadWith="emails$ as emails">
  @for (email of emails; track email.id) {
    <div>{{ email.title }}</div>
  } @empty { 
    You have no emails. 
  }
</div>

If you want to show error and loading screens, just add references to ng-template:


<div *ngxLoadWith="emails$ as emails; loadingTemplate: loading; errorTemplate: error"  ">
  @for (email of emails; track email.id) {
    <div>{{ email.title }}</div>
  } @empty { 
    You have no emails. 
  }
</div>
<ng-template #loading>Loading...</ng-template>
<ng-template #error let-error>{{ error.message }}</ng-template>

…at the small cost of adding a tiny 1.92 kb dependency to your Angular project.

Please check it out at https://github.com/rensjaspers/ngx-load-with and let me know what you think. If you find it useful, a star 🌟 is highly appreciated.

Stop Overloading Your Angular Components: Start Using Host Directives!

Rens Jaspers — Sat, 27 Jan 2024 10:16:44 +0000

When we build Angular apps, sometimes our components do too much. Take an AppComponent, for instance, that's burdened with tasks like changing the page title, receiving app updates, logging the app version, and tracking user clicks. These functions, though important, don't align with the component's main role of displaying content. As a result, AppComponent becomes crowded and complex, deviating from its primary purpose. This is where Angular's directives help. They are a simple solution that makes it easier to handle these tasks.

Directives in Angular allow us to neatly separate these side tasks from the component's core functionalities. By assigning responsibilities like click tracking and logging to directives, we prevent the main component from becoming overwhelmed. This leads to a cleaner, more focused AppComponent that sticks to displaying and interacting with content. Directives keep our apps organized, making them simpler and easier to handle.

Example of a 'Do Everything Component':


import { Component, OnInit, HostListener } from '@angular/core';
import { TitleService } from './title.service';
import { UpdateService } from './update.service';
import { VersionLoggerService } from './version-logger.service';
import { ClickTrackingService } from './click-tracking.service';

@Component({
  selector: 'app-root',
  template: `...`,
  // ...
})
export class AppComponent implements OnInit {
  constructor(
    // Ugh, so many injected services!
    private titleService: TitleService,
    private updateService: UpdateService,
    private versionLoggerService: VersionLoggerService,
    private clickTrackingService: ClickTrackingService
  ) {}

  ngOnInit() {
    // Updating the title
    this.titleService.updateTitle('App Title');

    // Subscribing to app updates
    this.updateService.getAppUpdates().subscribe(update => {
      // Handle update logic
    });

    // Logging the app version
    this.versionLoggerService.logVersion();

    // Other unrelated behaviors can also be added here
  }

  @HostListener('click', ['$event'])
  trackClick(event: Event) {
    this.clickTrackingService.trackClick(event);
  }
}

Now lets create some directives to help us move these extra jobs out of our component. We can make a special directive for each job, like one for changing the page title and another for tracking clicks. This keeps our components simple and focused on their main job.

// update-title.directive.ts

import { Directive, OnInit } from '@angular/core';
import { TitleService } from './title.service';

@Directive({
  selector: '[updateTitle]',
})
export class UpdateTitleDirective implements OnInit {
  constructor(private titleService: TitleService) { }

  ngOnInit() {
    this.titleService.updateTitle('New Title');
  }

}

// click-track.directive.ts

import { Directive, HostListener } from '@angular/core';
import { ClickTrackingService } from './click-tracking.service';

@Directive({
  selector: '[appClickTrack]',
})
export class ClickTrackDirective {

  constructor(private clickTrackingService: ClickTrackingService) {}

  @HostListener('click', ['$event'])
  onHostClick(event: MouseEvent): void {
    this.clickTrackingService.trackClick(event);
  }
}

As you can see, each directive handles one job. This makes them easier to work with and check. For instance, the directive for changing the page title does just that. It keeps its job separate from the rest of the app's code.

Adding these directives to our components is easy. We use hostDirectives in the @Component part to put in our new directives. Now, AppComponent is more about showing content and less about doing many different jobs.


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

@Component({
  selector: 'app-root',
  template: `...`,
  hostDirectives: [UpdateTitleDirective, AppUpdateAlertDirective, LogVersionDirective, ClickTrackDirective] // Put your host directives here!
})
export class AppComponent {
  // AppComponent focuses on its template-related logic only
}

In the end, using directives in Angular for tasks that don't deal with showing content is a really good idea. It makes our components simpler and less full of different tasks. Building and maintaining our app becomes easier. The components stay focused on their main job – showing things to users. Using directives this way keeps our app neat and easy to work with.

How to Include Version, Git Commit, and Build Date in Your Angular Builds

Rens Jaspers — Wed, 03 Jan 2024 19:39:35 +0000

Knowing the exact version of your Angular app can be really helpful. This article will teach you how to add your app's package version, git commit hash, and build date to your builds. You'll also learn how to access this information within your Angular app.

1. Create a File for Version Information

Make a file named version.ts in the src/environments/ folder.

Add placeholders for the app version, build date, and commit hash, like this:

// src/environments/version.ts
export const version = "0.0.0-development";
export const buildDate = new Date().toISOString();
export const commitHash = "development";

Then, you can use this version information in your Angular code. Here's how you might do it:

import { Injectable } from "@angular/core";
import { version, buildDate, commitHash } from "src/environments/version";

@Injectable({
  providedIn: "root",
})
export class VersionService {
  getVersion(): string {
    return `Version ${version}, commit ${commitHash}, built at ${buildDate}`;
  }
}

2. Write a Script to Update Version Information

Make a file called update-version.js in your project's main folder.

This script will automatically fill in the real version and commit hash using Node.js code. Here's an example:

const fs = require("fs");
const execSync = require("child_process").execSync;

const version = require("./package.json").version;
const commitHash = execSync("git rev-parse --short HEAD").toString().trim();
const buildDate = new Date().toISOString();

const content = `export const version = '${version}';
export const buildDate = '${buildDate}';
export const commitHash = '${commitHash}';`;

fs.writeFileSync("./src/environments/version.prod.ts", content);

console.log("Updated version!", { version, commitHash, buildDate });

3. Add a Prebuild Script to Your Project

In your package.json file, add a prebuild script in the "scripts" section.

This script should run node update-version.js before each build. Your package.json should include something like this:

"scripts": {
  "prebuild": "node update-version.js"
}

4. Update Your Build Configuration

In the angular.json file, make a change to use version.prod.ts instead of version.ts when you build your app. Here's how you can set it up:

"fileReplacements": [
  {
    "replace": "src/environments/version.ts",
    "with": "src/environments/version.prod.ts"
  }
]

5. Ignore the Generated Version File

If you want, you can add version.prod.ts to your .gitignore file. This keeps the automatically generated file out of your code repository.

Working example: https://github.com/rensjaspers/add-version-to-angular-build

I hope this article was helpful to you. If you've found a better way to implement this, I'd be very interested to hear about it.

Reactive Loading State Management with RxJS and Angular: Loading Stuff Based on Changes to Other Stuff

Rens Jaspers — Thu, 06 Jul 2023 16:03:00 +0000

When you build apps with Angular, you often need to get data when something changes in your app. These changes could come from a user's action, like typing in a search box, or from the app itself, such as a change in the route parameters. Today, we're going to learn some effective ways to reactively fetch data in response to these changes.

Responding to user input

Imagine a scenario where we want to show search results as the user types into a search box:

@Component({
  selector: 'my-app',
  standalone: true,
  imports: [CommonModule, ReactiveFormsModule],
  template: `
    <input [formControl]="searchControl" />

    <div *ngIf="result$ | async as result">
        {{ result }}
    </div>
  `,
})
export class App {
  // We are using a FormControl to watch the user's input
  searchControl = new FormControl('');

  result$ = this.searchControl.valueChanges.pipe(
    switchMap(keywords => this.http.get('/api/search', {params: { q: keywords }))
  );

  private http = inject(HttpClient);
}

In this example, searchControl.valueChanges is an Observable. This Observable sends out an event each time the user changes the text in the search box. We then use something called the switchMap operator from RxJS. This operator lets us make a fresh data request each time the user changes the text. It also makes sure we only work with the results for the latest text input. This is very important for keeping your app speedy and pleasant for the user.

We use *ngIf with the async pipe so that the template automatically connects to our result$ Observable and updates itself. This makes sure that the template always shows the newest search results to the user in real-time as they type into the search box.

Managing loading and error states with RxJS

A key part of getting data is giving feedback to the user during the entire loading process. This could be a loading message or an error message. Instead of using separate isLoading or hasError variables in our components, we'll use some RxJS operators called map, catchError, startWith, and scan.

Let's have a look at the following example:

interface LoadingState<T = unknown> {
  loading: boolean;
  error?: Error | null;
  data?: T;
}

@Component({
  selector: 'my-app',
  standalone: true,
  imports: [CommonModule, ReactiveFormsModule],
  template: `
    <input [formControl]="searchControl" />

    <div *ngIf="result$ | async as result">
      <div *ngIf="result.loading">Loading...</div>
      <div *ngIf="result.data as data">{{data}}</div>
      <div *ngIf="result.error as error">{{error.message}}</div>
    </div>
  `,
})
export class App {
  searchControl = new FormControl('');

  result$ = this.searchControl.valueChanges.pipe(
    switchMap((value) =>
      this.http.get('/api/search', {params: { q: value }).pipe(
        map((data) => ({ data, loading: false })),
        catchError((error) => of({ error, loading: false })),
        startWith({ error: null, loading: true })
      )
    ),
    scan((state: LoadingState<string>, change: LoadingState<string>) => ({
      ...state,
      ...change,
    }))
  );

  private http = inject(HttpClient);
}

In the code above:

We use map to change the raw data from the HTTP request into an object. This object includes the data and a loading flag that is set to false.
We use catchError to manage any errors that happen during the HTTP request. If an error happens, it gives back an Observable with an object. This object includes the error and a loading flag that is set to false.
We use startWith to begin the stream with a specific value. Here, it starts with an object that includes a null error and a loading flag set to true. This makes sure that the user sees a loading state before any data is loaded.
scan works like Array.reduce. It takes the previous state and the new changes and mixes them into a new state. Here, it takes the previous loading state and blends it with the changes from the HTTP request result. This way, we keep a constant stream of state changes, each adding in the changes of the one before it.
Now, in your template, you can use Angular's async pipe to subscribe to result$, and use *ngIf to show different parts of the template based on the loading state.

These operators look complicated! Why not just use separate isLoading and hasError variables?

Even if it looks easier to use this.isLoading or this.hasError variables in your component, using RxJS operators gives you better control.

When your loading and error states are inside the data stream, they're tied to the loading process. They can't be changed by anything else. This prevents unexpected changes and bugs.

If you use separate variables, other parts of your app could change them. This could lead to bugs that are hard to track down and fix.

Keeping these states inside the data stream makes your code less complicated and safer. It also makes sure the user interface updates smoothly.

Important: keep it DRY! Create your own reusable RxJS Operator

You probably need the pattern we discussed above in multiple places in your app. But you don’t want to write the same code over and over again. Luckily, it's not hard to make your own RxJS operators! We can take the code we used before and make a useful RxJS operator that we can use all over our app.

Let's look at an example: we'll make our own operator called switchMapWithLoading. We'll put it in a separate file named switch-map-with-loading.ts.

// switch-map-with-loading.ts

interface LoadingState<T = unknown> {
  loading: boolean;
  error?: Error | null;
  data?: T;
}

export function switchMapWithLoading<T>(
  observableFunction: (value: any) => Observable<T>
): OperatorFunction<any, LoadingState<T>> {
  return (source: Observable<any>) =>
    source.pipe(
      switchMap((value) =>
        observableFunction(value).pipe(
          map((data) => ({ data, loading: false })),
          catchError((error) => of({ error, loading: false })),
          startWith({ error: null, loading: true })
        )
      ),
      scan((state: LoadingState<T>, change: LoadingState<T>) => ({
        ...state,
        ...change,
      }))
    );
}

You can then import it in your component and use it like so:

@Component({
  selector: 'my-app',
  standalone: true,
  imports: [CommonModule, ReactiveFormsModule],
  template: `
    <input [formControl]="searchControl" />

    <div *ngIf="result$ | async as result">
      <div *ngIf="result.loading">Loading...</div>
      <div *ngIf="result.data as data">{{data}}</div>
      <div *ngIf="result.error as error">{{error.message}}</div>
    </div>
  `,
})
export class App {
  searchControl = new FormControl('');

  result$ = this.searchControl.valueChanges.pipe(
    switchMapWithLoading((value) => this.http.get('/api/search', {params: { q: value })))
  );

  private http = inject(HttpClient);
}

With this, you've made your Angular application code more efficient and maintainable by abstracting the reactive data fetching mechanism into a custom RxJS operator, which you can use across your application. This will not only keep your code DRY (Don't Repeat Yourself) but also make it easier to understand and manage.

Making it even simpler with `*ngxLoadWith`

Now, you might be wondering if there's a simpler way to handle all of this without dealing with complex RxJS operators. Good news! Introducing the *ngxLoadWith directive, which provides a simpler approach to managing loading states in your Angular application.

To get started, you need to install the *ngxLoadWith package. Run the following command:

npm install ngx-load-with

Once installed, you can use the *ngxLoadWith directive in your Angular component like this:

@Component({
  selector: "my-app",
  standalone: true,
  imports: [CommonModule, ReactiveFormsModule, NgxLoadWithModule],
  template: `
    <input [formControl]="searchControl" />

    <div
      *ngxLoadWith="
        getResult as data;
        args: searchControl.value;
        loadingTemplate: loading;
        errorTemplate: error
      "
    >
      {{ data }}
    </div>
    <ng-template #loading>Loading...</ng-template>
    <ng-template #error let-error>{{ error.message }}</ng-template>
  `,
})
export class App {
  searchControl = new FormControl("");

  getResult = (keywords: string) =>
    this.http.get("/api/search", { params: { q: keywords } });

  private http = inject(HttpClient);
}

Let's break it down. We simply define a function called getResult that takes a keywords parameter and returns an HTTP request. We then pass this function to the *ngxLoadWith directive, along with the value of searchControl.value as the args input.

Now whenever the searchControl value changes, the getResult function will be called with the new value. The *ngxLoadWith directive will then subscribe to the result of the function and display the result in the template.

Then we define two templates: loading and error. These templates will be automatically displayed when the getResult function is loading or has an error.

That's it! You can now easily and safely manage loading states in your Angular application without having to deal with complex RxJS operators.

Ready to give it a try? Check out the source code at github.com/rensjaspers/ngx-load-with. If you find *ngxLoadWith helpful, don't forget to give it a star on Github. We would love to hear your feedback and experiences with this directive!

Angular Guide for Beginners: Fetching Data from an API, Handling Errors, and Efficiently Managing Loading State

Rens Jaspers — Thu, 08 Jun 2023 06:55:33 +0000

In this guide, we'll learn how to get data from an API using Angular, show a loading indicator while waiting for the data, and how to display errors nicely.

Using HttpClient in Angular

To fetch data from the web, Angular provides a tool called HttpClient. To use it, you need to add it to your project. The way you add it depends on how your project is set up.

With NgModules

If your project uses NgModules, add HttpClientModule to your AppModule file:

// app.module.ts
import { HttpClientModule } from "@angular/common/http";

@NgModule({
  declarations: [
    // your components here
  ],
  imports: [
    BrowserModule,
    HttpClientModule,
    // other modules here
  ],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

With Standalone Components

For projects using standalone components, add HttpClient in your main file where you start your application:

// main.ts
bootstrapApplication(App, { providers: [provideHttpClient()] });

Injecting HttpClient

After adding HttpClient, you need to include it in your component by adding it to the constructor.

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

@Component(...)
export class MyComponent {
  constructor(private http: HttpClient) {}
}

Note: a good practice is to use HttpClient in services instead of directly in components. This makes your code neater.

Fetching Data from a Web Service

To get data from a web service, use the HttpClient.get() method. When you call this method, you can handle the data received or any errors that occur.

@Component(...)
export class MyComponent implements OnInit {
  data: any;

  constructor(private http: HttpClient) {}

  ngOnInit() {
    this.http.get('https://api.mywebsite.com/data').subscribe((response) => {
      this.data = response;
    });
  }
}

Showing a Loading Indicator

It's a good idea to show a loading spinner or icon while waiting for the data. You can do this by using an isLoading variable that is true when the data is being fetched and false once it's loaded. You use this variable in your template to show or hide the loading icon.

@Component(...)
export class MyComponent implements OnInit {
  data: any;
  isLoading: boolean;

  constructor(private http: HttpClient) {}

  ngOnInit() {
    this.isLoading = true;
    this.http.get('https://api.mywebsite.com/data').subscribe((response) => {
      this.data = response;
      this.isLoading = false;
    }, (error) => {
      this.isLoading = false;
      console.log('Error:', error);
    });
  }
}

Then, use the isLoading property to conditionally display a loading spinner in your component's template:

@if (isLoading) {
  <!-- Display your loading spinner or skeleton here -->
  Loading...
} @else {
  <!-- Display your data here -->
  {{ data }}
}

Handling Errors

If there's a problem fetching the data, you should show an error message. You can add an error variable that stores error information and use it in your template to show an error message when needed:

@Component(...)
export class MyComponent implements OnInit {
  data: any;
  isLoading: boolean;
  error: string;

  constructor(private http: HttpClient) {}

  ngOnInit() {
    this.isLoading = true;
    this.http.get('https://api.mywebsite.com/data').subscribe((response) => {
      this.data = response;
      this.isLoading = false;
    }, (error) => {
      this.isLoading = false;
      this.error = 'An error occurred while fetching data';
      console.log('Error:', error);
    });
  }
}

And in your template:

@if(isLoading {
  Loading...
} @else {
  @if(error) {
    {{ error.message }}
  } @else {
    {{ data }}
  }
}

Having completed these steps, you now possess a basic setup for fetching data from an API in Angular, showing a loading spinner during data fetching, and handling errors.

Improving Data Fetching with the `async` Pipe

Angular has a feature called the async pipe that can make working with data from web services easier. It automatically handles subscribing and unsubscribing to data streams, which helps prevent memory leaks.

This is a pattern for using the async pipe you will see often:

@Component(...)
export class MyComponent {
  data$ = this.http.get('https://api.mywebsite.com/data');
}

@if(data$ | async; as data) {
  {{ data }}
} @ else {
  Loading...
}

Besides preventing memory leaks this approach also makes sure we don’t introduce side effects like setting an isLoading flag and storing the data in the data property of our components.

This is a big deal because effects make your code harder to understand and harder to debug and test: any part of the application can edit the isLoading or data property.

But be careful! Using the async pipe with raw data has major drawbacks such as incorrectly showing a loading icon when the data is actually loaded but is a falsy value (like 0 or null) or not handling errors properly.

A Better Approach: Loading State Object Stream

A better way to handle data loading and errors while using the async pipe is to create a special object that clearly indicates the loading state. This object can have a state property that shows whether the data is loading, loaded, or there was an error.

This is what a loading state object could look like:

interface Loading {
  state: "loading";
}

interface Loaded<T> {
  state: "loaded";
  data: T;
}

interface Errored {
  state: "error";
  error: Error;
}

type LoadingState<T = unknown> = Loading | Loaded | Errored;

In your component, you can use it like this:

@Component()
export class MyComponent {
  data$ = this.http.get('https://api.mywebsite.com/data').pipe(
    map(data => ({ state: "loaded", data })),
    catchError(error => of({ state: "error", error })),
    startWith({state: "loading"})
  );

When the data comes in, it is piped through the map operator to create a Loaded object. If there's an error, it's caught by the catchError operator and turned into an Errored object. The startWith operator is used to emit a Loading object when the stream starts.

In your template, you can use @switch to easily handle all the loading outcomes:

@if (data$ | async; as data) {
  @switch (data.state) {
    @case ("loading") {
      Loading...
    }
    @case ("error") {
      Error: {{ data.error.message }}
    }
    @case ("loaded") {
      {{ data.data }}
    }
  }
}

This method is more clear and avoids the issues of directly using the data stream with the async pipe. It makes your code easier to understand and manage.

If you think the code in the last part is a bit hard, you're not alone. It includes some advanced topics from TypeScript and RxJS. But, you can easily make a function that changes your data stream into a loading state stream.

Here's how you can make any data stream show loading, loaded, or error states:

// to-loading-state-stream.ts
import { Observable, of } from "rxjs";
import { catchError, map, startWith } from "rxjs/operators";
import { LoadingState } from "./loading-state.interface";

export function toLoadingStateStream<T>(
  source$: Observable<T>,
): Observable<LoadingState<T>> {
  return source$.pipe(
    map((data) => ({ state: "loaded", data })),
    catchError((error) => of({ state: "error", error })),
    startWith({ state: "loading" }),
  );
}

You can import this function and use it in any component:

@Component()
export class MyComponent {
  data$ = toLoadingStateStream(this.http.get("https://api.mywebsite.com/data"));
}

If you still find this too tricky, I suggest checking out my library called ngx-load-with. It makes loading data very simple, even if you're not familiar with RxJS. It's as powerful and safe as the method we talked about but much easier to use. Check it out at github.com/rensjaspers/ngx-load-with and give it a star if it helps you!

Why Both Subscribe and *ngIf with Async Pipe Fall Short (and What You Should Use Instead)

Rens Jaspers — Mon, 05 Jun 2023 22:08:45 +0000

Handling data loading from observables in Angular templates can be a tricky business. Two commonly suggested solutions - subscribing to the observable or using *ngIf with the async pipe - each come with their own issues.

The Subscription Problem

First, let's take a look at subscribing. Subscriptions are great, until they aren't. One key issue here is that it's all too easy to forget to unsubscribe, which can lead to memory leaks and a performance hit over time. Additionally, if you're using the OnPush change detection strategy, you need to manually trigger change detection. This is not only tedious, but also counter-intuitive and potentially error-prone.

import { Component, ChangeDetectionStrategy, ChangeDetectorRef } from '@angular/core';
import { Observable } from 'rxjs';

@Component({
  selector: 'my-component',
  template: `<div>{{data}}</div>`,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class MyComponent {
  data: any;

  constructor(private myService: MyService, private cd: ChangeDetectorRef) {}

  ngOnInit() {
    this.myService.getData().subscribe(newData => {
      this.data = newData;
      // Whoops! Did you just forget to unsubscribe?
      // Memory leaks are sneaking in...

      // Uh-oh! Seems like you didn't this.cd.markForCheck() there, buddy!
      // Your view isn't going to update with OnPush change detection.
    });
  }
}

The Async Pipe Problem

Then there's *ngIf with async pipe. On the surface, it appears to be a more elegant solution. There's no need to handle subscribing and unsubscribing, and with the handy else syntax, you can display a loading template with ease. But in reality it isn’t that great.

Most blog posts or tutorials that suggest this method seldom touch upon error handling, which can complicate the template and detract from the elegance. Moreover, dealing with falsy values can also pose a challenge. Falsy values can inadvertently trigger the else block, which could lead to undesired effects.

<div *ngIf="count$ | async as count; else errorOrLoading">
  <p>{{count}} items</p>
  <!-- Whoops, this value is 0 and causing your loading template to show forever! -->
</div>

<ng-template #errorOrLoading>
  <!-- Hmm, doesn't look as elegant when you suddenly have to handle errors, does it? -->
  <div *ngIf="error; else loading">
    <p>Error occurred while loading data.</p>
  </div>
  <ng-template #loading>
    <p>Loading...</p>
  </ng-template>
</ng-template>

So what should we use?

What we really need is a solution that takes the best of both worlds, manages observable subscriptions, automatically detects changes with OnPush, handles loading state gracefully, and is performant, declarative and minimalistic.

Unfortunately I couldn't find an existing solution that met all these criteria, so I created one.

Meet ngx-load-with

⚡️ Live Example

<ul *ngxLoadWith="todos$ as todos; loadingTemplate: loading; errorTemplate: error">
  <li *ngFor="let todo of todos">{{todo.title}}</li>
</ul>
<ng-template #loading>Loading...</ng-template>
<ng-template #error let-error>{{error.message}}</ng-template>

@Component({...})
export class MyComponent {
  todos$ = inject(HttpClient).get<Todo[]>('api/todos');
}

The *ngxLoadWith structural directive automatically manages subscriptions, gracefully handles loading and error states, and provides excellent performance with a minimal amount of code in both your TypeScript and your template.

Furthermore, ngx-load-with goes a step beyond to cater to some common use-cases, making loading handling in Angular a breeze.

You can find ngx-load-with on npm or check out the project on GitHub.

If you find it useful, please give it a star and feel free to contribute. I'd love to hear your feedback or any ideas for improvements. Leave a comment below and let's make data loading in Angular more efficient and elegant!

Uncluttering Angular Templates: Simplifying Asynchronous Data Loading with ngxLoadWith

Rens Jaspers — Sun, 04 Jun 2023 14:03:18 +0000

When it comes to Angular development, creating well-structured, readable templates is a fundamental task. Good templates are about more than just aesthetics; they play a key role in ensuring your code is maintainable, debuggable, and extendable. However, dealing with asynchronous data loading in these templates can often lead to complex and cluttered structures, negatively impacting both the clarity of your code and the efficiency of your development process. This is where the *ngxLoadWith structural directive comes in. It offers a declarative and simple syntax that helps keep your templates clean and tidy, allowing you to focus more on the business logic and less on the mechanics of data loading.

The Traditional Approach

Traditionally, asynchronous data loading and management in Angular is often done using the async pipe and *ngIf directive. Let's look at an example:

<div *ngIf="todos$ | async as todos; else loadingOrError">
  <ul>
    <li *ngFor="let todo of todos">{{todo.title}}</li>
  </ul>
</div>

<ng-template #loadingOrError>
  <ng-container *ngIf="error$ | async as error; else loading">
    <p>Error: {{error.message}}</p>
  </ng-container>

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

This approach certainly works, but as you can see, it quickly adds extra complexity to our template. We're manually handling loading states, catching errors, and our code starts to get nested and harder to read. In a real-world application, these templates can get much more complex, adding to the cognitive load of understanding and maintaining your code.

Simplifying Templates with ngxLoadWith

Now let's see how ngxLoadWith simplifies this process. Here's the equivalent template using ngxLoadWith:

<ul *ngxLoadWith="todos$ as todos; loadingTemplate: loading; errorTemplate: error">
  <li *ngFor="let todo of todos">{{todo.title}}</li>
</ul>
<ng-template #loading>Loading...</ng-template>
<ng-template #error let-error>Error: {{error.message}}</ng-template>

In this example, the ngxLoadWith directive is managing our loading and error states. We no longer need to use the async pipe or *ngIf directive for this purpose. The loadingTemplate input is used to specify a template that should be displayed while our data is loading, and the errorTemplate provides an explicit place for error handling, reducing the complexity of our main template.

Conclusion

By using ngxLoadWith, you can drastically simplify your Angular templates. This makes them easier to understand, easier to maintain, and reduces the risk of mistakes that could lead to bugs. The library's straightforward syntax allows you to express complex asynchronous operations in a more intuitive way, allowing you to keep your focus on the unique aspects of your application.

Further Information and Resources

If you'd like to learn more about ngxLoadWith, you can visit the npm package page here, where you'll find more details and installation instructions.

You can also check out the library's GitHub page here. If you find ngxLoadWith useful, please consider giving the project a star on GitHub to show your support and help others discover this helpful resource.

Forem: Rens Jaspers

Looks like we can finally let our AI assistants use modern Angular techniques without the hassle!

Getting Better LLM Responses Using AI-Friendly Documentation

Gergely Szerovay for This is Angular ・ Mar 19

[Boost]

Getting Better LLM Responses Using AI-Friendly Documentation

Gergely Szerovay for This is Angular ・ Mar 19

How to Easily Notify Users About Task Progress in Angular

The Problem

The Solution

Using Observables

Why lastValueFrom?

Customizing Messages

How to Dockerize an Angular App for Production

Requirements

Using Caddy

Example Caddy Configuration

Example Dockerfile

Example Docker Ignore File

Example Docker Compose File

Example Environment File

Building and Running the Docker Container

Working Example

How To Easily Expand or Collapse All Accordion Items in IonAccordionGroup at Once Without Adding Complexity

Stop Pretending The Error Never Happened! Be Explicit About Loading State

Stop Overloading Your Angular Components: Start Using Host Directives!

How to Include Version, Git Commit, and Build Date in Your Angular Builds

1. Create a File for Version Information

2. Write a Script to Update Version Information

3. Add a Prebuild Script to Your Project

4. Update Your Build Configuration

5. Ignore the Generated Version File

Reactive Loading State Management with RxJS and Angular: Loading Stuff Based on Changes to Other Stuff

Responding to user input

Managing loading and error states with RxJS

These operators look complicated! Why not just use separate isLoading and hasError variables?

Important: keep it DRY! Create your own reusable RxJS Operator

Making it even simpler with *ngxLoadWith

Angular Guide for Beginners: Fetching Data from an API, Handling Errors, and Efficiently Managing Loading State

Using HttpClient in Angular

With NgModules

With Standalone Components

Injecting HttpClient

Fetching Data from a Web Service

Showing a Loading Indicator

Handling Errors

Improving Data Fetching with the async Pipe

A Better Approach: Loading State Object Stream

Why Both Subscribe and *ngIf with Async Pipe Fall Short (and What You Should Use Instead)

The Subscription Problem

The Async Pipe Problem

So what should we use?

Meet ngx-load-with

Uncluttering Angular Templates: Simplifying Asynchronous Data Loading with ngxLoadWith

The Traditional Approach

Simplifying Templates with ngxLoadWith

Conclusion

Further Information and Resources

Why `lastValueFrom`?

Making it even simpler with `*ngxLoadWith`

Improving Data Fetching with the `async` Pipe