DEV Community: Michele Stieven

Recreating LinkedIn’s Crossclimb Game with Angular - Part 3

Michele Stieven — Fri, 14 Nov 2025 01:34:41 +0000

Now that we've taken care of the game's logic with a service, it's time to end our little project with a couple more components!

The `Hint` component

But first, let's create a simple component to display the current hint to the user: create the file /components/hint.ts.

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

@Component({
  selector: 'app-hint',
  template: `
    <ng-content />
  `,
  styles: `
    :host {
      background: rgba(0,0,0,.1);
      color: grey;
      display: block;
      position: absolute;
      bottom: 0;
      left: 0;
      right: 0;
      height: 2rem;
      padding: 2em;
      text-align: center;
    }
  `
})
export class Hint {}

This component does nothing more than styling: it'll place our hint on the bottom of the page via Content Projection, like this:

<app-hint>This is a hint</app-hint>

The Container

Time for our final component: the GameContainer! This one will be in charge of displaying all the words, binding the states from our service, and listening to events. Essentially, it is the main orchestrator of our game. Create the file components/game-container.ts.

@Component({
  selector: 'app-game-container',
  template: `
    @if (gameService.game(); as game) {
      <div class="game-container">

      </div>
    }

    <app-hint>{{ gameService.currentHint() }}</app-hint>
  `,
  imports: [Hint],
  styles: `

  `
})
export class GameContainer {

  gameService = inject(GameService);

  ngOnInit() {
    this.gameService.init();
  }
}

For now, all it does is to display the current hint to the user, and it also sets up a container <div>. It is also responsible for initializing the game.

Just put it in your main component, like this:

@Component({
  selector: 'app-root',
  template: `
    <app-game-container />
  `,
  imports: [GameContainer],
})
export class App {}

Now go back to the GameContainer component: let's add some template.

From now on, we'll be working inside the <div class="game-container"> element.

Showing the edge words

First, we'll show the top word.

<app-word
  [letters]="game.currentEdgeWords[0].split('')"
  [isReadonly]="gameService.gameStatus() !== 'sorted' || gameService.gameStatus() === 'solved'"
  [isFinal]="true"
  [isLocked]="gameService.gameStatus() === 'error' || gameService.gameStatus() === 'unsorted'"
  (lettersChange)="onLettersChange(0, $event)"
  (lastKeydown)="focusWord(game.words.length + 1)"
/>

This is what we're doing:

We're binding the current top word (transforming it from an array to a single string).
We're binding isReadonly, isFinal and isLocked with the appropriate expressions.

Don't forget to import the Word component!

We're also listening to two events: lettersChange and lastKeydown. The first one is responsible for updating the state, the second one is needed to jump to the bottom word when the user has entered the last letter (for convenience). So, we need to create two metods.

The first one is really simple, all it has to do is to call the methods we've already created in our service:

onLettersChange(wordIndex: number, letters: string[]) {
  if (wordIndex === 0) {
    this.gameService.replaceTop(letters.join(''));
  } else if (wordIndex === this.gameService.game()!.words.length + 1) {
    this.gameService.replaceBottom(letters.join(''));
  } else {
    this.gameService.replaceWord(wordIndex - 1, letters.join(''));
  }
}

The wordIndex we get goes from 0 to 6, so we're calling the appropriate method based on that.

Then, we need the ability to focus on some element in our view. To do that, we need to use viewChildren:

  wordComponents = viewChildren(Word);

Import it from @angular/core.

This is a Signal which contains all the Word components on this page. Now we can create the focusWord() handler:

focusWord(i: number) {
  this.wordComponents()[i]?.focus(0);
}

Perfect! Now for the bottom word, things are mostly the same, except that we're binding to the second edge word, and we don't need to listen to the lastKeydown event:

<app-word
  [letters]="game.currentEdgeWords[1].split('')"
  [isReadonly]="gameService.gameStatus() !== 'sorted' || gameService.gameStatus() === 'solved'"
  [isFinal]="true"
  [isLocked]="gameService.gameStatus() === 'error' || gameService.gameStatus() === 'unsorted'"
  (lettersChange)="onLettersChange(game.words.length + 1, $event)"
/>

You should now see both words, in a locked state:

The middle words

It's time to display the middle words! In order to have the drag & drop functionality, we need the Angular CDK, so install it like this:

npm install @angular/cdk

Now, between the two words, put this template:

<div cdkDropList class="sortable-list" (cdkDropListDropped)="drop($event)">
  @for (word of game.words; track i; let i = $index) {
    <div cdkDrag class="word-container">

    </div>
  }
</div>

Here we're displaying all of our middle words. But also:

We're using the cdkDropList directive to tell Angular that this is where we'll put our draggable elements.
We're using the cdkDrag directive to the elements that we want to drag.
We're listening to the cdkDropListDropped event which tells us when an element has been dropped.

So, first of all, import the directives:

import { CdkDropList, CdkDrag } from '@angular/cdk'; 

// ...
  imports: [Word, CdkDropList, CdkDrag, Hint, Icon],

Then, we need to implement the drop() handler. This is how it looks like:

  drop(event: CdkDragDrop<string[]>) {
    const words = [...this.gameService.game()!.words];
    moveItemInArray(words, event.previousIndex, event.currentIndex);
    this.gameService.game.update(game => ({ ...game!, words }));
  }

Import CdkDragDrop and moveItemInArray from @angular/cdk and place them in the imports array.

Here we're cloning the original array of words (we don't want to mutate it) and sorting it with the helper moveItemInArray from the CDK. Then, we're updating the state with the ordered words.

Believe it or not, the class is done! All we need to do now is to add some more elements and some styles.

Place your cursor inside the <div cdkDrag class="word-container"> element and add the following:

<app-word
  [letters]="word.current.split('')"
  [isReadonly]="gameService.gameStatus() !== 'error'"
  (focusedChange)="gameService.focused.set($event !== null ? i : null)"
  (lettersChange)="onLettersChange(i + 1, $event)"
  (lastKeydown)="$last ? '' : focusWord(i + 2)"
/>

This is more or less the same thing we did for the edge words, but:

The bindings and conditions are different.
We're using i + 1 on the lettersChange event because we need to account for the top word.
We're using i + 2 on lastKeydown for the same reason.

Also, we're listening to focusedChange to know when the user has focused this word. For our state, we don't actually need to know the index of the character (the $event), just the index of the word.

One more touch: we don't want the user to drag the words normally, we want to make sure they drag an icon, so let's add two icons, one per side! Place this immediately after the previous template.

<div cdkDragHandle [style.display]="gameService.gameStatus() !== 'sorted' && gameService.gameStatus() !== 'solved' ? 'block' : 'none'">
  <app-icon icon="bars" />
</div>

<div cdkDragHandle [style.display]="gameService.gameStatus() !== 'sorted' && gameService.gameStatus() !== 'solved' ? 'block' : 'none'">
  <app-icon icon="bars" />
</div>

Import CdkDragHandle from @angular/cdk and place it in the imports array.

All that's left to do is some styling! Put these styles in your component:

These are some simple styles to make it functional, feel free to tweak them!

.game-container {
  max-width: 400px;
  padding: 2em;
  margin: 0 auto;
}
.word-container {
  position: relative;
}
[cdkDragHandle] {
  position: absolute;
  top: 50%;
  display: block;
  cursor: pointer;
}
[cdkDragHandle]:nth-of-type(1) {
  left: 0;
  transform: translate(-50%, -50%);
}
[cdkDragHandle]:nth-of-type(2) {
  right: 0;
  transform: translate(50%, -50%);
}
.sortable-list {
  border: 2px solid rgba(0,0,0,.05);
  border-top: none;
  border-bottom: none;
 }
app-word {
  display: block;
  padding: 10px 30px;
}
.cdk-drag-placeholder {
  opacity: 0;
}
.cdk-drag {
  overflow: visible;
}
.cdk-drag-animating {
  transition: transform 250ms cubic-bezier(0, 0, 0.2, 1);
}
.sortable-list.cdk-drop-list-dragging > *:not(.cdk-drag-placeholder) {
  transition: transform 250ms cubic-bezier(0, 0, 0.2, 1);
}

All the classes with the cdk- prefix are automatically applied by the CDK, we just need to style them. The CDK actually clones the element when it moves, so we're just making the previous one invisible while we drag.

And we're done! Our game is now complete! [Link to the final code]

Where to go from here

The game is fully working, but the original one has a couple more features. Feel free to implement them as an exercise! For example:

Request the GameInfo object from an actual server.
Start a timer as soon as the game is loaded, and stop it when the puzzle is solved. You could do it easily with RxJS.
Display a button which reveals the focused word.
Display a button which reveals only one missing letter of the focused word.
Finally, to make it more challenging, allow the user to click on these buttons only every 10 seconds or so. Again, this should be pretty easy with RxJS!

I hope this has been a fun little project to build, as it was for me! Hope you liked it!

Recreating LinkedIn’s Crossclimb Game with Angular - Part 2

Michele Stieven — Thu, 13 Nov 2025 00:29:30 +0000

In the previous article we wrote the main component for our app: the Word component. Now, it's time to implement some game logic!

The models

Create a models/game.ts file which will store our models.

First, we have a GameInfo interface: this is what could be eventually be store on a server (we won't have one, but we'll pretend that we do). It stores the 5 middle words, each with its own hint, the 2 edge words (top and bottom) and a common hint.

/** What comes from the server */
export interface GameInfo {
  words: Array<{ correct: string; hint: string }>;
  edgeWords: [string, string];
  edgeHint: string;
};

Then, we need a similar interface, which I called Game, which stores some additional strings: the user's current values.

/** What we store in our component */
export interface Game {
  words: Array<{ correct: string; hint: string; current: string }>;
  edgeWords: [string, string];
  currentEdgeWords: [string, string];
  edgeHint: string;
};

This is what I imagined for the purpose of this demo, but it's not the only way to store the data.

As I said, we won't use an actual server, so let's export some fake data!

export const mock: GameInfo = {
  words: [
    { correct: 'CARE', hint: 'Compassionate attention given to someone' },
    { correct: 'CORE', hint: 'Discarded part of an apple' },
    { correct: 'CORK', hint: 'Stopper in a champagne bottle' },
    { correct: 'FORK', hint: 'Eating utensil with tines' },
    { correct: 'FORT', hint: '____nite (popular online game)' }
  ],
  edgeWords: ['BARE', 'FOOT'],
  edgeHint: 'Compound word for "having no shoes or socks on"'
};

Remember that the 2 edge words share a common hint!

So, to recap, the user will have to guess these words in this exact order:

BARE
CARE
CORE
CORK
FORK
FORT
FOOT

The service

We'll store pretty much all of our data in a service, so create a services/game.service.ts file.

This is where you may use a State Management solution, like NgRx. We'll keep it simple and use Angular Signals!

@Injectable({ providedIn: 'root' })
export class GameService {

}

This service will hold 2 states: game and focused.

@Injectable({ providedIn: 'root' })
export class GameService {

  game = signal<Game | null>(null);
  focused = signal<number | null>(null);
}

game will store the current Game object, and focused will store the index of the focused word (in our case, since we have 7 words, 0 to 6). We'll take advantage of this state to show the appropriate hint to the user.

Let's implement a method to initialize the game object. In a real scenario, you would perform an HTTP request, but we'll use our mock data!

  init() {
    const emptyString = Array(mock.edgeWords[0].length).fill(' ').join('');
    this.game.set({
      ...mock,
      words: mock.words.map(word => ({ ...word, current: emptyString })).sort(() => Math.random() - 0.5),
      currentEdgeWords: [emptyString, emptyString]
    });
  }

Here we're simply populating the current words with empty strings. So, if our words have 4 letters, the current words will be 4 empty characters each.

We're also randomizing the order of our words (see that Math.random()?), so that the user will be forced to sort them correctly!

The derived states

All of the info we need can be derived from our game and focused states, so let's create some derived states using computed.

First, let's calculate the word length, just for convenience.

  wordLength = computed(() => this.game()?.edgeWords[0].length || 0);

It doesn't matter which word you choose, they have the same length.

We also need to know the current game status. The game could be in 5 different states:

idle (game not loaded yet)
error (not solved at all)
unsorted (middle words are solved, but not sorted)
sorted (middle words have been sorted)
solved (the edge words have been solved)

In order to calculate it, we need a helper method: let's call it differByOne(), and its job will be to tell us if 2 strings differ by exactly one character.

  private differByOne(str1: string, str2: string) {
    if (str1.length !== str2.length) return false;

    let diffCount = 0;

    for (let i = 0; i < str1.length; i++) {
      if (str1[i] !== str2[i]) diffCount++;
      if (diffCount > 1) return false;
    }

    return diffCount === 1;
  }

Now we can write our gameStatus derived state!

  gameStatus = computed(() => {

  });

First, we check if there is a game at all. If we have no game, we return idle.

    const game = this.game();
    if (!game) return 'idle';

Then, we check if the middle words have been solved, and if not, we return error.

    const isHalfSolved = game.words.every(word => word.correct === word.current);

    if (!isHalfSolved) return 'error';

Then, we check if the middle words have been sorted correctly, and if not, we return unsorted.

    const isSorted =
      isHalfSolved
      && game.words.every((word, i) => i === game.words.length - 1 || this.differByOne(word.current, game.words[i + 1].current))

    if (!isSorted) return 'unsorted';

The words could be arranged in reverse order, it doesn't matter.

Finally, we check if the edge words are correct (and we check that the top one and the first middle word differ by one character, to make sure they're written in the correct order).

    const isSolved =
      isHalfSolved
      && isSorted
      && game.currentEdgeWords.every((word, i) => game.edgeWords.includes(word))
      && this.differByOne(game.currentEdgeWords[0], game.words[0].current);

    if (!isSolved) return 'sorted';
    return 'solved';

This derived state is done!

We just need another one: we'll call it currentHint, and it will store the hint to show to the user based on the gameStatus and the focused index.

currentHint = computed(() => {
    if (this.gameStatus() === 'solved') return 'Solved!';
    if (this.gameStatus() === 'sorted') return 'Top + bottom: ' + this.game()!.edgeHint;
    if (this.gameStatus() === 'unsorted') return 'Sort the rows!';
    if (this.focused() === null) return undefined;

    return this.game()?.words.at(this.focused()!)!.hint;
  });

This should be self-explanatory.

We're almost done with our service! We just need 3 additional methods to mutate our game state.

First, create a replaceWord method to change the value of one of the middle words:

  replaceWord(index: number, text: string) {
    this.game.update(game => (game && {
      ...game,
      words: game.words.map((word, i) => {
        if (index !== i) return word;
        return { ...word, current: text }
      })
    }))
  }

The index will go from 0 to 4 since we're only dealing with the 5 middle words.

Then, two similar methods to replace the edge words:

  replaceTop(word: string) {
    this.game.update(game => (game && {
      ...game,
      currentEdgeWords: [word, game.currentEdgeWords[1]] 
    }));
  }

  replaceBottom(word: string) {
    this.game.update(game => (game && {
      ...game,
      currentEdgeWords: [game.currentEdgeWords[0], word]
    }));
  }

And we're done! In the next article we'll take advantage of our Word component and our newly created GameService to display the actual game, with the help of the Angular CDK.

At the end, we'll have something like this:

Recreating LinkedIn’s Crossclimb Game with Angular - Part 1

Michele Stieven — Wed, 12 Nov 2025 01:45:38 +0000

In this short series, we’ll use Angular to recreate the popular LinkedIn game Crossclimb, a fun word puzzle that’s perfect for showing off the power of Signals in modern Angular.

This project is not only a great coding exercise, but also an enjoyable way to explore reactive state management using Signals.
So, fire up your terminal, create a new Angular app, and let’s build together! 🚀

How the game works

If you’ve never played Crossclimb before, here’s a quick rundown:

The goal is to guess seven words using a set of hints to form a connected word chain. Each consecutive pair of words differs by exactly one character, for example, “code” → “cove” → “love”.

You’ll start by completing and correctly arranging the five middle words. Once that’s done, the first and last words unlock. They come with a hint to help you guess them, and they’re connected by a logical relationship.

When all seven words are correctly guessed, you’ve solved the puzzle! 🎉

The `Word` component

Feel free to use your favorite font for the project: for my demo, I've used Roboto, so I wrote this in my global styles:

@import url('https://fonts.googleapis.com/css2?family=Roboto:ital,wght@0,100..900;1,100..900&display=swap');

body, * {
  font-family: "Roboto", sans-serif;
  font-optical-sizing: auto;
  font-style: normal;
  font-variation-settings: "wdth" 100;
}

First, create the main component, called Word, in a file (eg. /components/word.ts):

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

@Component({
  selector: 'app-word',
  imports: [],
  template: `
  `,
  styles: ``
})
export class Word {

}

On the surface, this component is pretty simple: it's a box containing multiple <input> elements in a row (one for each letter).

However, there are some behaviors we need to implement, for example:

Each <input> must contain a single letter (or none)
If the user writes a second letter, it must replace the previous one
After the user enters a letter, we must automatically focus the next <input>, so that the user can type the whole word easily
We must display a bottom border where if there is no letter, to indicate that it's missing

This is an example of how we'll use this component:

<app-word
  [letters]="[' ', ' ', ' ', ' ']"
  [isReadonly]="false"
  [isFinal]="false"
  [isLocked]="false"
  (lettersChange)="..."
  (focusedChange)="..."
  (lastKeydown)="..."
/>

So, we need 4 inputs:

letters will be an array of characters (empty character for a missing letter)
isReadonly will stop the user from changing the letters (we'll set it to true once the user is done with the middle words)
isFinal will be used for the first and last words (just to style them with a different color)
isLocked will display a lock icon on top of the word (just for the first and last words, initially)

And two outputs:

lettersChange will give us back a new array of letters when the user changes one of them
focusedChange will tell us the index of the character which is currently focused by the user, we need this in order to display the correct hint. We don't actually need the index (we just need to know which word it is) but it may come in handy.
lastKeydown will be emitted when the user has typed something on the last <input>, we'll use this to focus on the next word automatically.

Let's write them, starting with the inputs.

export class Word {

  isReadonly = input(false);
  isFinal = input(false);
  isLocked = input(false);
  letters = model.required<string[]>();
  focused = model<number | null>(null);
}

letters and focused are actually models, a particular type of input which can also be overridden by the component itself. Also, each model automatically creates an output with the same name but with the Change suffix: this means we get lettersChange and focusedChange for free! They'll emit the new value once the model value changes.

Then, create the missing output:

  lastKeydown = output();

The template

It's time to display something! This will be the template for our component:

<div class="container" [class.final]="isFinal()">
  @for (_ of [].constructor(letters().length); let i = $index; track i) {
    @let letter = letters()[i];
    <input
      #input
      type="text"
      [class.with-border]="letter === ' ' && !isReadonly() && !isLocked()"
      [class.highlighted]="focused() === i && !isReadonly() && !isLocked()"
      [value]="letter === ' ' ? '' : letter"
      [readonly]="isReadonly()"
      (keydown)="onKeydown(i, $event)"
      (focus)="focused.set(i)"
      (blur)="focused.set(null)"
    >
  }
  @if (isLocked()) {
    <div class="overlay">
      <!--<app-icon icon="lock" />-->
    </div>
  }
</div>

Here's what's going on...

The whole template is wrapped inside a .container element, with an optional class final which will simply change its background color.
We're creating an empty array with a trick ([].constructor(letters().length)) to be able to use @for to display the correct number of <input>s.
We're extracting each letter inside a template variable (@let letter).
We're using a reference variable #input to be able to grab the elements later.
We're applying some dynamic classes on the elements, just for styling.
We're binding properties and listening to events to change our states.
We're adding an overlay to display a lock icon on top of the element while the component is still locked (initially, the first and last word).

There are a few things missing: the keydown event handler, an <app-icon> component, and some styling.

First, let's create an empty handler just to make it work:

  onKeydown(index: number, e: KeyboardEvent) {}

Then, apply some styling to our component. Feel free to use these styles:

  .container {
    position: relative;
    display: flex;
    justify-content: space-evenly;
    background: lightgrey;
    border-bottom: 2px solid grey;
    border-radius: 4px;
    padding: 10px;
  }
  input {
    border: none;
    background: transparent;
    width: 1.5em;
    text-align: center;
    outline: none;
    padding: 0;
    font-weight: bold;
  }
  .with-border {
    border-bottom: 2px solid grey;
  }
  .highlighted {
    border-bottom: 2px solid black;
  }
  .final {
    background: #FFCBA4;
  }
  .overlay {
    position: absolute;
    inset: 0;
    background: transparent;
    align-items: center;
    justify-content: center;
    display: flex;
  }

Feel free to test this component! Just place it in your app:

@Component({
  selector: 'app-root',
  template: `
    <app-word [letters]="[' ', ' ', ' ', ' ']" />
  `,
  imports: [Word]
})
export class App {
}

And you should see something like this:

We just need to apply the correct logic when the user enters a letter: let's do it!

Handling the `keydown` event

We'll need the ability to focus on a specific <input>, and in order to do that we must grab a reference to them!

We've already applied an #input reference variable on our template, so we're able to grab all our <input> elements with the help of viewChildren:

import { ..., viewChildren } from "@angular/core";

// ...

  // Inside the component's class
  inputs = viewChildren<ElementRef<HTMLInputElement>>('input');

This will give us a Signal which contains an array of ElementRefs, with all of our native elements inside.

Create a focus method that you'll use to focus on the correct element:

  focus(index: number) {
    this.inputs()[index]?.nativeElement.focus();
  }

Now, it's time to implement the onKeydown() method! So position your cursor inside of it and write the following code... Feel free to test each step on your own!

First, if the word is readonly, we must do nothing and stop the event, so that nothing is written inside our element:

  if (this.isReadonly()) {
    e.preventDefault();
    return;
  }

If the user takes advantage of the tab key to navigate the <input>s, allow it (don't prevent the event), but do nothing on the element.

  if(e.key === 'Tab') {
    return;
  }

Then, the user could delete a character by using backspace or delete. We'll also add a simple check, so that if backspace is used on an empty character, we'll focus the previous <input>, to make it easier for the user.

  if (e.key === 'Backspace' || e.key === 'Delete') {
    if (e.key === 'Backspace' && this.letters()[index] === ' ') {
      this.focus(index - 1);
    }
    this.letters.update(letters => letters.map((l, i) => index !== i ? l : ' '));
  }

At this point, stop the event so that nothing is written inside the input. We'll add the character ourself in our state, and Angular will automatically replace in on the DOM thanks to our [value] binding!

  e.preventDefault();

Finally, we need to mutate our state with the new letter:

  if (isLetter && letter !== previousLetter) {
    this.letters.update(letters => letters.map((l, i) => index !== i ? l : letter));
    if (index === this.letters().length - 1) {
      this.lastKeydown.emit();
    } else {
      this.focus(index + 1);
    }
  }

Notice that we're also focusing on the next <input>, and if there is none, we're just emitting the lastKeydown event. We'll use it later in another component!

Our main component is done! Feel free to test it out!

Here's the entire onKeydown() method:

  onKeydown(index: number, e: KeyboardEvent) {
    if (this.isReadonly()) {
      e.preventDefault();
      return;
    }
    if(e.key === 'Tab') {
      return;
    }
    if (e.key === 'Backspace' || e.key === 'Delete') {
      if (e.key === 'Backspace' && this.letters()[index] === ' ') {
        this.focus(index - 1);
      }
      this.letters.update(letters => letters.map((l, i) => index !== i ? l : ' '));
    }

    e.preventDefault();

    const isLetter = /^[a-zA-Z]$/.test(e.key);
    const letter = e.key.toUpperCase();
    const previousLetter = this.letters().at(index)!.toUpperCase();

    if (isLetter && letter !== previousLetter) {
      this.letters.update(letters => letters.map((l, i) => index !== i ? l : letter));
      if (index === this.letters().length - 1) {
        this.lastKeydown.emit();
      } else {
        this.focus(index + 1);
      }
    }
  }

And this is what you should see:

The `Icon` component

We need an Icon component to display a couple of icons: one with a lock, and one with some bars (for the drag & drop functionality which we'll implement later). For the purpose of this exercise, you can just use the SVGs from Font Awesome, like this:

import { Component, input } from "@angular/core";

@Component({
  selector: 'app-icon',
  template: `
    @if (icon() === 'lock') {
      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 384 512"><!--!Font Awesome Free v7.1.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free Copyright 2025 Fonticons, Inc.--><path d="M128 96l0 64 128 0 0-64c0-35.3-28.7-64-64-64s-64 28.7-64 64zM64 160l0-64C64 25.3 121.3-32 192-32S320 25.3 320 96l0 64c35.3 0 64 28.7 64 64l0 224c0 35.3-28.7 64-64 64L64 512c-35.3 0-64-28.7-64-64L0 224c0-35.3 28.7-64 64-64z"/></svg>

    } @else {
      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 448 512"><!--!Font Awesome Free v7.1.0 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free Copyright 2025 Fonticons, Inc.--><path d="M0 96C0 78.3 14.3 64 32 64l384 0c17.7 0 32 14.3 32 32s-14.3 32-32 32L32 128C14.3 128 0 113.7 0 96zM0 256c0-17.7 14.3-32 32-32l384 0c17.7 0 32 14.3 32 32s-14.3 32-32 32L32 288c-17.7 0-32-14.3-32-32zM448 416c0 17.7-14.3 32-32 32L32 448c-17.7 0-32-14.3-32-32s14.3-32 32-32l384 0c17.7 0 32 14.3 32 32z"/></svg>
    }
  `,
  styles: `
    svg {
      height: 1rem;
    }
  `
})
export class Icon {

  icon = input.required<'lock' | 'bars'>();
}

Now, just remove the comment from the Word component template, and add Icon to the imports array:

import { Icon } from "./icon";

@Component({
  selector: 'app-word',
  imports: [Icon], // Add this
  template: `

    <!-- Change this: --->
    <!--<app-icon icon="lock" />-->

    <!-- To this: -->
    <app-icon icon="lock" />
  `,
  ...
})

Try it out! Set isLocked to true and you should see something like this:

<app-word [letters]="[' ', ' ', ' ', ' ']" [isLocked]="true" />

Next steps

In the next articles of this series we'll implement the game logic and a drag & drop list using the Angular CDK. Stay tuned!

Angular Authentication with Cookies in 10 minutes

Michele Stieven — Tue, 04 Nov 2025 03:27:18 +0000

Hi folks! Long time no see!
In this short article, I’ll show you just how simple Cookie Authentication can be in Angular, all in five easy steps!

Personally, I find Cookies to be the ideal choice for most applications. They keep the front-end clean and transparent, while leaving the heavy lifting where it belongs: on the server. That said, this isn’t always the best fit for every scenario. Depending on your needs, you might opt for a hybrid setup, a fully token-based approach (like JWTs), or even OAuth 2.0 with OIDC.

If you want to dive deeper, my short e-book covers everything in detail, complete with Angular examples and mock back-ends for hands-on learning. Feel free to check it out!

AccademiaDev: text-based web development courses!

I believe in providing concise, valuable content without the unnecessary length and filler found in traditional books. Drawing from my years as a consultant and trainer, these resources—designed as interactive, online courses—deliver practical insights through text, code snippets, and quizzes, providing an efficient and engaging learning experience.

Before we begin: the server

I've already created a back-end for educational purposes: you'll find it here.

Download the code (or clone the repo)
Open a terminal
Position yourself inside the project with cd
Install the dependencies with npm install
Run the back-end with npm run dev

If all goes well, by visiting http://localhost:3000 on your browser you should see a message. We're good to go!

The server assumes that your front-end will be on localhost:4200, if it's not the case, create an .env file inside the project and set FRONTEND_URL to the full URL of your front-end. This is for CORS purposes.

Step 1: Getting the CSRF Token

A CSRF Token is a special value generated by the server (as a cookie) and stored on the browser which prevents any kind of CSRF vulnerability (eg. cross-origin same-site requests, login CSRF). It must be sent to the server (as a header) with each mutating request: this will be done automatically by Angular.

As soon as the app starts, we must get the CSRF token from the server. Let's use provideAppInitializer for that.

import { PLATFORM_ID } from '@angular/core';
import { isPlatformServer } from '@angular/common'; 
// ...

bootstrapApplication(App, {
  providers: [
    provideAppInitializer(() => {
      const http = inject(HttpClient);
      const platformId = inject(PLATFORM_ID);

        // Skip on the server (when using SSR), otherwise the request will be
        // cached and not repeated on the client-side, thus not grabbing the token.
        if (isPlatformServer(platformId)) return Promise.resolve();
        return firstValueFrom(http.get(`${env.apiUrl}/csrf-token`)
    }),
    provideHttpClient(),
  ],
});

Angular automatically saves this token and sends it with every request: as long as the Cookie name is XSRF-TOKEN, Angular will save it, and it will send it as a Header with the name X-XSRF-TOKEN for every request.

Should your server use different names, you can override them:

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(
      withXsrfConfiguration({
        cookieName: 'YOUR-COOKIE-NAME',
        headerName: 'YOUR-HEADER-NAME',
      }),
    ),
  ]
};

Warning: Angular doesn't send this to absolute URLs. For this reason, when working on localhost, I suggest using an URL like this: //localhost:3000. This bypasses Angular's rules, likely due to a bug, but it's useful for development.

Step 2: Sending the Cookie in `localhost`

The beautiful thing about cookies is that they are automatically sent to the server, but only to the server which created them, and only if it's on the same domain. However, during development, our server will be on a different domain (due to having a different port). For this, let's just create a simple interceptor to send them manually:

export const apiInterceptor: HttpInterceptorFn = (
  req: HttpRequest<any>,
  next: HttpHandlerFn
) => {
  // Include the `apiUrl` in your environment, like `//localhost:3000`
  if (req.url.includes(environment.apiUrl)) {
    req = req.clone({ withCredentials: true });
  }
  return next(req);
}

And provide it:

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(
      withInterceptors([apiInterceptor])
    ),
    // ...
  ]
};

Step 3: Creating a service

Create a service to communicate with the server and store the user's data.

// For the sake of the exercise
type User = any;

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

  http = inject(HttpClient);
  router = inject(Router);

  user = signal<User | null>(null);
}

We need fetchUser method to fetch the user's data:

  /**
   * Gets the User's info from server and populates the state.
   * This is _the_ way to check if the user is still logged in.
   * If we already have it, skip the call.
   */
  fetchUser(forceReload = false): Observable<User> {
    const user = this.user();

    if (!!user && !forceReload) return of(user);

    return this.http.get<any>(`${env.apiUrl}/me`, {}).pipe(
      tap(u => this.user.set(u))
    );
  }

Then we need register and a login methods:

  register(credentials: {
    email: string,
    password: string,
    name: string,
    surname: string
  }) {
    return this.http.post<boolean>(`${env.apiUrl}/register`, credentials);
  }

  login(email: string, password: string) {
    return this.http.post<any>(`${env.apiUrl}/login`, { email, password }).pipe(
      switchMap(() => this.fetchUser()),
    );
  }

Finally, a logout method:

  logout() {
    this.http.get<any>(`${env.apiUrl}/logout`).subscribe(() => {
      this.user.set(null);
      this.router.navigateByUrl('/login');
    });
  }

Believe it or not, we're almost done!

Step 4: Detect an expired cookie

As soon as we get a 401 request, it means that we're no longer authenticated and we should be redirected to the login page. Let's create another interceptor. This is just an example, feel free to tweak it!

export const authInterceptor: HttpInterceptorFn = (
  req: HttpRequest<any>,
  next: HttpHandlerFn
) => {
  const authService = inject(AuthService);

  return next(req).pipe(
    tap({
      error: error => {
        if (error instanceof HttpErrorResponse && error.status === 401) {
          // Clears the cookies and redirects to login
          authService.logout();
        }
      }
    })
  );
}

And provide it:

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(
      withInterceptors([apiInterceptor, authInterceptor])
    ),
    // ...
  ]
};

Step 5: Guard your pages!

Let's create a guard to check if the user is authenticated, and if not, redirect to the login page:

export const authGuard = () => {
  const authService = inject(AuthService);
  const router = inject(Router);

  return authService.fetchUser().pipe(
    map(() => true),
    catchError(() => {
      router.navigateByUrl('/login')
      return [false];
    });
  )
}

And apply it to the pages you want to protect, just make sure not to use it on the login and register pages!

export const routes: Routes = [
  {
    path: '',
    pathMatch: 'full',
    loadChildren: () => import('./pages/home/home.routes'),
    canMatch: [authGuard]
  },
  // ...
]

Use it!

We're done! Just create some pages to accomodate a login and a register form, and show the user's info!

You must register like this:

this.authService.register(credentials).subscribe(() => {
  this.router.navigateByUrl('/login');
})

You login like this:

this.authService.login(email, password).subscribe(() => {
  this.router.navigateByUrl('/');
})

Bonus: SSR Quirks

If you don't use SSR (server-side rendering), you can stop here. But if you do, there are some quirks to be aware of.

We already made sure to skip the CSRF Token call on the server, that is because if we did make that request, Angular would cache it and wouldn't repeat it on the client: we don't want that.

There's one more thing we must take care of with SSR: forwarding the Cookies.

In a normal app with client-side rendering, all API requests start from the user's browser where the cookies are stored: as a result, they're always sent automatically by the browser.

With SSR though, requests could start from the server, without the user's cookies. This means that each request which requires authentication (eg. /me to get the user profile) will fail on the server. As a result, the server will render the page as if you were not authenticated (eg. showing login buttons, redirecting to the login page if there's an auth guard…), then the client-side app will take over and modify the HTML: that's a terrible user experience.

Angular does not forward the cookies for us. In order to fix this, we must grab the user's cookies from the initial NodeJS Express Request and attach them to every request manually.

First, you need to provide the Express Request object to Angular (and while we're at it, let's pass the Response, too). In order to do so, create some InjectionTokens and provide them when the app is rendered.

Put these in a file, let's call it express-tokens.ts:

import { InjectionToken } from "@angular/core";
import { Request, Response } from "express";

export const REQUEST = new InjectionToken<Request>('Express REQUEST');
export const RESPONSE = new InjectionToken<Response>('Express RESPONSE');

Provide them in server.ts:

    commonEngine
      .render({
        bootstrap,
        documentFilePath: indexHtml,
        url: `${protocol}://${headers.host}${originalUrl}`,
        publicPath: browserDistFolder,
        providers: [
          { provide: APP_BASE_HREF, useValue: baseUrl },
          // Add these lines
          { provide: REQUEST, useValue: req },
          { provide: RESPONSE, useValue: res }
        ],
      })
      .then((html) => res.send(html))
      .catch((err) => next(err));

Then, use this interceptor to retrieve the cookies from the Request object and add them as headers:

import { isPlatformServer } from '@angular/common';
import { HttpHandlerFn, HttpHeaders, HttpRequest } from '@angular/common/http';
import { PLATFORM_ID, inject } from '@angular/core';
import { REQUEST } from '../../express-tokens';

export function cookieInterceptor(
  req: HttpRequest<unknown>,
  next: HttpHandlerFn
) {
  const location = inject(PLATFORM_ID);
  const serverRequest = inject(REQUEST, { optional: true });

  if (isPlatformServer(location)) {
    let headers = new HttpHeaders();
    const cookies = serverRequest?.headers.cookie;
    headers = headers.set('cookie', cookies ?? '');

    const cookiedRequest = req.clone({
      headers,
    });

    return next(cookiedRequest);
  }
  return next(req);
}

You'll get an error though, something among the lines of "Refused to set unsafe header 'cookie'": that's because using "cookie" as a header name is forbidden by the spec. In order for this to work, we have to disable this error with a little hack inside server.ts:

// @ts-ignore
import * as xhr2 from 'xhr2';

// HACK - enables setting cookie header
xhr2.prototype._restrictedHeaders.cookie = false;

Done!

If you're providing the HttpClient with the withFetch() configuration, this unfortunately won't work. Follow this open issue for more info.

Angular LAB: Preserving Component State Across Route Transitions

Michele Stieven — Tue, 21 Jan 2025 02:15:57 +0000

Let’s dive into a fun new exercise!

Imagine you have an application with two routes:

One displays a list of users.
The other shows details for a specific user.

You can navigate between these routes by clicking links, and you can also switch between user details using "Previous" and "Next" buttons.

Here’s an example of what it might look like:

The First Challenge

When navigating back to a route you've already visited, the application fetches the data from the server again.

While this can be addressed in several ways—such as implementing a cache or using a global store to maintain state across route transitions—there’s another, more nuanced issue.

The Second Challenge: Losing DOM State

When navigating away from a route, you lose all DOM state. This is particularly problematic with forms. When you return to the form, any entered data, validation states, and UI modifications are lost:

Although proper state management could solve this, it’s not straightforward. You’d need to:

Save the component state.
Reapply all DOM modifications to restore the previous look and behavior.

This involves patching form values, states, errors, and more. And it’s not limited to forms—other UI elements like accordions also require similar treatment.

Fortunately, Angular provides a powerful tool to address this: the RouteReuseStrategy class.

RouteReuseStrategy: what does it do?

You’ll find plenty of in-depth articles on RouteReuseStrategy, but here’s the gist: it allows you to control when Angular should dispose of or retain a component during navigation.

In our scenario, we want Angular to “set aside” (hide) components instead of destroying them when leaving a route, and to retrieve them as-is when navigating back.

By default, Angular uses an internal strategy, but we can override it with a custom implementation.

Creating a Custom Reuse Strategy

Here’s how we can define a custom RouteReuseStrategy:

@Injectable({
  providedIn: 'root',
})
export class CustomReuseStrategy implements RouteReuseStrategy {}

// main.ts
bootstrapApplication(AppComponent, {
  providers: [
    // ...
    {
      provide: RouteReuseStrategy,
      useExisting: CustomReuseStrategy,
    },
  ],
});

Note: Marking it as Injectable isn’t strictly required since Angular handles it internally, but this approach offers flexibility—more on that in a moment.

Defining Route Reuse Behavior

Let’s establish a convention for managing routes:

Use storeRoute: true for routes that should not be destroyed.
Use noReuse: true for routes that must not reuse components, even if the paths are identical.

The noReuse flag is critical for routes with parameters (e.g., /users/1 vs. /users/2). Without it, these routes would share the same component instance, leading to unintended state sharing.

Here’s how your routes might look:

const routes: Routes = [
  {
    path: 'users',
    component: UsersComponent,
    data: {
      storeRoute: true,
    },
  },
  {
    path: 'users/:id',
    component: UserComponent,
    data: {
      noReuse: true,
      storeRoute: true,
    },
  },
  {
    path: '**',
    redirectTo: '/users',
  },
];

A couple of helpers

For our implementation we'll need a couple of helpers:

A function which constructs the full path of a route, in order to identify it
A function which compares two objects, for comparing parameters and query parameters

Here an example for both:

function compareObjects(a: any, b: any): boolean {
  return Object.keys(a).every(prop => 
    b.hasOwnProperty(prop) &&
    (typeof a[prop] === typeof b[prop]) &&
    (
      (typeof a[prop] === "object" && compareObjects(a[prop], b[prop])) ||
      (typeof a[prop] === "function" && a[prop].toString() === b[prop].toString()) ||
      a[prop] == b[prop]
    )
  );
}

// Returns the full path of a route, as a string
 export function getFullPath(route: ActivatedRouteSnapshot): string {
  return route.pathFromRoot
    .map(v => v.url.map(segment => segment.toString()).join("/"))
    .join("/")
    .trim()
    .replace(/\/$/, ""); // Remove trailing slash
}

Implementing `RouteReuseStrategy`

Let's implement the class. First, we must create an object to cache our components:

import {
  ActivatedRouteSnapshot,
  DetachedRouteHandle,
  RouteReuseStrategy
} from "@angular/router";

interface StoredRoute {
  route: ActivatedRouteSnapshot;
  handle: DetachedRouteHandle;
}

@Injectable({
  providedIn: 'root'
})
export class CustomReuseStrategy implements RouteReuseStrategy {
  storedRoutes: Record<string, StoredRoute | null> = {};
}

I won't go into details about DetachedRouteHandle, but that's what will bring our component back when the route is visited again.

Now we must implement the required methods of RouteReuseStrategy.

A shouldDetach method decides whether to detach a route or not: we'll decide based on the storeRoute property in our route configuration.

  // Should we store the route? Defaults to false.
  shouldDetach(route: ActivatedRouteSnapshot): boolean {
    return !!route.data['storeRoute'];
  }

A store method allows us to store our route when navigating away from it. We'll store it by full path with our helper from before:

  // Store the route
  store(
    route: ActivatedRouteSnapshot,
    handle: DetachedRouteHandle
  ): void {
    // Ex. users/1, users/2, users/3, ...
    const key = getFullPath(route);
    this.storedRoutes[key] = { route, handle };
  }

A shouldAttach method decides whether to grab the route from our cache or not. Here, we compare all route parameters, including queryParams.

  // Should we retrieve a route from the store?
  shouldAttach(route: ActivatedRouteSnapshot): boolean {
    const key = getFullPath(route);
    const isStored = !!route.routeConfig && !!this.storedRoutes[key];

    if (isStored) {
      // Compare params and queryParams.
      // Params, however, have already been compared because the key includes them.
      const paramsMatch = compareObjects(
        route.params,
        this.storedRoutes[key]!.route.params
      );
      const queryParamsMatch = compareObjects(
        route.queryParams,
        this.storedRoutes[key]!.route.queryParams
      );

      return paramsMatch && queryParamsMatch;
    }
    return false;
  }

A retrieve method is used to grab the route from our cache:

  // Retrieve from the store (it only needs the handle)
  retrieve(route: ActivatedRouteSnapshot) {
    const key = getFullPath(route);
    if (!route.routeConfig || !this.storedRoutes[key]) return null;
    return this.storedRoutes[key].handle;
  }

Finally, shouldReuseRoute decides whether a route with the same path as the previous one should be reused. Again, we'll refer to our convention, and true will be the default:

  // Should the route be reused?
  shouldReuseRoute(
    previous: ActivatedRouteSnapshot,
    next: ActivatedRouteSnapshot
  ): boolean {
    const isSameConfig = previous.routeConfig === next.routeConfig;
    const shouldReuse = !next.data['noReuse'];
    return isSameConfig && shouldReuse;
  }

Convenience methods for purging the cache

It's important to understand that when a route is cached, the associated component is never destroyed. This also means that ngOnInit will not be triggered again when the user navigates back to the route. While this can be beneficial for preserving state, it also introduces the risk of memory leaks if not handled properly.

To mitigate this, I recommend implementing convenience methods to manually purge the cache: one for clearing a single route and another for clearing all routes.

  // Destroys the components of all stored routes
  clearAllRoutes() {
    for (const key in this.storedRoutes) {
      if (this.storedRoutes[key]!.handle) {
        this.destroyComponent(this.storedRoutes[key]!.handle);
      }
    }
    this.storedRoutes = {};
  }

  // Destroys the component of a particular route.
  clearRoute(fullPath: string) {
    if (this.storedRoutes[fullPath]?.handle) {
      this.destroyComponent(this.storedRoutes[fullPath].handle);
      this.storedRoutes[fullPath] = null;
    }
  }

  // A bit of a hack: manually destroy a particular component.
  private destroyComponent(handle: DetachedRouteHandle): void {
    const componentRef: ComponentRef<any> = (handle as any).componentRef;
    if (componentRef) {
      componentRef.destroy();
    }
  }

Conclusion

Here's the end result:

When navigating back to a cached route, the component retains all of its state seamlessly. Additionally, you can manually clear the cache whenever needed.

This solution is highly "plug-and-play" and can be easily integrated into your projects. However, use it wisely—improper use can make your app prone to memory leaks.

Link to the full demo here.

AccademiaDev: text-based web development courses!

Angular's inject function: a couple of years later...

Michele Stieven — Sun, 19 Jan 2025 23:50:42 +0000

Angular 14 introduced a new inject() function, offering an alternative to constructors for injecting dependencies.

export class MyComponent {
  myService = inject(MyService);
}

This brought several advantages, such as:

Easier inheritance

inject simplifies inheritance by eliminating the need to call super() in subclasses and reducing boilerplate code. This is especially useful when dependencies are inherited:

export class A {
  x = inject(X);
  y = inject(Y);
}

export class B extends A {
  z = inject(Z);

  // No need for constructors,
  // no need to inject X and Y,
  // no need to call super()
}

Avoiding Parameter Decorators

Previously, when requesting a non-class dependency (e.g., an InjectionToken), the @Inject() decorator was often used:

export class A {
  constructor(@Inject(X) x: SomeType) {}
}

With inject, you can skip the decorator and enjoy automatic type inference, making the code more concise and type-safe:

export class A {
  x = inject(X); // Works even with an InjectionToken
}

Additionally, inject's second parameter lets you control options like Optional, SkipSelf, Self, and Host—all without needing extra decorators:

// Default options
x = inject(X, {
  optional: false,
  skipSelf: false,
  self: false,
  host: false
})

In short, inject is a convenient utility. And as we've seen time and time again, convenience often wins over best practices.

This was my concern when it was first introduced: inject could encourage practices that aren't ideal, especially for mid-level developers. As a consultant and trainer, I feared its misuse.

Now that a couple of years have passed, it’s a good time to reflect and see if these fears have materialized.

Classes lose their "purity"

One of the core principles of Dependency Injection (DI) is that dependencies are passed into the class, meaning the class doesn't need to "grab" them itself.

export class A {
  // x is passed like a parameter
  constructor(x: X) {}
}

This makes unit testing extremely simple, as it's easy to substitute the dependency with a mock or fake:

const x = getFakeX();
const a = new A(x);

// Do your tests...

With inject, however, this simplicity is no longer guaranteed. Now, you must assume that any Angular class could be using inject, so you can no longer pass dependencies directly like this. Instead, you need to rely on Angular’s testing helper, TestBed, which sets up an injector:

describe('A Component', () => {
  let fixture: ComponentFixture<A>;
  let component: A;

  beforeEach(() => {
    TestBed.configureTestingModule({
      declarations: [A],
      providers: [
        { provide: X, useValue: MockX }
      ]
    });

    fixture = TestBed.createComponent(A);
    component = fixture.componentInstance;
  });
});

While this introduces more verbosity, it’s manageable, and the simplicity of Angular’s DI system remains intact in terms of functionality. Moreover, TestBed is necessary for testing the component's DOM, so I don't consider this a real drawback.

Scattered dependencies

Previously, all dependencies were neatly listed in the constructor, making them easy to spot. With inject, however, dependencies can now be scattered throughout the class:

export class A {
  x = inject(X);

  // ... 100 lines of code later ...
  y = inject(Y);

  // ... 
  z = inject(Z);
}

In practice, developers often group their dependencies at the top of the class for clarity, so this issue rarely becomes a major problem. However, it does reduce the immediate visibility of dependencies within the class.

Hidden dependencies

The real concern arises with the ability to call inject inside another function, but only if that function is invoked at construction time. This enables patterns like the following:

export class A {
  x = thisFunctionUsesInject();
}

function thisFunctionUsesInject() {
  const x = inject(X);
  return x;
}

This pattern is gaining popularity due to its convenience. However, it comes with its own set of challenges:

Hidden Dependencies: The dependency is now hidden inside a function, making it less obvious to anyone reading the code. They might expect the function to be usable anywhere, but if it's not executed during the construction phase, it will throw an error. This assumes the reader has knowledge of how Angular’s DI system works.
Lack of Transparency: When inspecting the component, it's not immediately clear that there are any dependencies. To understand the component fully, you need to dive into the function that uses inject(). This introduces complexity, as the component may seem simpler than it actually is. Some developers have suggested naming these functions with an "inject" prefix to clarify the dependency injection relationship, but I don’t agree with that approach. Such naming could be misleading if the function returns something different than what is being injected.
Increased Testing Complexity: As with any other situation where dependencies are not directly visible, you'll still need to use TestBed for testing. But as established earlier, this is not a major issue in itself.

To wrap it up, while it's certainly a useful pattern, I suggest not to abuse it and use it with care, because it can make your code harder to grasp.

What is an Injection Context?

The inject function can only be used within an Injection Context, but what exactly does that mean? In practice, this refers to specific places where Angular manages the lifecycle and context of a class or function, allowing it to resolve dependencies. These places include:

Constructors
Property initializers
Guards
Interceptors
useFactory when declaring providers

It’s fairly straightforward to understand that inject works during class construction because the class itself is being instantiated, and Angular has control over the DI context. However, the fact that it can also be used in places like guards or interceptors can be more confusing. This is a concern I’ve seen materialize frequently in my role as a consultant and trainer.

A particularly confusing scenario I’ve encountered involves functional NgRx Effects, where inject() is used in a function which shouldn't have any arguments:

// Functional NgRx Effect injecting Actions
createEffect((actions$ = inject(Actions)) => actions$.pipe(...), {
  functional: true
});

Here’s the trick: you have to understand that an Injection Context is automatically set up when NgRx creates the effect. The key to this pattern is that the inner function takes no arguments, so we exploit this by setting a default parameter, which just happens to be an injected dependency.

This pattern is not easy to grasp, especially for newcomers. The idea that inject works without explicitly calling a constructor or using a class can be quite confusing, and many developers, particularly those new to Angular or DI systems, struggle with this.

Minor causes of frustration I've seen on the web

Missed opportunity for a better name?: When inject was first introduced, some developers pointed out that it's actually the Injector (not inject itself) that performs the dependency injection. As a result, a few suggested that a different name, like ask or retrieve, would better reflect the function’s role. Personally, I don’t see this as a major issue. The name inject aligns with naming conventions in other frameworks, and it doesn’t cause any confusion for me.
Isn't this a Service Locator?: Another concern raised by some developers is that inject might resemble the Service Locator anti-pattern rather than true Dependency Injection. While it can be convincingly argued that inject is not a Service Locator (as highlighted in this insightful article), I do understand where the confusion stems from. The reason is that inject shares some of the same drawbacks as Service Locators, such as hidden dependencies and testing challenges.

Personally, I don’t believe inject is a Service Locator, but it also doesn't feel like a "pure" form of Dependency Injection. It’s somewhere in between. But it’s worth noting that some of the same issues could arise even before inject was introduced—simply by using the Injector to retrieve dependencies directly. Perhaps even worse, but it was not a common pattern.

Takeaways

The new inject function has proven to be incredibly useful, simplifying certain aspects of writing Angular code. Overall, I’m quite fond of it and generally recommend it over constructor parameters. I believe it’s valuable to adhere to a single, consistent practice, making the codebase easier to understand.

However, Angular developers need to invest some time in understanding what an Injection Context is and where inject can be safely used. It also takes time to fully grasp some of the more subtle patterns, such as hidden dependencies or using dependencies as default values for function parameters.

Given these nuances, I believe that documentation websites should take extra care when explaining what constitutes an Injection Context. It’s important not to assume too much knowledge from developers and to clarify how and when inject should be used.

AccademiaDev: text-based web development courses!

Angular LAB: animating lists and using AnimationBuilder for imperative animations

Michele Stieven — Wed, 09 Oct 2024 18:08:12 +0000

Did you know that Angular includes a complex animation system? I find it especially useful when I want to animate elements when they enter the screen or when they get destroyed!

Also, you can use AnimationBuilder in order to imperatively play, pause or stop some custom animations! Let's see how it's done.

Creating a list

In this exercise we start by creating a list, something like this:

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <button (click)="addUser()">Add user</button>
    <ul>
    @for (user of users(); track user.id) {
      <li>{{ user.name }}</li>
    }
    </ul>
  `,
})
export class AppComponent {
  users = signal<User[]>([
    { id: Math.random(), name: 'Michele' }
  ]);

  addUser() {
    this.users.update(users => [...users, { id: Math.random(), name: 'New user' }]);
  }
}

Notice that we've included a button which adds a user to the list!

Animating the list

Now, what if we want to animate the new user which will be added? First, we want to tell Angular that we want to use its animation system by providing it in your main configuration:

import { provideAnimationsAsync } from '@angular/platform-browser/animations/async';

bootstrapApplication(AppComponent, {
  providers: [
    provideAnimationsAsync(),
  ]
});

Then, we can create our animation:

import { trigger, transition, style, animate } from '@angular/animations';

const fadeInAnimation = trigger('fadeIn', [
  transition(':enter', [
    style({ transform: 'scale(0.5)', opacity: 0 }),
    animate(
      '.3s cubic-bezier(.8, -0.6, 0.2, 1.5)', 
      style({ transform: 'scale(1)', opacity: 1 })
    )
  ])
])

With these helpers we:

Created an animation trigger called fadeIn
Added a transition when the element enters the screen
Applied an initial style
Immediately started the animation which will result in a new style applied to the element

For more information on how to write animations, you can refer to the official guide which is awesome!

Now let's apply this animation to each of our elements in the list:

@Component({
  ...,
  template: `
    <button (click)="addUser()">Add user</button>
    <ul>
    @for (user of users(); track user.id) {
      <li @fadeIn>{{ user.name }}</li> <!-- Notice here -->
    }
    </ul>
  `,
  // Also, add the animation to the metadata of the component
  animations: [fadeInAnimation]
})

Now, when a new item is added, it gets animated! Our first step is done.

Notice that in order for our animation to work correctly, Angular has to track each element in our for, because otherwise it could end up re-creating the same elements when updating the template, resulting in unwanted animations. This comes for free with the new Control Flow syntax because the track property is mandatory, but if you're using old verisons of Angular with the *ngFor directive, you must use the trackBy option like this:

<li
  *ngFor="let user of users; trackBy: trackByUserId"
  @fadeIn
>{{ user.name }}</li>

// A class method in your component:
trackByUserId(index, user: User) {
  return user.id;
}

Now, let's add another type of animation to our list.

AnimationBuilder

Let's add a button to each element of our list:

<li @fadeIn>
  {{ user.name }}
  <button>Make me blink</button>
</li>

Imagine this: we want to make the element blink when we press the button. That'd be cool! This is where the AnimationBuilder service comes in.

First, let's create a Directive which will be applied to every element. In this directive, we'll inject both ElementRef and AnimationBuilder:

import { AnimationBuilder, style, animate } from '@angular/animations';

@Directive({
  selector: '[blink]',
  exportAs: 'blink', // <--- Notice
  standalone: true
})
export class BlinkDirective {

  private animationBuilder = inject(AnimationBuilder);
  private el = inject(ElementRef);
}

Notice that we exported the directive: we'll get to the reason in a few seconds.

Then, we can create a custom animation like this:

export class BlinkDirective {

  ...

  private animation = this.animationBuilder.build([
    style({ transform: 'scale(1)', opacity: 1 }),
    animate(150, style({ transform: 'scale(1.1)', opacity: .5 })),
    animate(150, style({ transform: 'scale(1)', opacity: 1 }))
  ]);
}

We're using the same functions that we used in the previous animation, just with different styles.

Now we want to create a player which will perform the animation on our element:

export class BlinkDirective {

  ...

  private player = this.animation.create(this.el.nativeElement);
}

And now let's expose a method which will actually start the animation!

export class BlinkDirective {

  ...

  start() {
    this.player.play();
  }
}

There's only one step left: we must import the directive, apply it to our elements, grab it with a template variable and call the method when the button is pressed!

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <button (click)="addUser()">Add user</button>
    <ul>
    @for (user of users(); track user.id) {
      <li @fadeIn blink #blinkDir="blink">
        {{ user.name }}
        <button (click)="blinkDir.start()">Make me blink</button>
      </li>
    }
    </ul>
  `,
  imports: [BlinkDirective],
  animations: [
    fadeInAnimation
  ]
})

We can grab the directive's instance and put it in a local variable because we previously exported the directive with exportAs. That's the key part!

Now, try clicking on the button: the element whould be animated correctly!

The exercise is complete, but this is just the tip of the iceberg! The AnimationPlayer has a lot of commands which you can use to stop, pause and resume the animation. Very cool!

interface AnimationPlayer {
  onDone(fn: () => void): void;
  onStart(fn: () => void): void;
  onDestroy(fn: () => void): void;
  init(): void;
  hasStarted(): boolean;
  play(): void;
  pause(): void;
  restart(): void;
  finish(): void;
  destroy(): void;
  reset(): void;
  setPosition(position: number): void;
  getPosition(): number;
  parentPlayer: AnimationPlayer;
  readonly totalTime: number;
  beforeDestroy?: () => any;
}

Here's our full example if you want to play with it: just put it in your main.ts file and see it in action!

import { Component, signal, Directive, ElementRef, inject } from '@angular/core';
import { bootstrapApplication } from '@angular/platform-browser';
import { trigger, transition, style, animate, AnimationBuilder } from '@angular/animations';
import { provideAnimationsAsync } from '@angular/platform-browser/animations/async';

interface User {
  id: number;
  name: string;
}

@Directive({
  selector: '[blink]',
  exportAs: 'blink',
  standalone: true
})
export class BlinkDirective {

  private animationBuilder = inject(AnimationBuilder);
  private el = inject(ElementRef);

  private animation = this.animationBuilder.build([
    style({ transform: 'scale(1)', opacity: 1 }),
    animate(150, style({ transform: 'scale(1.1)', opacity: .5 })),
    animate(150, style({ transform: 'scale(1)', opacity: 1 }))
  ]);

  private player = this.animation.create(this.el.nativeElement);

  start() {
    this.player.play();
  }
}

const fadeInAnimation = trigger('fadeIn', [
  transition(':enter', [
    style({ transform: 'scale(0.5)', opacity: 0 }),
    animate(
      '.3s cubic-bezier(.8, -0.6, 0.2, 1.5)', 
      style({ transform: 'scale(1)', opacity: 1 })
    )
  ])
])

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <button (click)="addUser()">Add user</button>
    <ul>
    @for (user of users(); track user.id) {
      <li @fadeIn blink #blinkDir="blink">
        {{ user.name }}
        <button (click)="blinkDir.start()">Make me blink</button>
      </li>
    }
    </ul>
  `,
  imports: [BlinkDirective],
  animations: [
    fadeInAnimation
  ]
})
export class App {
  users = signal<User[]>([
    { id: Math.random(), name: 'Michele' }
  ]);

  addUser() {
    this.users.update(users => [...users, { id: Math.random(), name: 'New user' }]);
  }
}

bootstrapApplication(App, {
  providers: [
    provideAnimationsAsync()
  ]
});

AccademiaDev: text-based web development courses!

Angular LAB: let's create a Visibility Directive

Michele Stieven — Wed, 09 Oct 2024 00:05:23 +0000

In this article I'm going to illustrate how to create a very simple Angular Directive that keeps track of an element's visibility state, or in other words, when it goes in and out of the viewport. I hope this will be a nice and perhaps useful exercise!

In order to do this, we're going to use the IntersectionObserver JavaScript API which is available in modern browsers.

What we want to achieve

We want to use the Directive like this:

<p
  visibility
  [visibilityMonitor]="true"
  (visibilityChange)="onVisibilityChange($event)"
>
  I'm being observed! Can you see me yet?
</p>

visibility is the selector of our custom directive
visibilityMonitor is an optional input which specifies whether or not to keep observing the element (if false, stop monitoring when it enters the viewport)
visibilityChange will notifies us

The output will be of this shape:

type VisibilityChange =
  | {
      isVisible: true;
      target: HTMLElement;
    }
  | {
      isVisible: false;
      target: HTMLElement | undefined;
    };

Having an undefined target will mean that the element has been removed from the DOM (for example, by an @if).

Creation of the Directive

Our directive will simply monitor an element, it will not change the DOM structure: it will be an Attribute Directive.

@Directive({
  selector: "[visibility]",
  standalone: true
})
export class VisibilityDirective implements OnInit, OnChanges, AfterViewInit, OnDestroy {
  private element = inject(ElementRef);

  /**
   * Emits after the view is initialized.
   */
  private afterViewInit$ = new Subject<void>();

  /**
   * The IntersectionObserver for this element.
   */
  private observer: IntersectionObserver | undefined;

  /**
   * Last known visibility for this element.
   * Initially, we don't know.
   */
  private isVisible: boolean = undefined;

  /**
   * If false, once the element becomes visible there will be one emission and then nothing.
   * If true, the directive continuously listens to the element and emits whenever it becomes visible or not visible.
   */
  visibilityMonitor = input(false);

  /**
   * Notifies the listener when the element has become visible.
   * If "visibilityMonitor" is true, it continuously notifies the listener when the element goes in/out of view.
   */
  visibilityChange = output<VisibilityChange>();
}

In the code above you see:

the input and output we talked about earlier
a property called afterViewInit$ (an Observable) which will act as a reactive counterpart to the ngAfterViewInit lifecycle hook
a property called observer which will store the IntersectionObserver in charge of monitoring our element
a property called isVisibile which will store the last visibility state, in order to avoid re-emitting the same state twice in a row

And naturally, we inject the ElementRef in order to grab the DOM element on which we apply our directive.

Before writing the main method, let's take care of the lifecycle of the directive.

ngOnInit(): void {
  this.reconnectObserver();
}

ngOnChanges(): void {
  this.reconnectObserver();
}

ngAfterViewInit(): void {
  this.afterViewInit$.next();
}

ngOnDestroy(): void {
  // Disconnect and if visibilityMonitor is true, notify the listener
  this.disconnectObserver();
  if (this.visibilityMonitor) {
    this.visibilityChange.emit({
      isVisible: false,
      target: undefined
    });
  }
}

private reconnectObserver(): void {}
private disconnectObserver(): void {}

Now here's what happens:

Inside both ngOnInit and ngOnChanges we restart the observer. This is in order to make the directive reactive: if the input changes, the directive will start behaving differently. Notice that, even if ngOnChanges also runs before ngOnInit, we still need ngOnInit because ngOnChanges doesn't run if there are no inputs in the template!
When the view is initialized we trigger the Subject, we'll get to this in a few seconds
We disconnect our observer when the directive is destroyed in order to avoid memory leaks. Lastly, if the developer asked for it, we notify that the element has been removed from the DOM by emitting an undefined element.

IntersectionObserver

This is the heart of our directive. Our reconnectObserver method will be the one to start observing! It'll be something like this:

private reconnectObserver(): void {
    // Disconnect an existing observer
    this.disconnectObserver();
    // Sets up a new observer
    this.observer = new IntersectionObserver((entries, observer) => {
      entries.forEach(entry => {
        const { isIntersecting: isVisible, target } = entry;
        const hasChangedVisibility = isVisible !== this.isVisible;
        const shouldEmit = isVisible || (!isVisible && this.visibilityMonitor);
        if (hasChangedVisibility && shouldEmit) {
          this.visibilityChange.emit({
            isVisible,
            target: target as HTMLElement
          });
          this.isVisible = isVisible;
        }
        // If visilibilyMonitor is false, once the element is visible we stop.
        if (isVisible && !this.visibilityMonitor) {
          observer.disconnect();
        }
      });
    });
    // Start observing once the view is initialized
    this.afterViewInit$.subscribe(() => {
        this.observer?.observe(this.element.nativeElement);
    });
  }

Trust me, it's not as complicated as it seems! Here's the mechanism:

First we disconnect the observer if it was already running
We create an IntersectionObserver and define its behavior. The entries will contain the monitored elements, so it will contain our element. The property isIntersecting will indicate if the element's visibility has changed: we compare it to the previous state (our property) and if it's due, we emit. Then we store the new state in our property for later.
If visibilityMonitor is false, as soon as the element becomes visible we disconnect the observer: its job is done!
Then we have to start the observer by passing our element, so we wait for our view to be initialized in order to do that.

Lastly, let's implement the method which disconnects the observer, easy peasy:

 private disconnectObserver(): void {
    if (this.observer) {
      this.observer.disconnect();
      this.observer = undefined;
    }
  }

Final code

Here's the full directive. This was just an exercise, so be free to change it to whatever you like!

type VisibilityChange =
  | {
      isVisible: true;
      target: HTMLElement;
    }
  | {
      isVisible: false;
      target: HTMLElement | undefined;
    };

@Directive({
  selector: "[visibility]",
  standalone: true
})
export class VisibilityDirective
  implements OnChanges, OnInit, AfterViewInit, OnDestroy {
  private element = inject(ElementRef);

  /**
   * Emits after the view is initialized.
   */
  private afterViewInit$ = new Subject<void>();

  /**
   * The IntersectionObserver for this element.
   */
  private observer: IntersectionObserver | undefined;

  /**
   * Last known visibility for this element.
   * Initially, we don't know.
   */
  private isVisible: boolean = undefined;

  /**
   * If false, once the element becomes visible there will be one emission and then nothing.
   * If true, the directive continuously listens to the element and emits whenever it becomes visible or not visible.
   */
  visibilityMonitor = input(false);

  /**
   * Notifies the listener when the element has become visible.
   * If "visibilityMonitor" is true, it continuously notifies the listener when the element goes in/out of view.
   */
  visibilityChange = output<VisibilityChange>();

  ngOnInit(): void {
    this.reconnectObserver();
  }

  ngOnChanges(): void {
    this.reconnectObserver();
  }

  ngAfterViewInit(): void {
    this.afterViewInit$.next(true);
  }

  ngOnDestroy(): void {
    // Disconnect and if visibilityMonitor is true, notify the listener
    this.disconnectObserver();
    if (this.visibilityMonitor) {
      this.visibilityChange.emit({
        isVisible: false,
        target: undefined
      });
    }
  }

  private reconnectObserver(): void {
    // Disconnect an existing observer
    this.disconnectObserver();
    // Sets up a new observer
    this.observer = new IntersectionObserver((entries, observer) => {
      entries.forEach(entry => {
        const { isIntersecting: isVisible, target } = entry;
        const hasChangedVisibility = isVisible !== this.isVisible;
        const shouldEmit = isVisible || (!isVisible && this.visibilityMonitor);
        if (hasChangedVisibility && shouldEmit) {
          this.visibilityChange.emit({
            isVisible,
            target: target as HTMLElement
          });
          this.isVisible = isVisible;
        }
        // If visilibilyMonitor is false, once the element is visible we stop.
        if (isVisible && !this.visibilityMonitor) {
          observer.disconnect();
        }
      });
    });
    // Start observing once the view is initialized
    this.afterViewInit$.subscribe(() => {
        this.observer?.observe(this.element.nativeElement);
    });
  }

  private disconnectObserver(): void {
    if (this.observer) {
      this.observer.disconnect();
      this.observer = undefined;
    }
  }
}

AccademiaDev: text-based web development courses!

How I structure my Angular components with Signals

Michele Stieven — Tue, 08 Oct 2024 15:34:44 +0000

In this short article I want to show you how I like to structure my components with signals, with no external library. Of course things like NgRx would play a huge role to make our code more robust, but let's start simple!

First of all I define all of my states with signals:

export class TodoListComponent {
  todos = signal<Todo[]>([]);
}

The same applies for inputs, too! If my component needs an input, I declare it with the new input() function by Angular, which gives me a signal as well. And if it happens to be a route parameter, I use input.required().

Then, if I want to show some state that can be derived from another one, I always use computed:

completedTodos = computed(() => this.todos().filter(t => t.completed));

Then, if you know me, you know how much I despise performing asynchronous side-effects directly inside class methods... 🤢

export class TodoListComponent {
  todoService = inject(TodoService);

  toggleTodo(id: string) {
    this.todoService.toggle(id).subscribe(newTodo => ...);
  }
}

Why you ask? Because if the method is the one who directly initiates the side-effect (in this case, calling subscribe), you have no control over back-pressure.

Back-pressure can be summed up with this: what happens if the user toggles the todo while the previous call hasn't finished?

There are a number of problems, for example:

Do we even want to perform the second call? Or wait for the first one to finish? Or should we cancel the first one?
What if we toggle different items in a short time?
What if we want to introduce some sort of debounce or throttle?

If you know RxJS (and if you're reading this, you should by now!) you know that the first problem is easily solved with the 4 Flattening Operators (mergeMap, concatMap, switchMap, exhaustMap).

Then, if you know RxJS quite well, you know that you can solve the second problem with an awesome operator called groupBy!

But in order to use all of this goodness, you must have an Observable source, so... not a method.

Subjects

Think of a Subject like an open (not completed), empty Observable. It's the perfect tool to represent custom events.

All of the events in our component can be represented by Subjects:

export class TodoListComponent {
  ...

  toggleTodo$ = new Subject<string>();
  deleteTodo$ = new Subject<string>();
  addTodo$ = new Subject<void>();
}

Then, our template can simply call them when necessary, instead of calling methods, for example:

<button (click)="deleteTodo$.next(todo.id)">delete</button>

Now that our sources are Observables, we can use our dear operators: let's create some effects.

Effects

I like to define my effects inside the constructor so that I can use the takeUntilDestroyed() operator to clean up the effect when the component is destroyed! So, for example:

constructor() {
  this.addTodo$.pipe(
    concatMap(() => this.todoService.add())
    takeUntilDestroyed()
  ).subscribe(newTodo => this.todos.update(todos => [...todos, newTodo]));
}

Here I'm using concatMap in order to preserve the order of the responses, so that the todos are added in order. This means that there are no concurrent calls. I think it's perfect for add operations, but it may be the wrong choice for other calls: for instance, for a GET request, it's usually better to use exhaustMap or switchMap, depending on the use case.

I'm also using an approach which is called Pessimistic Update, which means that I wait for the call to end to update my internal state. This is a personal preference! You could add the todo right away, and then revert it back by using a catchError if the API call errors out.

Then there's the actual effect function from Angular which is meant to be used in conjunction with signals: I use this function for synchronization tasks. For example, when a parameter changes in the URL (referring to a new entity ID), I may want to update a form with the new entity:

// This comes from the router
id = input.required<string>();

// Always stores the current invoice information
currentInvoice = toSignal(toObservable(this.id).pipe(
  switchMap(id => this.invoiceService.get(id))
));

constructor() {
  effect(() => {
    // Assuming the 2 structures match, every time we browse
    // to a new invoice, the form gets populated
    this.form.patchValue(this.currentInvoice());
  })
}

Notice that we don't have control over back-pressure with this technique. For this kind of thing it's fine, but remember: that's why we still need RxJS in order to craft bug-free apps. Or another library which abstracts this complexity under the hood.

Going full Reactive is not always a good idea

Many states that we represent with signals could be technically be considered derived asynchronous states. For example, our Todo list could be considered a derived state from the server:

// Trigger this when you need to refetch the todos
fetchTodos$ = new Subject<void>();

todos = toSignal(toObservable(this.fetchTodos$).pipe(
  switchMap(id => this.todoService.getAll())
));

This approach is similar to the one used by libraries such as TanStack Query, in which you manually invalidate a query when you need the new data. In other words, you always go to the server for each mutation.

This may be good in some scenarios, but there are 2 things to consider:

It makes updating the state manually (optimistic updates) difficult. This is made easier by libraries such as TanStack Query, but doing it manually is a pain.
It makes the code somewhat harder to grasp by most developers, this is what I see as a consultant working on this kind of stuff daily.

In short, I usually don't recommend it. And I said usually! :)

Conclusion

I hope you liked this short article! As a summary:

Define your states as signals
Define your derived states as computed signals
Define your asynchronous effect as Observables
Define your synchronozation effects with effects

I'm sure that if you follow these principles your apps will be much easier to maintain!

AccademiaDev: text-based web development courses!

Angular - Error Handling 101

Michele Stieven — Sun, 30 Jul 2023 01:26:51 +0000

In an Angular app, we can handle errors in many ways, each with its pros and cons: let's explore them.

HTTP errors

The most common case of error is an HTTP call gone bad. We may act upon it in different ways: we could either react to it, replace a value, or do nothing at all. And if we want to recover, where should we do it? At the component level, in a service, in a store...?

First things first. When there's a HTTP error, Angular wraps it in a class called HttpErrorResponse: this happens both when the error is server-side (eg. a 500 error) and when the client makes a wrong request.

These are just some fields of the class:

class HttpErrorResponse {
  message: string;
  error: any | null;
  status: number;
  statusText: string;
  url: string | null;
  ...
}

This structure is thrown as an error on the Observable you subscribe to in order to start the request. You can then use these properties to understand the error type: for example, you can look at status to check if the user's session has expired!

But what options do we have to recover from an error?

retry

Since the HttpClient service returns an Observable for each call, we can easily use RxJS operators.

You can use retry in order to repeat the call if it errors out. You can even specify a maximum number of times:

import { retry } from 'rxjs';

getPosts() {
  return this.http.get<Post[]>('/api/post').pipe(
    retry(3)
  );
}

Instead of a number, you can supply a more powerful configuration object:

interface RetryConfig {
  count?: number
  delay?: number | ((error: any, retryCount: number) => ObservableInput<any>)
  resetOnSuccess?: boolean
}

With this, you can even delay the re-subscription (by a number of milliseconds, or when another Observable emits something), and tell whether the error count should be reset when a value is emitted.

timeout

Speaking of HTTP requests, I cannot but recall the existence of a timeout operator, which does the opposite of what we want: it triggers an error, if the Observable doesn't emit in N milliseconds. It can come in handy together with retry or other operators.

import { timeout } from 'rxjs';

getPosts() {
  return this.http.get<Post[]>('/api/post').pipe(
    timeout(3000)
  );
}

catchError

Another useful operator is catchError. This one may seem a bit strange at first, but that's because it's very flexible. Let me explain.

When an Observable errors out, it stops completely. It cannot emit anything else, its life ends. The only way to get new values out of it is to subscribe again, restarting its execution.

For this reason, this operator doesn't simply let you replace the error with a value: instead, it lets you switch to a new Observable in order to continue its life.

catchError(error => otherObservable)

For example, you may want to perform an additional HTTP request (a different one, otherwise you could simply use retry):

catchError(error => this.http.get(...))

But if this is too much, you can just return a value and that's it. The Observable will replace the error with the supplied value and then complete. You can supply the value by wrapping it in an Observable:

import { of } from 'rxjs';

catchError(error => of(value))

Or, if you don't want to use the of operator, you could wrap it in an array:

catchError(error => [value]);

This works because every RxJS operator which accepts an Observable also accepts arrays, promises and iterators (they're called ObservableInput). They're all converted under the hood to an Observable.

Now let's ask ourselves: where should we handle the errors?

The first place to consider is the simplest, inside the subscribe. This usually happens inside Components. Something like this:

export class PostComponent {

  getPosts() {
    this.http.get<Post[]>('/api/post').subscribe({
      next: posts => this.posts = posts,
      error: e => this.error = e,
    });
  }
}

This way, we can handle the errors in a very specific way, for example showing different errors based on the HTTP call or the page that the visitor is seeing.

At the same time, it's also a bit verbose, but it obviously depends on how many errors we want to intercept.

But one thing must be clear: we're not remedying the situation! We're just detecting the error. If we wanted to recover from the error, we should use the operators we talked about earlier, for example catchError.

export class PostComponent {

  getPosts() {
    this.http.get<Post[]>('/api/post').pipe(
      catchError(() => []),
    ).subscribe(posts => {
      this.posts = posts;
    });
  }
}

So, always remember this important difference: when we use catchError, we don't receive the error in the subscribe anymore.

Services

If you're using Services in your app (you probably should), you may also catch the errors there, before being delivered to the Components. Something like this:

@Injectable({ providedIn: 'root' })
export class PostService {

  http = inject(HttpClient);

  getPosts() {
    return this.http.get<Post[]>('/api/post').pipe(
      catchError(() => []),
    );
  }
}

This code, however, has a problem: as we said, the Component will never know what's happened.

So, for most cases, I don't recommend this approach: as the app grows, the need to show different error messages based on the page will also grow. With this technique, we cannot do that.

Instead, consider using Services but also catching the errors at the component level:

export class PostComponent {

  getPosts() {
    this.postService.getPosts().pipe(
      catchError(() => []),
    ).subscribe(posts => {
      this.posts = posts;
    });
  }
}

But if you also wanted to catch the errors at the Service level, you could use the tap operator to intercept the errors (but letting them be delivered to the components):

@Injectable({ providedIn: 'root' })
export class PostService {

  http = inject(HttpClient);

  getPosts() {
    return this.http.get<Post[]>('/api/post').pipe(
      tap({
        error: e => console.log(e)
      }),
    );
  }
}

This is not something I'd do normally, but it may be useful in some situations.

Interceptors

You can also handle HTTP errors globally with an Interceptor. Interceptors let you do stuff before and after each HTTP request in your app. This example uses the new syntax for functional interceptors:

function logInterceptor(
  req: HttpRequest<any>,
  next: HttpHandler
): Observable<HttpEvent<any>> {
  return next.handle(req).pipe(
    tap({
      error: e => console.log(e)
    })
  )
}

You can then provide the interceptor globally like this:

bootstrapApplication(AppComponent, {
  providers: [
    provideHttpClient(
      withInterceptors([logInterceptor])
    ) 
  ]
})

Be careful, though: don't catch the error, otherwise it won't be propagated to components! Instead, you may want to use this technique to handle some global state (eg. the number of ongoing requests, the total number of errors...).

You could however catch the errors which shouldn't be seen by the components, for example with retry you could hide the request gone bad to the user.

Interceptors are especially useful with 401 errors, signaling that the user's session has expired. This should cause a redirect to the login screen:

function logInterceptor(
  req: HttpRequest<any>,
  next: HttpHandler)
: Observable<HttpEvent<any>> {

  router = inject(Router);

  return next.handle(req).pipe(
    tap({
      error: e => {
        if (e instanceof HttpErrorResponse && e.status === 401) {
          this.router.navigateByUrl('/login');
        }
      }
    })
  )
}

Other common use-cases for interceptors are:

Global retry mechanism
Global request cache
Refreshing auth tokens
Appending Headers to requests
Etc...

Store

If you're using a Store, you usually put your side-effects somewhere specific: I'll make an example with NgRx.

If you're using a Store, it means that you're putting your data there instead of putting it inside the Components. This means that catching the errors inside an Effect is perfectly fine, and you may save the errors inside the Store directly.

loadPosts$ = createEffect(() => this.actions$.pipe(
  ofType(loadPosts),
  switchMap(() => this.postService.getPosts().pipe(
    map(posts => loadPostsSuccess(posts)),
    catchError(e => [loadPostsError(e)])
  ))
));

You may also want to group different error actions together and react to multiple errors in the same place:

handleAllErrors$ = createEffect(() => this.actions$.pipe(
  ofType(loadPostsError, loadUsersError, loadTodosError),
  ...
);

This is not something I'd suggest for the entire app (you'd be constantly updating it with dozens of actions) but for small sections of it (or pages) it should be totally fine.

ErrorHandler

Finally, if you don't want to remedy but just detect the errors, you can implement your own ErrorHandler by replacing the default one in Angular:

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

export class CustomErrorHandler implements ErrorHandler {
  handleError(error) {
    // Do what you want here, but throw it so that it's visible on the console!
    throw new Error(error);
  }
}

And provide it globally:

providers: [{
  provide: ErrorHandler,
  useClass: CustomErrorHandler
}]

This class intercepts all the unhandled errors in your app (not just HTTP errors but any error), it's the final place to consider for when you can't do anything to it. It's often useful for logging (eg. sending the error to an Analytics-like server). Of course, if you catch an error anywhere in your app (eg. with catchError), it won't end up here.

Conclusions

Always treat your errors as part of the program, handle them whenever possible
If it's something that the user should see, it's usually best to catch the error at the component-level or store-level
Use interceptors for HTTP errors that are not tied to a specific page, or that the user shouldn't see
Use ErrorHandler for unhandled errors (usually bugs)

AccademiaDev: text-based web development courses!

Photo by Sarah Kilian on Unsplash

Why I like Signals in Angular and the importance of Declarative code

Michele Stieven — Thu, 02 Mar 2023 03:37:25 +0000

I've been reading some great posts from very smart folks, about React, about Solid, and about Angular.

I basically love them all (both the frameworks and the folks!). I mean, I'm not a Hook enthusiast... but who cares.

You've heard the big news: Signals are coming to Angular! I love this for many reasons, but I want to focus on one important thing here: declarative code.

This article was inspired by an example of a React component from Dan Abramov:

// React
function VideoList({ videos, emptyHeading }) {
  const count = videos.length;
  let heading = emptyHeading;
  if (count > 0) {
    const noun = count > 1 ? 'Videos' : 'Video';
    heading = count + ' ' + noun;
  }
  return <h1>{heading}</h1>
}

Pretty simple! It accepts an array and a placeholder value, it does some calculations, and returns some text.

No videos here
1 Video
2 Videos

That's it, those are the combinations.

Now: I love Functional Programming, and React kinda follows a functional mindset.

f(state) = UI

I won't be talking about hooks here: it's not the point.

The point is that Functional Programming is a subset of Declarative Programming. And I love declarative code. And that particular component's example is something that I don't quite like.

In this case, that component was a trivial example to demonstrate a concept. But in reality, I find that kind of code in many projects, so let's start from there to talk about Declarative code and why I'm excited for Signals in Angular.

This post assumes a basic knowledge of Signals (and a bit of React for the comparisons)!

Functional is Declarative

Let's get back to the component:

// React
function VideoList({ videos, emptyHeading }) {
  const count = videos.length;
  let heading = emptyHeading;
  if (count > 0) {
    const noun = count > 1 ? 'Videos' : 'Video';
    heading = count + ' ' + noun;
  }
  return <h1>{heading}</h1>
}

Why don't I like it? Because this component's logic is imperative. This is not a problem with a component this small, but this is not how most components in complex codebases look like.

In order to understand what heading could be, I have to dig into all the rest of the component.

In pure functional programming, there are no variables, only constants. In JavaScript we can mutate variables, and we don't have to strictly follow FP's guidelines in order to write good code, but it's still a good recommendation in many cases.

This would be the declarative approach:

// React (declarative)
function VideoList({ videos, emptyHeading }) {
  const count = videos.length;

  const heading = count > 0
    ?  count + ' ' + (count > 1 ? 'Videos' : 'Video')
    :  emptyHeading;

  return <h1>{heading}</h1>
}

Each declaration contains all the logic for that particular constant. When I read const heading = this_thing, in my mind I read "This is what heading is all about". I don't care about the rest of the component.

The disadvantage here is that the ternary operator could be more difficult to read and a bit awkward to write. We also cannot really use intermediate variables (such as noun in the previous example) without strange syntaxes like IIFE's.

But this to me is a small disadvantage compared to what we get. Now, at first glance, I know what heading is all about. The declaration contains the full recipe on how to calculate that value. I no longer have to read the rest of the component to understand it.

This is especially important for me as a consultant: I need to be able to look at some code and immediately understand the logic behind it. Why? Because I cannot afford to understand the whole project, nor can the client! Time is money.

And this is true for the teams, too! If I can understand something immediately, it means that the people behind that code will be able to maintain it well.

Classes

Compared to pure functions, a class is a different mental model. It's not a potential flow of instructions, but a group of Properties and Methods.

This means that the previous React component (the imperative one) cannot be written in the same way if we use a class. We'd have to place the logic inside a method. It'd be both ugly and strange.

// Angular (kinda, you get the point)
class VideoListComponent {

  @Input() videos;
  @Input() emptyHeading;

  count = 0;
  heading = '';

  ngOnChanges(changes) {
    this.count = changes.videos?.currentValue.length;
    this.heading = this.count > 0
      ?  this.count + ' ' + (this.count > 1 ? 'Videos' : 'Video')
      :  this.emptyHeading;
  }
}

Honestly? This sucks. Compare it to how clean the previous React examples were. I don't want to touch Lifecycle methods. I don't care. I want to declare derived values: I want to write a recipe.

With classes, we can take advantage of getters in order to declare derived states.

class VideoListComponent {

  @Input() videos = [];
  @Input() emptyHeading = '';

  get count() {
    return this.videos.length;
  }

  get heading() {
    if (this.count > 0) {
      const noun = this.count > 1 ? 'Videos' : 'Video';
      return this.count + ' ' + noun;
    }
    return this.emptyHeading;
  }
}

Much simpler to read and to reason about. That's what I suggest in such simple use-cases.

Notice that, since the getter is a function, it's easy to use intermediate variables (noun) and some sparkles of imperative code (which is self-contained and not scattered around the whole component).

Of course, it's a bit verbose to write. And we have to ask ourselves: will the framework pick up the changes? We are relying on Change Detection for those getters to work, and they could be fired potentially many times because there's no real way to know that a mutable property has changed.

That's about to end once we get Signals.

Signals

class VideoListComponent {

  // I think this is what we'll end up with, reactive
  // inputs as signals with default values, or something like that!
  videos = input([]);
  emptyHeading = input('');

  count = computed(() => this.videos().length);

  heading = computed(() => {
    if (this.count() > 0) {
      const noun = this.count() > 1 ? 'Videos' : 'Video';
      return this.count() + ' ' + noun;
    }
    return this.emptyHeading();
  });
}

This is still more code than the function-based alternatives. Not much really. But:

It's very explicit
It's declarative

Also:

It's performant by default (as any other Signal implementation really), which I think is the future of any framework. I'm not a fan of the mindset of "optimize it later, if you need it", because in large applications I may not realize how expensive a specific computation will be in 3 months from now with a lot more code. And it'll be difficult to come back to the incriminated code.
We won't need zone.js anymore (phew)

These are all great benefits to me.

Signals have many flavors, one for each framework using them. Compare it to Solid's approach:

// Solid
function VideoList(props) {
  const count = () => props.videos.length;
  const heading = () => {
    if (count() > 0) {
      const noun = count() > 1 ? "Videos" : "Video";
      return count() + " " + noun;
    }
    return props.emptyHeading;
  }
  return <h1>{heading()}</h1>
}

My opinion is that this approach is also great. But it has some small caveats.

Why are there arrow functions everywhere? We have to know that in Solid, in order to make a variable reactive, it must be a function. But this is a bit difficult to districate at first sight.
When I see a function, I don't know if it's a reactive derived state or an event handler. They look the same, so I have to read the code to know what it does (or, hope that the variable has a great name!).

It's important to note that this is just an opinion and you may like Solid's code more than anything else! It's a great tool.

So why do I like Angular with Signals? And why do I like working with classes this way?

Because with Angular's signals, we are forced to communicate that a value is a derived state. And we'll be forced to say that an input should be treated as a signal (if we want it to be!). And writing imperative code, such as the very first example of this article, is pretty much discouraged by the nature of classes in a reactive context. If your code looks bad, you're probably going to hate it, maybe tomorrow, maybe in 3 months.

With React, we have the possibility (which, however, I don't want) to write imperative code. We have a nice and short syntax. But we don't have fine-grained reactivity and Hooks have rules (I think it's fair to say that React's mental model is great until you add hooks, and they're used a lot).

With Solid, we usually deal with a lot of anonymous functions, and handling props can be quite strange (they're reactive, but we get them as normal values, destructuring is strange).

With Angular, we have a clear syntax and we're pushed towards declarative code. The tax to pay is a bit more code than the alternatives.

My opinion has been the same for many years: less code is not always objectively better. Classes can be easily understood by any high-school student who has learned OOP. They're easy to reason about if we do it right. So do it right :)

Many people criticize classes. They have some good reasons to do so. So how come that I appreciate them even if I love functional programming?

If we use classes with a bit of FP mindset (immutability, properties are constants), a lot of their cons disappear.

I'm happy that I won't ever need an ngOnChanges again. Or some input-setters to set some BehaviorSubjects values!

PS. Please, don't take this as a critique on React or Solid.

AccademiaDev: text-based web development courses!

Photo by Tsvetoslav Hristov on Unsplash

DEV Community: Michele Stieven

Recreating LinkedIn’s Crossclimb Game with Angular - Part 3

The Hint component

The Container

Showing the edge words

The middle words

Where to go from here

Recreating LinkedIn’s Crossclimb Game with Angular - Part 2

The models

The service

The derived states

Recreating LinkedIn’s Crossclimb Game with Angular - Part 1

How the game works

The Word component

The template

Handling the keydown event

The Icon component

Next steps

Angular Authentication with Cookies in 10 minutes

AccademiaDev: text-based web development courses!

Before we begin: the server

Step 1: Getting the CSRF Token

Step 2: Sending the Cookie in localhost

Step 3: Creating a service

Step 4: Detect an expired cookie

Step 5: Guard your pages!

Use it!

Bonus: SSR Quirks

Angular LAB: Preserving Component State Across Route Transitions

The First Challenge

The Second Challenge: Losing DOM State

RouteReuseStrategy: what does it do?

Creating a Custom Reuse Strategy

Defining Route Reuse Behavior

A couple of helpers

Implementing RouteReuseStrategy

Convenience methods for purging the cache

Conclusion

AccademiaDev: text-based web development courses!

Angular's inject function: a couple of years later...

Easier inheritance

Avoiding Parameter Decorators

Classes lose their "purity"

Scattered dependencies

Hidden dependencies

What is an Injection Context?

Minor causes of frustration I've seen on the web

Takeaways

AccademiaDev: text-based web development courses!

Angular LAB: animating lists and using AnimationBuilder for imperative animations

Creating a list

Animating the list

AnimationBuilder

AccademiaDev: text-based web development courses!

Angular LAB: let's create a Visibility Directive

What we want to achieve

Creation of the Directive

IntersectionObserver

Final code

AccademiaDev: text-based web development courses!

How I structure my Angular components with Signals

Subjects

Effects

Going full Reactive is not always a good idea

Conclusion

AccademiaDev: text-based web development courses!

Angular - Error Handling 101

HTTP errors

retry

timeout

catchError

Subscribe

Services

Interceptors

Store

ErrorHandler

Conclusions

AccademiaDev: text-based web development courses!

Why I like Signals in Angular and the importance of Declarative code

Functional is Declarative

The `Hint` component

The `Word` component

Handling the `keydown` event

The `Icon` component

Step 2: Sending the Cookie in `localhost`

Implementing `RouteReuseStrategy`