Forem: Soumaya Erradi

Angular HTTP Interceptors: A modern guide

Soumaya Erradi — Thu, 19 Mar 2026 12:32:23 +0000

Angular's HttpClient is powerful, but when you're building a real-world application, you quickly find yourself repeating tasks for every API call: attaching JWT tokens, handling server errors, implementing global loading indicators, or logging performance.

This is where HTTP Interceptors shine. They allow you to define middleware logic that intercepts and modifies outgoing requests and incoming responses.

In recent versions of Angular, the landscape changed dramatically. Class-based interceptors, which rely on dependency injection and boilerplate interfaces, were superseded by Functional Interceptors.

This article is a deep dive into functional interceptors, focused on modern best practices, packed with code snippets and real-world patterns.

1. The core concept: The "toll booth" analogy

Think of an HTTP Interceptor as a toll booth on a highway.

When your application components make a request (HttpClient.get()), the "car" (the request) must pass through the booth. The attendant can:

inspect the car,
modify it (add a "paid" sticker/header),
or turn it back (if unauthorized).

When the server sends a response back, the car returns through the same toll booth, allowing the attendant to handle errors or log travel time before the car reaches the user.

2. Defining a Functional Interceptor: `HttpInterceptorFn`

In modern Angular, an interceptor is a pure function that adheres to the HttpInterceptorFn type signature.

Let’s define a minimal, boilerplate example:

import { HttpInterceptorFn, HttpRequest, HttpHandlerFn, HttpEvent } from '@angular/common/http';
import { Observable } from 'rxjs';

export const minimalInterceptor: HttpInterceptorFn = (
  req: HttpRequest<unknown>,
  next: HttpHandlerFn
): Observable<HttpEvent<unknown>> => {

  // 1. You receive the request 'req'
  console.log('Request outgoing:', req.url);

  // 2. You pass it to the 'next' handler
  return next(req); 
};

Key players:

HttpRequest: The incoming request object. Note that requests are immutable.
HttpHandlerFn: A function that represents the next interceptor in the chain, or the final backend handler if there are no more interceptors. Calling next(req) passes the request forward.
The Return Value: It must return an Observable<HttpEvent<any>>.

3. Immutability & Cloning: The modifying rule

Because HttpRequest objects are immutable, you cannot do this:

// ❌ WRONG: Requests are immutable
req.url = 'https://new-api.com' + req.url;

Instead, you must clone the request and apply changes during the cloning process. Angular optimizes this process.

// ✅ CORRECT: Clone and Modify
const modifiedReq = req.clone({
  url: `https://api.my-app.com${req.url}`,
  setHeaders: {
    'Content-Type': 'application/json'
  }
});
return next(modifiedReq);

4. Registering your Interceptors (Dependency Injection)

Interceptors are not registered via @Injectable(). They are provided where you configure your HttpClient. In modern applications, this is typically in app.config.ts.

You must use the provideHttpClient() function and its optional withInterceptors([]) helper.

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideHttpClient, withInterceptors } from '@angular/common/http';
import { minimalInterceptor } from './interceptors/minimal.interceptor';

export const appConfig: ApplicationConfig = {
  providers: [
    // Provide HttpClient with a list of active functional interceptors
    provideHttpClient(
      withInterceptors([
        minimalInterceptor, 
        // nextInterceptor,
        // errorInterceptor
      ])
    )
  ]
};

Crucial note on order: The order matters. Interceptors run sequentially in the order they are listed in the array: Minimal -> Next -> Error. For responses, the order is reversed.

5. Real-world power moves: 4 advanced patterns

Let’s look at practical implementations you’ll likely need in production.

Pattern A: The Authentication Header (JWT) Interceptor

The most common use case. Attach a bearer token if the user is authenticated.

Because functional interceptors run inside the injection context, you can inject services directly.

import { HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';
import { AuthService } from './services/auth.service';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  // 1. Inject the AuthService to get the token
  const authService = inject(AuthService);
  const authToken = authService.getToken();

  // 2. If no token, just forward the original request
  if (!authToken) {
    return next(req);
  }

  // 3. Clone and add the Authorization header
  const authReq = req.clone({
    setHeaders: {
      Authorization: `Bearer ${authToken}`
    }
  });

  return next(authReq);
};

Pattern B: Global Error Handling with RxJS

Don't use try/catch blocks in every component. Use the interceptor to catch HTTP errors globally, handles 401s, and shows friendly messages to the user.

We tap into the response stream using pipe().

import { HttpInterceptorFn, HttpErrorResponse } from '@angular/common/http';
import { tap, catchError } from 'rxjs/operators';
import { throwError } from 'rxjs';
import { inject } from '@angular/core';
import { NotificationService } from './services/notification.service';
import { Router } from '@angular/router';

export const errorInterceptor: HttpInterceptorFn = (req, next) => {
  const notifier = inject(NotificationService);
  const router = inject(Router);

  return next(req).pipe(
    // tap() allows us to inspect SUCCESSFUL responses/events
    tap({
      next: (event) => {
        // You could check status codes here if needed (e.g., 201 Created)
      }
    }),

    // catchError() handles FAILED responses
    catchError((error: HttpErrorResponse) => {
      let errorMessage = 'An unknown error occurred.';

      if (error.error instanceof ErrorEvent) {
        // Client-side error (e.g., network issue)
        errorMessage = `Client Error: ${error.error.message}`;
      } else {
        // Server-side error
        switch (error.status) {
          case 401: // Unauthorized
            errorMessage = 'Your session has expired. Please log in again.';
            // Handle auto-logout or token refresh logic here
            router.navigate(['/login']);
            break;
          case 403: // Forbidden
            errorMessage = 'You do not have permission to access this resource.';
            break;
          case 404: // Not Found
            errorMessage = 'The requested resource was not found.';
            break;
          case 500: // Internal Server Error
            errorMessage = 'The server encountered an error. Please try again later.';
            break;
        }
      }

      // Show the notification to the user
      notifier.showError(errorMessage);

      // We MUST re-throw the error so the calling component knows it failed
      return throwError(() => error);
    })
  );
};

Pattern C: Performance logging

Let’s measure how long our API requests take. We record the start time when the request is sent and the end time when the final response event is received.

import { HttpInterceptorFn, HttpResponse } from '@angular/common/http';
import { tap, finalize } from 'rxjs/operators';

export const loggingInterceptor: HttpInterceptorFn = (req, next) => {
  const startTime = Date.now();
  let status: string;

  return next(req).pipe(
    // Monitor events
    tap({
      next: (event) => {
        if (event instanceof HttpResponse) {
          status = 'succeeded';
        }
      },
      error: (error) => {
        status = 'failed';
      }
    }),
    // finalize runs when the observable completes or errors
    finalize(() => {
      const elapsedTime = Date.now() - startTime;
      const message = `${req.method} "${req.urlWithParams}" ${status} in ${elapsedTime}ms.`;

      // We use console.info here to separate it from app logs
      console.info(message);
    })
  );
};

Pattern D: A modern loading spinner

A global spinner that shows whenever any API call is pending. We use an interceptor to increment a counter in a service, and finalize to decrement it, even if the request fails.

// 1. The Loading Service
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class LoadingService {
  // Using Angular Signals for efficient reactivity
  private activeRequests = signal<number>(0);
  readonly isLoading = signal<boolean>(false);

  show() {
    this.activeRequests.update(count => count + 1);
    this.isLoading.set(true);
  }

  hide() {
    this.activeRequests.update(count => Math.max(0, count - 1));
    if (this.activeRequests() === 0) {
      this.isLoading.set(false);
    }
  }
}

// 2. The Interceptor
import { HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';
import { finalize } from 'rxjs/operators';
import { LoadingService } from './loading.service';

export const loadingInterceptor: HttpInterceptorFn = (req, next) => {
  const loadingService = inject(LoadingService);

  // Start the spinner
  loadingService.show();

  return next(req).pipe(
    // Always hide the spinner when the request stream completes (success or error)
    finalize(() => {
      loadingService.hide();
    })
  );
};

Summary of Best Practices

Prefer Functional Interceptors: Do not write class-based interceptors (implements HttpInterceptor) for new code. They are verbose and less composable.
Order matters: Remember that your registered array ([auth, error, logging]) dictates the execution order.
Clone, don't modify: Always use req.clone() when changing a request.
Handle errors in the chain: Use RxJS operators like catchError and tap within the interceptor to handle global failure logic. Do not handle error UI inside your components unless it is highly specific.
Always rethrow errors: If you catch an error in an interceptor, you must use throwError at the end to pass the error down the chain. Otherwise, your component’s .subscribe(..., error => {}) block will never fire.
Avoid bloat: Interceptors should be lean. If your logging logic gets complicated, move it into a dedicated LoggingService and inject that service into the interceptor.

Functional Interceptors are a perfect example of how Angular is modernizing: removing boilerplate, embracing functional programming patterns, and optimizing performance. When used correctly, they are the key to a clean, scalable, and resilient application architecture.

Conclusion

Angular’s shift toward Functional Interceptors is more than just a syntax change; it’s a move toward more composable, readable, and tree-shakable code. By moving cross-cutting concerns like authentication, error handling, and loading states into interceptors, you keep your components focused on what they do best: managing the UI.

As you implement these in your own projects, remember:

Keep them single-purpose: It’s better to have four small interceptors than one giant "God-interceptor."
Mind the order: Your provideHttpClient array is your execution pipeline.
Embrace Signals: Combine interceptors with Angular Signals (like in our Loading Spinner example) for a truly modern, reactive experience.

What are you using interceptors for in your current project?

Signal Forms in Angular 21

Soumaya Erradi — Thu, 12 Feb 2026 08:02:56 +0000

For years, Angular forms have meant one thing: FormGroup, FormControl, valueChanges, and a tree of AbstractControls that we learn to navigate almost mechanically.

And if you’ve been working with Angular for many years, you probably feel very comfortable there.

But Angular 21 introduces something that isn’t just a new API.

It’s a different mental model.

Signal Forms are not an evolution of Reactive Forms.
They’re a re-alignment of forms with Angular’s new reactive core.

And once you really use them in a non-trivial scenario, you realize something:

Forms stop feeling like a framework feature.
They start feeling like state.

Let me show you what I mean.

A real checkout Form

Instead of the classic “login form” example, let’s build something closer to production reality: a checkout form with nested objects, conditional payment logic, and cross-field validation.

We start from the only thing that really matters: the model.

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

export interface CheckoutModel {
  customer: {
    firstName: string;
    lastName: string;
    email: string;
  };
  shipping: {
    street: string;
    city: string;
    zip: string;
    country: string;
  };
  billingSameAsShipping: boolean;
  billing: {
    street: string;
    city: string;
    zip: string;
    country: string;
  };
  payment: {
    method: 'card' | 'paypal';
    cardNumber: string;
    expiry: string;
    cvv: string;
  };
  acceptTerms: boolean;
}

checkoutModel = signal<CheckoutModel>({
  customer: {
    firstName: '',
    lastName: '',
    email: ''
  },
  shipping: {
    street: '',
    city: '',
    zip: '',
    country: ''
  },
  billingSameAsShipping: true,
  billing: {
    street: '',
    city: '',
    zip: '',
    country: ''
  },
  payment: {
    method: 'card',
    cardNumber: '',
    expiry: '',
    cvv: ''
  },
  acceptTerms: false
});

This is the part that I really like.

The form is not a control tree. It is a typed signal.

That means:

It is the single source of truth.
It integrates with computed.
It integrates with effect.
It integrates with zoneless Angular naturally.

There is no secondary abstraction layer.

Creating the Form

Signal Forms generate a FieldTree that mirrors your model.

import { form, required, email, validate } from '@angular/forms/signals';

checkoutForm = form(this.checkoutModel, (path) => {

  required(path.customer.firstName);
  required(path.customer.lastName);
  required(path.customer.email);
  email(path.customer.email);

  required(path.shipping.street);
  required(path.shipping.city);
  required(path.shipping.zip);
  required(path.shipping.country);

  required(path.acceptTerms);

});

This schema function is extremely important.

It forces validation to stay close to the data structure.

Not close to a UI. Not buried inside components. Not hidden inside abstract classes.

Validation is declared against the model shape.

That’s architectural clarity.

Nested binding feels natural

The template doesn’t need formGroupName, formControlName, or any structural directives.

<input [formField]="checkoutForm.customer.firstName" />
<input [formField]="checkoutForm.customer.lastName" />
<input [formField]="checkoutForm.customer.email" />

<input [formField]="checkoutForm.shipping.street" />
<input [formField]="checkoutForm.shipping.city" />

You don’t “get” nested groups.

You don’t navigate an AbstractControl tree.

The structure already exists because it mirrors your signal model.

This feels closer to plain TypeScript than to framework configuration.

Conditional logic without fighting the API

Now let’s make the payment method dynamic.

<select [formField]="checkoutForm.payment.method">
  <option value="card">Card</option>
  <option value="paypal">PayPal</option>
</select>

Then conditionally render card details:

@if (checkoutForm.payment.method().value() === 'card') {
  <input [formField]="checkoutForm.payment.cardNumber" />
  <input [formField]="checkoutForm.payment.expiry" />
  <input [formField]="checkoutForm.payment.cvv" />
}

No subscriptions. No valueChanges. No async pipes.

The UI reacts because Signals react.

This is where you start feeling the architectural consistency Angular has been moving toward since Signals were introduced.

Cross-field validation becomes boring (In a good way)

One of the painful parts of Reactive Forms has always been cross-field validation.

You end up writing form-level validators that inspect sibling controls and return error maps.

With Signal Forms, the model is already a signal. You can just read it.

Let’s validate the card number only if the method is card.

validate(path.payment.cardNumber, ({ value }) => {
  const model = this.checkoutModel();

  if (model.payment.method !== 'card') {
    return null;
  }

  return value().length < 16
    ? { kind: 'invalidCard', message: 'Card number must be 16 digits' }
    : null;
});

There is no special form-level abstraction.

You simply express domain logic.

And that’s the key difference:

This feels like business logic. Not framework logic.

Derived state is first-class

Because your form is just a signal, computed becomes a natural extension.

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

orderSummary = computed(() => {
  const { customer, shipping } = this.checkoutModel();

  return {
    fullName: `${customer.firstName} ${customer.lastName}`,
    destination: `${shipping.city}, ${shipping.country}`
  };
});

There’s no need to listen to form changes.

There is no concept of valueChanges.

The model changes. The computed recalculates. The template updates.

The reactivity is consistent everywhere in your app.

Synchronizing fields without patching controls

A common requirement: billing address equals shipping address.

In Reactive Forms, you would patch values manually and carefully avoid circular updates.

With Signals, this becomes trivial:

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

constructor() {
  effect(() => {
    const model = this.checkoutModel();

    if (model.billingSameAsShipping) {
      this.checkoutModel.update(current => ({
        ...current,
        billing: { ...current.shipping }
      }));
    }
  });
}

You are not “patching controls”.

You are updating state.

That distinction changes how you reason about the system.

Field state is still there — Just reactive

Each field exposes reactive state:

checkoutForm.customer.email().valid();
checkoutForm.customer.email().invalid();
checkoutForm.customer.email().touched();
checkoutForm.customer.email().errors();

In the template:

@if (checkoutForm.customer.email().invalid() &&
     checkoutForm.customer.email().touched()) {
  @for (error of checkoutForm.customer.email().errors(); track error) {
    <p>{{ error.message }}</p>
  }
}

The difference is that this state is signal-based, not imperative.

You don’t ask the form to recompute. You don’t trigger change detection.

It just reacts.

Why this feels different

The biggest change is not syntax.

It’s conceptual.

Reactive Forms introduced a parallel abstraction:

A control tree
A validation system
A state system
An event system

Signal Forms collapse all of that into:

Reactive state + schema validation.

If you’re already using:

Signals
Computed
Effects
Zoneless Angular

Then Signal Forms feel coherent.

And that coherence is important in large codebases.

Is this ready for Production?

Signal Forms in Angular 21 are still experimental.

I wouldn’t rewrite a massive enterprise app tomorrow.

But for greenfield Angular 21 projects?

I would absolutely start with this.

Especially if:

You’re already signal-first
You’re avoiding heavy RxJS form logic
You want simpler mental models
You care about fine-grained reactivity

The API is small. The concepts are consistent. The typing is strong.

And the mental overhead is lower.

My honest take

For years, Angular forms felt powerful but heavy.

Signal Forms feel lighter. More aligned with modern Angular. More explicit. Less magical.

They encourage you to model your domain properly instead of wiring control trees.

And if you’ve ever had to debug a deeply nested Reactive Form with dynamic validators, you’ll immediately understand the difference.

This isn’t just a new forms API.

It’s Angular finishing the shift it started when Signals were introduced.

Forms are no longer a special subsystem.

They’re just reactive state.

And I genuinely think that’s the right direction.

Angular’s Resource API: Making async state human again

Soumaya Erradi — Sun, 18 Jan 2026 08:42:27 +0000

Every Angular developer has lived this moment.

You fetch data.
You handle loading.
You handle errors.
You add reload logic.

And suddenly your component is 100 lines long.

Not because the feature is complex, but because async state is.

Angular’s Resource API is a signal-first solution to a problem we’ve been solving manually for years.

It doesn’t replace RxJS. It doesn’t hide async.

It makes async state behave like a signal.

The pain of async state in Angular

Before signals, async code in Angular usually meant:

HttpClient returning Observables
the async pipe in templates
manual flags like isLoading, hasError, isComplete
Subjects to trigger reloads
takeUntil(destroy$) to avoid memory leaks

Even with the async pipe, most components still had to juggle three states:

Loading – we’re waiting for data
Success – we have data
Error - something went wrong

A very typical template looked like this:

<div *ngIf="data$ | async as data; else loading">
  <ng-container *ngIf="!error; else errorBlock">
    {{ data.name }}
  </ng-container>
</div>

<ng-template #loading>Loading…</ng-template>
<ng-template #errorBlock>Error loading data</ng-template>

It works but it’s verbose, repetitive and fragile.
Every new async operation adds more flags and more mental overhead.

What if async behaved like a signal?

Signals changed how we write synchronous state in Angular:

reactive by default
automatically tracked
declarative
no subscriptions

At some point, the obvious question emerged:

What if async code behaved like computed()?

The Resource API is Angular’s answer.

What is the Resource API?

The Resource API is a signal-first abstraction for async state.

You define:

reactive parameters
a loader function that returns a Promise or an Observable

Angular gives you:

a single reactive resource
built-in loading and error tracking
automatic cancellation
automatic teardown
dependency tracking on signals

No subscribe().
No async pipe.
No manual flags.

Your first resource

Here’s the simplest example using the official API shape:

import { Component, signal, resource } from '@angular/core';

@Component({
  selector: 'app-user',
  template: `...`
})
export class UserComponent {
  userId = signal(1);

  user = resource({
    params: () => this.userId(),
    loader: ({ params }) =>
      fetch(`/api/users/${params}`).then(r => r.json())
  });
}

user is now one reactive unit that represents:

the current value
whether it’s loading
whether it failed

Using a resource in the template

Resources expose signal helpers instead of forcing you to manage flags manually.

@if (user.isLoading()) {
  <p>Loading…</p>
}
@else if (user.error()) {
  <p>{{ user.error()?.message }}</p>
}
@else {
  <h2>{{ user.value().name }}</h2>
}

Important:
value() throws if the resource isn’t ready.
Always check isLoading() or error() first.

Reactive dependencies: the core idea

Resources automatically track signals used inside params().

userId = signal(1);

user = resource({
  params: () => this.userId(),
  loader: ({ params }) =>
    this.http.get(`/api/users/${params}`)
});

When userId changes:

the resource invalidates
the loader re-runs
the UI updates automatically

No switchMap.
No Subjects.
No wiring code.

This is the key mental shift:

The resource reacts to signal changes, not events.

Reloading data manually

Sometimes you want an explicit refresh.

<button (click)="user.reload()">Reload</button>

That’s it.

The resource automatically transitions through a loading state again.

The three flavors of Resource

Angular provides three helpers for different use cases.

`resource()` – the general-purpose tool

Use it when:

you want full control
you return a Promise or Observable
the async logic isn’t HTTP-specific

todos = resource({
  loader: () => this.http.get('/api/todos')
});

`httpResource()` – HTTP without boilerplate

httpResource() is a specialized helper built on top of resource():

unwraps the HTTP response
handles HttpErrorResponse
integrates cleanly with HttpClient

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

user = httpResource(() =>
  this.http.get<User>('/api/user')
);

Same mental model, fewer lines.

`rxResource()` – real-time streams

For data that emits multiple values over time:

WebSockets
Server-Sent Events
live prices
sensor data

import { rxResource } from '@angular/core/rxjs-interop';

updates = rxResource(() =>
  new EventSource('/api/events')
);

The resource value updates whenever the stream emits.
Connection and teardown are handled automatically.

Before vs After: a real comparison

Before (classic RxJS setup)

private destroy$ = new Subject<void>();
private reload$ = new Subject<void>();

category$ = new BehaviorSubject('all');
isLoading = false;

products$ = this.category$.pipe(
  switchMap(cat => {
    this.isLoading = true;
    return this.http.get(`/api/products?cat=${cat}`).pipe(
      finalize(() => this.isLoading = false)
    );
  }),
  takeUntil(this.destroy$)
);

After (Resource API)

category = signal('all');

products = httpResource(() => {
  const cat = this.category();
  return this.http.get(`/api/products?cat=${cat}`);
});

One resource.
No flags.
No Subjects.
No teardown logic.

Common gotchas

Reading signals outside `params()`

const id = this.userId();

user = resource({
  params: () => id, // not reactive
  loader: ({ params }) => ...
});

Always read signals inside params().

Accessing `value()` too early

@if (user.isLoading()) {
  {{ user.value() }} <!-- will throw -->
}

Always guard access to value().

Does this replace RxJS?

No, and it shouldn’t.

RxJS is excellent for streams and orchestration
Resource is excellent for async state

A good rule of thumb:

RxJS for flows
Resource for state

They work best together.

Where should a resource live?

In a component Perfect for local, view-specific async state
In a service Great for shared or global state. Resources are signals, so they’re injectable and composable.

Final thoughts

The Resource API doesn’t kill RxJS.

It removes the noise:

fewer pipes
fewer flags
built-in loading and error handling
signal-native async logic

Async state becomes predictable, reactive and boring and that’s a compliment.

If you’re already using signals, the Resource API is the missing piece.

Async, finally made human.

My Second Semester of 2025

Soumaya Erradi — Mon, 29 Dec 2025 07:54:53 +0000

Conferences, people, and places that stayed with me

The second semester is always intense in a different way.
More travel, more conversations, and a clearer sense of why I keep doing this.

From September to December, I moved across Italy and beyond, joining communities that welcomed me with open arms, listening to stories, sharing knowledge, and sometimes just having fun together. Here’s what each stop left me with.

DevFest Lecce — Lecce, Italy - September 12

This was the very first DevFest for the GDG Lecce community, and you could feel it.
So much energy, so many motivated people, and a genuine excitement around building something together. It was a beautiful start to the semester and a reminder of how powerful new communities can be when they’re driven by passion.

Come to Code — Pignola, Italy - September 27–28

Come to Code is one of my favourite places to be.
Pignola feels less like a conference destination and more like a family reunion. I met so many friends, laughed a lot, and had an incredible time. I left those days with my heart full — and honestly, that feeling lasts long after the event ends.

DevFest Modena — Modena, Italy - October 4–5

A short stop in Modena for their DevFest, but a very intense one.
A successful event, packed with great content and familiar faces from all over Italy. It’s always special to see how strong and connected the Italian tech community really is.

Frontmania — Utrecht, The Netherlands - October 8

Back in the Netherlands, one of my favourite countries in the world.
Frontmania never disappoints. My workshop room was full, the questions kept coming, and I had the chance to meet both new people and old friends. Events like this remind me why I love teaching and sharing knowledge in person.

INIT Conference — Banja Luka, Bosnia and Herzegovina - October 10–11

My first time in Bosnia, and what a welcome.
INIT Conference in Banja Luka was a lovely experience: warm people, great care from the organizers, and that feeling of being looked after from the moment I landed until I left. I really love events like this, where hospitality is as important as content.

Codemotion Milan — Milano, Italy - October 14–15

Codemotion Milan is the biggest conference in Italy, and it always feels special.
It’s an opportunity to finally meet in person friends I usually see abroad, catch up, and plan new ideas together. During my talk, I gave away an Arduino, and the competition around it was so much fun, one of those moments that make conferences memorable.

DevFest Roma — Roma, Italy - October 25

Organized by my friends from GDG Roma Città, this was their very first DevFest, and they did an amazing job.
It was a different kind of trip to Rome, a beautiful excuse to spend time with people I deeply care about. Being there during a hard moment in my life, surrounded by such supportive people, meant more than I can easily put into words.

Cursor Meetup — Casablanca, Morocco - November 1

This was the most unexpected event of the semester.
Nothing was planned, yet I found myself surrounded by one of the strongest communities I’ve ever met. The Moroccan tech community is young, motivated, and incredibly engaged. In small events like this, you really feel the energy and participation.

Devoxx Morocco — Marrakech, Morocco - November 12–15

Back to Marrakech, spending a full week immersed in the Moroccan community.
The warmth wasn’t just in the weather, but in the people. Everything about this trip made it feel truly worth it, from the conversations to the atmosphere of the city. Definitely one of my go-to events of the year.

Wey Wey Web — Malaga, Spain - November 17–18

Back to Malaga, but in a very different season.
Talking about Angular at a frontend conference with such a diverse audience was refreshing. I met people from all over Europe, and seeing so many Italians there made it feel even more special.

JS Poland — Warsaw, Poland - November 19

Back on the biggest stage I’ve ever spoken on.
This time, it felt familiar. The warmth of the people made me truly enjoy talking about one of my biggest passions: electronics. So many questions, so many Angular friends, it really felt like a reunion.

AngularDay — Verona, Italy - November 21

My local Angular conference, and one I care deeply about.
Being back on stage in Italy, so close to home, always feels special. Verona hosts one of my favourite events, and it’s a place I’ll always be present at.

DevFest Bari — Bari, Italy - November 30

The last conference of November took me to Bari.
One of the most successful DevFests in Italy: big, vibrant, and full of people I’m really close to. I loved being back in the south of Italy, enjoying great food while talking about tech with friends.

Angular.love Meetup — Warsaw, Poland - December 11

The final stop of 2025, and the last trip of the year.
Warsaw welcomed me warmly, thanks to the Angular.love community. Closing such an intense and meaningful year by talking about Angular felt like the perfect ending.

Closing thoughts

This second semester wasn’t about quantity or speed.
It was about people, trust, and feeling part of something bigger wherever I went.

Looking back at 2025, the numbers tell part of the story: 44 flights, 23 trains, 25 cities, 12 countries.

If we met at any of these events, thank you.
You made this journey what it was.

How to write a talk proposal that actually gets accepted

Soumaya Erradi — Mon, 15 Dec 2025 18:35:33 +0000

If you’ve ever submitted a talk proposal and wondered “Why wasn’t this accepted?”, this article is for you.

I’m part of several conference program committees, and over the years I’ve read hundreds of submissions. I’ve also been on the other side, submitting talks myself and dealing with rejections, rewrites, and iterations.

Recently, there’s one pattern I keep seeing more and more, and it’s making the selection process harder than it should be.

The problem: proposals that feel polished, but empty

Many submissions today are technically well written.

The grammar is perfect.

The structure is clean.

The buzzwords are all there.

And yet… they say nothing.

Titles and abstracts that feel heavily AI-generated often lack the one thing that actually helps a program committee make a decision: a clear, personal point of view.

When I read those proposals, I struggle to understand:

what the talk will really be about
how it will be delivered
and why this specific person should be the one giving it

Without that, it’s almost impossible to confidently put the talk on stage.

A talk proposal is not a documentation page

This is probably the most common misconception.

A talk proposal is not:

a neutral description of a topic
a mini Wikipedia page
a list of concepts you’re going to cover

A talk proposal is a promise.

It’s the first signal of how you think, how you communicate, and what attendees will experience if they choose your session over dozens of others.

Before your talk reaches the audience, it has to convince:

the program committee
the attendees scanning the agenda

Both groups are looking for clarity, relevance, and authenticity.

Using AI is not the problem, outsourcing your voice is

Let me be very clear:

this is not an anti-AI message.

AI can be a great tool to:

clean up language
improve structure
help you iterate faster

The problem starts when AI replaces your thinking instead of supporting it.

If I remove your name from the proposal and it could have been written by anyone, that’s a red flag.

Your proposal should answer one simple question:

Why do you care about this topic?

If that answer isn’t visible, the proposal feels generic even if it’s technically correct.

What I personally look for when reviewing a proposal

Every program committee is different, but these are the things that immediately catch my attention.

1. A clear angle

Not just what the topic is, but from which perspective you’re approaching it.

Is it based on real-world experience?
Is it a lesson learned the hard way?
Is it a comparison, a failure story, a migration journey?

I don’t need the full outline, I need to understand the lens.

2. Evidence of experience (not expertise)

You don’t need to be “the world expert”.

I care much more about:

what you’ve actually tried
what went wrong
what surprised you
what you’d do differently today

Concrete experience beats abstract authority every time.

3. Honest scope

Overpromising is very common.

If an abstract claims it will:

cover fundamentals
advanced patterns
internals
performance
live demos all in 30–40 minutes… that’s a warning sign.

A focused talk is far more attractive than an overly ambitious one.

4. A human tone

I don’t expect perfection.

I do expect sincerity.

Proposals that sound like marketing copy or technical documentation are harder to trust than ones that feel written by a real person who genuinely wants to share something.

Common mistakes I see again and again

Here are a few patterns that often lead to rejection:

Titles full of buzzwords, but no substance
Abstracts that list technologies instead of ideas
Generic phrases like “we will explore”, “we will deep dive”, “you will learn everything about…” with no specifics
No indication of why this talk exists
No sense of who the talk is for

None of these are fatal on their own but combined, they make it very hard to say yes.

A simple exercise to add a personal touch

Before writing (or rewriting) your proposal, answer these questions for yourself, not for the CFP form:

Why did this topic matter to me personally?
What problem or confusion led me here?
What do I wish someone had told me earlier?
What’s one opinion or lesson I’m confident about?

Then rewrite your abstract starting from those answers.

You can still use AI afterwards, just don’t erase the core.

Final thought

Conferences don’t need more perfectly formatted proposals.

They need clear voices, real experiences, and honest stories.

If your proposal reflects how you actually think and care about a topic, it will already stand out even before the talk is delivered.

If you’re new to speaking, struggling with rejections, or unsure how to improve your submissions: you’re not alone. And this is a skill you can learn.

If this article helps even one person get their first “accepted” email, it’s already done its job.

Discriminated Unions in TypeScript explained simply

Soumaya Erradi — Sat, 20 Sep 2025 11:19:58 +0000

The idea

Many apps track “where we are” with loose flags:

let isLoading = false;
let data: User | null = null;
let error: string | null = null;

This creates tricky situations: what if isLoading is true and error is also set? Which one is real?

Discriminated unions fix this by saying: “the app is in exactly one state at a time, and each state carries only the data it needs.”

type FetchState<T> =
  | { kind: 'idle' }
  | { kind: 'loading' }
  | { kind: 'success'; data: T }
  | { kind: 'error'; message: string };

The shared field (kind) is the discriminant.
The other fields belong only to that single state.

Now impossible combos (loading + error + data) simply can’t exist.

Why this helps

Clarity: You read kind and instantly know what’s happening.
Safety: TypeScript narrows types for you. In 'success', data is guaranteed to exist.
Guidance: If you add a new state later, the compiler shows every place you must update.

How to use it

1) Define the states

Pick a single property name for the tag. Common choices: kind or type.

type AuthState =
  | { kind: 'loggedOut' }
  | { kind: 'loggingIn' }
  | { kind: 'loggedIn'; user: { id: string; name: string } }
  | { kind: 'loginFailed'; message: string };

2) Write code that switches on the tag

function renderAuth(s: AuthState): string {
  switch (s.kind) {
    case 'loggedOut':  return 'Please log in';
    case 'loggingIn':  return 'Logging in…';
    case 'loggedIn':   return `Welcome, ${s.user.name}`;
    case 'loginFailed':return `Oops: ${s.message}`;
    // add this to catch missing cases:
    default: return assertNever(s);
  }
}

function assertNever(x: never): never {
  throw new Error('Unhandled state: ' + JSON.stringify(x));
}

TypeScript now narrows the type inside each case:

In 'loggedIn', s.user is available (no ?).
In 'loginFailed', s.message is available.

3) Update state with small functions

function startLogin(_s: AuthState): AuthState {
  return { kind: 'loggingIn' };
}

function loginOk(_s: AuthState, user: { id: string; name: string }): AuthState {
  return { kind: 'loggedIn', user };
}

function loginFail(_s: AuthState, message: string): AuthState {
  return { kind: 'loginFailed', message };
}

Keep these functions pure (no network calls inside). They’re easy to test.

Common everyday patterns

A) Async fetch without `isLoading`

type FetchState<T> =
  | { kind: 'idle' }
  | { kind: 'loading' }
  | { kind: 'success'; data: T }
  | { kind: 'error'; message: string; retryAfterMs?: number };

Use it in UI:

function renderUsers(s: FetchState<User[]>) {
  switch (s.kind) {
    case 'idle':    return 'Click to load';
    case 'loading': return 'Loading…';
    case 'success': return `Loaded ${s.data.length} users`;
    case 'error':   return `Error: ${s.message}`;
    default:        return assertNever(s);
  }
}

B) Forms as small flows

type ProfileForm =
  | { kind: 'editing'; values: { name: string; email: string }; errors?: Record<string, string> }
  | { kind: 'submitting'; values: { name: string; email: string } }
  | { kind: 'submitted'; id: string }
  | { kind: 'failed'; values: { name: string; email: string }; message: string };

Now you don’t need isSubmitting, submitError, etc. The state name says it all.

C) Feature flags you can’t misuse

type Rollout =
  | { kind: 'off' }
  | { kind: 'percentage'; percent: number }        // 0..100
  | { kind: 'audience'; segments: Array<'beta'|'staff'|'pro'> }
  | { kind: 'on' };

function isEnabled(flag: Rollout, ctx: { segment: string; rand: number }) {
  switch (flag.kind) {
    case 'off': return false;
    case 'on':  return true;
    case 'percentage': return ctx.rand < flag.percent / 100;
    case 'audience':   return flag.segments.includes(ctx.segment as any);
    default: return assertNever(flag);
  }
}

D) Results and Options (errors without `try/catch` everywhere)

type Result<T, E> = { kind: 'ok'; value: T } | { kind: 'err'; error: E };
type Option<T> = { kind: 'some'; value: T } | { kind: 'none' };

const ok   = <T, E=never>(value: T): Result<T, E> => ({ kind: 'ok', value });
const err  = <E, T=never>(error: E): Result<T, E> => ({ kind: 'err', error });
const some = <T>(value: T): Option<T> => ({ kind: 'some', value });
const none = <T=never>(): Option<T> => ({ kind: 'none' });

function parseJson<T>(s: string): Result<T, string> {
  try { return ok(JSON.parse(s) as T); }
  catch (e) { return err('Invalid JSON'); }
}

Helpful add-ons

Small type guards (nice for readability)

const isSuccess = <T>(s: FetchState<T>): s is { kind: 'success'; data: T } =>
  s.kind === 'success';

if (isSuccess(state)) {
  // state.data is available and typed
}

Tiny matcher (for one-line mappings)

function match<T extends { kind: string }, R>(
  v: T,
  handlers: { [K in T['kind']]: (x: Extract<T, { kind: K }>) => R }
): R {
  return handlers[v.kind](v as any);
}

const label = match(state, {
  idle:    () => 'Idle',
  loading: () => 'Loading…',
  success: s => `Got ${s.data.length}`,
  error:   s => `Error: ${s.message}`,
});

(This is optional, plain switch is perfectly fine.)

Migrating your code

List current flags that describe modes: isLoading, hasError, status, etc.
Name states that cover reality, e.g. idle | loading | success | error.
Move fields into their states (error message inside 'error', data inside 'success').
Replace if with switch (state.kind).
Add assertNever to catch missing cases now and in the future.

Do this one module at a time. You’ll see benefits immediately.

Testing becomes easier

Because your state-changing functions are pure (input → output, no side effects), tests are short and stable.

import { it, expect } from 'vitest';

it('goes loading -> success', () => {
  const s0: FetchState<User> = { kind: 'idle' };
  const s1: FetchState<User> = { kind: 'loading' };
  const s2: FetchState<User> = { kind: 'success', data: { id: '1', name: 'Soumaya' } };
  expect(s0.kind).toBe('idle');
  expect(s1.kind).toBe('loading');
  expect(s2.kind).toBe('success');
});

No mocking of timers or network required to test state transitions.

Common mistakes

Different tag names. All variants must share the same discriminant name (e.g., always kind).
Optional fields everywhere. If a field only matters in one situation, make it its own state instead of field?: T.
Too many tiny states. If two states act the same and hold the same data, merge them.
Forgetting exhaustiveness. Keep assertNever (or a default: exhaustive(state) helper) to catch missing cases.

Final thoughts

Discriminated unions are small but powerful:

They name your states.
They make impossible states impossible.
They give you clear code and better autocomplete.
They make changes safe (the compiler shows what to update).

Start with one place that currently uses isLoading + error + data?. Turn it into a union with kind. You’ll feel the difference right away.

Mastering Angular DevTools

Soumaya Erradi — Sun, 03 Aug 2025 09:19:42 +0000

If you’ve ever felt like debugging an Angular app was like solving a puzzle in the dark, you’re not alone. I’ve been there too, opening the browser console, adding console.log() statements, trying to guess why a component keeps re-rendering or where a signal is stuck.

That changed when I started using Angular DevTools.

In this article, I’ll walk you through how Angular DevTools works, what you can do with it, and how to use it to debug smarter and optimize faster, with practical examples and diagrams to help you visualize what’s happening under the hood.

Why Angular DevTools?

Angular is powerful, but sometimes that power makes things harder to trace. Between @Input() bindings, signals, services, lifecycle hooks and change detection, it can be difficult to see what's really going on.

Angular DevTools is a browser extension that gives you real-time insight into:

Your component tree
Input and output values
Signals and state changes
Change detection cycles
Performance profiling

It’s built to work with Angular 9+ (Ivy is required) and gets better with each version of Angular, especially with the recent addition of signals.

Getting started

First, install Angular DevTools from the Chrome Web Store.

Once installed:

Run your app with ng serve
Open Chrome DevTools
Click on the Angular tab

If you don’t see it, make sure your app isn’t in production mode and that you’re using Ivy (enabled by default in Angular 9+).

Feature breakdown

1. Inspect Components

@Component({
  selector: 'app-user-card',
  template: `
    <h2>{{ user.name }}</h2>
    <p>{{ user.email }}</p>
    <button (click)="toggleActive()">
      {{ user.active ? 'Deactivate' : 'Activate' }}
    </button>
  `,
})
export class UserCardComponent {
  @Input() user: { name: string; email: string; active: boolean };
  @Output() statusChange = new EventEmitter<boolean>();

  toggleActive() {
    this.user.active = !this.user.active;
    this.statusChange.emit(this.user.active);
  }
}

DevTools lets you:

Inspect the component tree
Edit @Input() values live
Trigger outputs and debug events

Component tree diagram

2. Debug Signals (Angular 18+)

@Component({
  selector: 'app-counter',
  template: `
    <h3>Count: {{ count() }}</h3>
    <button (click)="increment()">+</button>
  `,
})
export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.set(this.count() + 1);
  }

  constructor() {
    effect(() => {
      console.log('Count changed:', this.count());
    });
  }
}

Signal flow diagram

3. Visualize Change Detection

@Component({
  selector: 'app-product-list',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<div *ngFor="let product of products">{{ product.name }}</div>`,
})
export class ProductListComponent {
  @Input() products: Product[];
}

If your list re-renders too often, DevTools helps you catch it.

Change Detection timeline

4. Use the Profiler

Record a session and analyze which components rendered and how long they took. This helps pinpoint bottlenecks in dashboards, lists, and forms.

5. Explore the Dependency Injection graph (Experimental)

@Injectable({ providedIn: 'root' })
export class AuthService {
  isLoggedIn = signal(false);
}

@Component({
  selector: 'app-navbar',
  template: `<span *ngIf="auth.isLoggedIn()">Welcome!</span>`,
})
export class NavbarComponent {
  constructor(public auth: AuthService) {}
}

DI graph

Real-world debugging use cases

A parent component was mutating an array, DevTools helps realize it by showing stale inputs.
The Profiler showed that a sidebar was re-rendering unnecessarily, OnPush fixed it.
A signal wasn't updating because it was tied to a destroyed component.

Tips & tricks

ng.getComponent($0) lets you inspect a DOM element’s Angular instance
Use ng.profiler.timeChangeDetection() for benchmarks
Name your signals for easier tracking:

  const count = signal(0, { name: 'counter' });

Known limitations

Works only in development mode
Ivy is required
Some features are experimental

Conclusion

Angular DevTools helps you answer tough questions: Why is this rendering? What changed? Where is this value coming from? It gives you visibility, speed and confidence when working with modern Angular apps.

Install it, explore your app and see how much easier debugging can be.

Install Angular DevTools

My first semester of 2025: conferences, stories & lessons from the road

Soumaya Erradi — Sun, 06 Jul 2025 07:52:49 +0000

2025 started at full speed, and I’m not even sure how I managed to fit so many cities, stages, workshops and countless conversations into just six months.
In this article, I want to take you with me through every stop of this first half of the year: what I spoke about, what I learned and the small moments that made each event unforgettable.

🎙️ January 10 — Bonanni a Tutti, Torino

Talk: Cypress, Playwright o Selenium: la sfida definitiva!
The best kickoff of the year, invited by my dear friend Savino Carlone to his event in Turin. A perfect way to break the winter blues: testing tools, community vibes and good food.

🇸🇪 February 4 — Swetugg, Stockholm

Talk: Mastering Git
My first time in Sweden! I joined the Microsoft community there and met so many new faces. This trip was extra special: I got to visit my friends Mohammed Aboullaite and Abdellfetah Sghiouar at their offices in Stockholm, the perfect blend of professional growth and personal connections.

🇫🇷 February 28 — Paris TypeScript La Conf, Paris

Talk: TypeScript meets IoT: Safe Programming for Embedded Devices
First time speaking in France, and my first ever trip to Paris! The event, organized by BeJs, was fantastic: professional yet warm, full of curious developers. The speaker tour of Paris the next day was the cherry on top.

🇮🇹 March 14 — NG-Venice, Venice

Talk: Performance & SSR in Angular
A new Angular conference in Italy, and I was happy to speak at its very first edition! I shared the stage with Enea Jahollari and Kasia Biernat-Kluba to talk about two of my favourite topics: SSR and performance. It felt like a big family reunion.

🇳🇱 March 21 — WebDevCon, Amsterdam

Talk: Discover the Magic of TypeScript
Back in my favourite city ever: Amsterdam. Despite it being a tough time for me to travel, the city worked its magic again. The event was packed with inspiring speakers and deep conversations that refueled my passion.

🇮🇹 March 31 — Web Day, Milan

Talk: Test di Accessibilità Semplificati con Cypress
A tradition: joining Web Day, one of the main Italian conferences. This talk was very personal, accessibility is a topic I wasn’t always mindful of, but I wanted to share my journey to do better. The audience’s interest showed me how important it is to keep pushing for inclusive web development.

🇬🇧 April 24–25 — CityJS London, London

Workshop: TypeScript meets IoT
Talk: Cypress, Playwright or Selenium: Choosing the Right Testing Tool
My first conference workshop! I brought my Arduino on stage and dived deep into TypeScript for embedded devices. Sharing my passion for electronics in a web conference context was a highlight.
The next day, I gave a last-minute talk, and the room was packed! Proof that even unplanned moments can turn into something special.

🇩🇪 May 6–7 — Advanced Developer Conference, Regensburg

Talks: Mastering Git & Cypress, Playwright or Selenium
An unforgettable venue, a football stadium! My first talk took place in the players’ changing room, which was surreal and so much fun. The second talk sparked lively discussions about testing tools and real-world use cases. Inspiring exchanges all around.

🇪🇸 May 14–16 — J On The Beach, Malaga

Talk: TypeScript meets IoT
My first conference in Spain, what better setting than right by the beach? I tested my few Spanish words and they did the trick! My Arduino joined me on stage again, and the audience was eager to learn how TypeScript can push hardware programming further.

🇫🇷 May 24 — NG Baguette, Nantes

Talk: Next-Level Angular SSR: Exploring Hydration Enhancement
Back to France, this time to Nantes, with the amazing Angular community, probably my favourite bunch! It felt like catching up with old friends while meeting so many new ones who share the same passion.

🇬🇷 May 29–30 — CityJS Athens, Athens

Workshop: TypeScript meets IoT
Talk: Cypress, Playwright or Selenium
First time speaking in Greece, sun, great food, even better people! We ended the days with competitive quizzes (yes, we won!) and long dinners full of laughs. I’m grateful for how this event blended learning and fun.

🏟️ June 12 — Middlesbrough Front End Conference, Middlesbrough

Talk: Accessibility Testing Made Easy with Cypress
Yet another stadium venue, and an incredible atmosphere! My talk on accessibility really resonated with the audience; so many people reached out afterwards to share thoughts and ideas. It’s a reminder that accessibility is everyone’s job.

🇩🇰 June 18 — Codegarden, Odense

Talk: Mastering Git
My first time in Denmark: a curious, welcoming city that felt just right. The event, focused on Umbraco, was huge and vibrant. I was new to this community but quickly felt at home. Many people turned up to learn more about what really happens under the hood with Git.

🇩🇪 July 2 — Developer World, Mannheim

Talk: Mastering Git
My final talk of the season, back to Germany for a super professional but warm event. The audience’s curiosity about Git keeps surprising me. After the conference, I wandered through the city centre, closing this first half of the year with many steps and even more gratitude.

✨ Reflections

Seventeen talks. Fourteen events. Fourteen cities. Nine countries. Countless stories.
Looking back, this semester reminded me why I do this: I love to share what I learn, but I love even more what I learn from everyone I meet.

🔜 What’s Next?

Now it’s time to plan the next half of 2025: new topics, new experiments, new communities to join.
I can’t wait to see where the next talks will take me. If you see me on the schedule, come say hi!

The European Accessibility Act: What developers need to know

Soumaya Erradi — Sun, 08 Jun 2025 14:25:55 +0000

The European Accessibility Act (EAA) is about to change the game, starting June 28, 2025, digital accessibility becomes mandatory for products and services offered to EU users.

If you’re a developer building websites, mobile apps, or digital tools for the European market, accessibility is no longer a best practice, it’s a legal requirement.

In this article, we’ll cover what that means for you, with real code examples you can apply today. Let’s dive in.

What’s the EAA?

The European Accessibility Act is an EU directive designed to harmonize accessibility standards across Europe. Its goal is to ensure that people with disabilities can access and use digital products and services on equal terms.

As of June 28, 2025, all businesses offering digital products or services to EU consumers, even if they're based outside the EU, must comply with these rules.

The law applies to:

Websites and mobile apps
E-commerce platforms
Banking, ticketing, and transport services
eBooks, self-service terminals, ATMs, and more

The EAA is based on:

WCAG 2.1 AA (Web Content Accessibility Guidelines)
EN 301 549, a European standard for ICT accessibility

National authorities will be responsible for enforcing compliance, which means audits, penalties, and reputational risks for companies that fail to meet the bar.

Bottom line: You need to ensure your digital interfaces are usable by everyone, starting now.

Accessibility is a fix, not a feature

“An app without keyboard support or labels is broken for many users.”

Accessibility ensures people with visual, motor, cognitive, or situational impairments can use your product. Let’s fix common issues.

Forms: always pair inputs with labels

Screen readers need labels to announce fields.

❌ Missing label:

<input type="email" placeholder="Email">

✅ Proper label:

<label for="email">Email</label>
<input id="email" type="email">

🔁 Alternative:

<input type="email" aria-label="Email">

Icon buttons: provide an accessible name

Icon-only buttons must expose a name.

❌ Unlabeled:

<button><i class="fa fa-search"></i></button>

✅ With aria-label:

<button aria-label="Search">
  <i class="fa fa-search"></i>
</button>

Images: never skip `alt`

Screen readers ignore images without alt.

❌ No alt:

<img src="logo.png">

✅ Descriptive alt:

<img src="logo.png" alt="Company logo">

Decorative?

<img src="divider.svg" alt="">

Keyboard: make everything tabbable

Test your UI without a mouse. If you can’t Tab to it, users can’t either.

✅ Native button:

<button>Submit</button>

❌ Div hack:

<div onclick="submitForm()">Submit</div>

If you must use a div:

<div role="button" tabindex="0"
     onclick="submitForm()"
     onkeydown="if(event.key==='Enter') submitForm()">
  Submit
</div>

but prefer <button>.

Headings: maintain hierarchy

Headings create an outline for screen reader users.

❌ Wrong:

<h1>Dashboard</h1>
<h4>Stats</h4>

✅ Right:

<h1>Dashboard</h1>
<h2>Stats</h2>

Contrast: verify ratios

Ensure text/background contrast meets WCAG:

4.5:1 for normal text
3:1 for large text (≥18px bold)

Use tools like:

Automate with tools

Catch many issues early—automate these checks:

🧪 Lighthouse (Chrome DevTools)

Inspect → Lighthouse → Accessibility

🧪 axe-core

npm install --save-dev axe-core

import axe from 'axe-core';
axe.run(document).then(({ violations }) => {
  console.log(violations);
});

🧰 Other integrations

Pa11y (CLI)
Playwright + @axe-core/playwright
Cypress + cypress-axe

Dynamic content

After a route change or modal open, re-run your checks and manage focus.

Playwright example:

import { injectAxe, checkA11y } from '@axe-core/playwright';

await injectAxe(page);
await page.click('#open-modal');
await checkA11y(page, '#modal-content');

Focus management:

const dialog = document.querySelector('[role="dialog"]');
dialog.hidden = false;
dialog.focus();

ARIA live for updates:

<div aria-live="polite" id="status">3 items added to cart</div>

Quick dev checklist

Labels on all form controls
Icon buttons have aria-label
Images include meaningful alt
Keyboard navigation works
Logical heading order
Sufficient color contrast
Dynamic changes announced

Conclusion

The EAA is weeks away from enforcement, and for developers, this is a pivotal moment. Accessibility is now part of your delivery requirements, not something to push down the backlog.

Start reviewing your apps with real users in mind. Write accessible HTML, automate your checks, and fix the easy stuff first. Tools can help, but so can habits.

Because in the end, accessibility isn’t just about compliance, it’s about building better software for everyone.

The new Cypress features you should be using

Soumaya Erradi — Sun, 04 May 2025 12:17:02 +0000

End-to-end testing has evolved. Today, Cypress offers more than just a slick UI and an intuitive syntax, it now comes packed with powerful features that make tests faster, more realistic and easier to debug.

In this article, we’ll dive into three of the most exciting additions to Cypress:

cy.session() — for smarter state caching
cy.press() — for realistic keyboard navigation
cy.stop() — for precise control of test execution

Whether you're scaling tests across CI, validating accessibility flows or debugging a tricky edge case, these new commands will upgrade your test suite.

`cy.session()`: cache once, reuse everywhere

We’ve all repeated login flows in every test:

beforeEach(() => {
  cy.visit('/login');
  cy.get('input[name="email"]').type('test@example.com');
  cy.get('input[name="password"]').type('passwordExample');
  cy.get('button[type="submit"]').click();
});

It works, but it’s slow. And flaky.
cy.session() solves this by caching browser state (like cookies and localStorage) after a one-time setup.

How to use it:

beforeEach(() => {
  cy.session('admin-session', () => {
    cy.request('POST', '/api/login', {
      email: 'admin@example.com',
      password: 'admin123'
    }).then((res) => {
      window.localStorage.setItem('auth_token', res.body.token);
    });
  });
});

Now your tests run faster and skip repeated login steps. Cypress restores the session seamlessly between tests in the same spec.

Bonus: If you're using Cypress Cloud, session state is even visible in replays.

`cy.press()`: simulate real keyboard navigation

Testing keyboard behavior used to feel like a workaround. cy.type('{tab}') could only go so far, it didn’t trigger real focus movement in most browsers.

Now Cypress supports cy.press(), a new command designed for real keyboard event simulation (currently supporting Tab).

Perfect for:

Testing keyboard accessibility
Navigating forms
Validating focus order

cy.get('input[name="email"]').focus();
cy.press(Cypress.Keyboard.Keys.TAB);
cy.focused().should('have.attr', 'name', 'password');

What you should know:

✅ Works in Chromium and Firefox (v135+)
❌ Not yet supported in WebKit (e.g., Safari)
⚠️ Currently only supports Tab, more keys coming soon

It’s a big win for accessibility-first development and progressive enhancement strategies.

`cy.stop()`: pause Cypress execution programmatically

Imagine this: your test is halfway through, and you want to inspect the DOM, view state or manually interact with the app before continuing.

cy.stop() lets you pause test execution at any point, from code.

Example:

cy.visit('/dashboard');
cy.get('.notification').should('be.visible');
cy.stop(); // Open Cypress runner and inspect manually

This is incredibly useful for:

Debugging
Live demos
Investigating CI failures

You don’t need to add breakpoints manually anymore or pause via DevTools — Cypress now supports it natively.

Pro tip: Use it alongside .only and .debug() for powerful test inspection sessions.

Bonus: use `cy.stop()` in `afterEach()` to halt further test execution

In some scenarios, especially in CI environments or resource-intensive apps, you might want to stop the entire suite after a certain test runs, for example, if a critical failure occurs or if you're debugging and don’t want Cypress to continue running all remaining tests.

afterEach(() => {
  // Stop further tests from running
  cy.stop();
});

This can be helpful when:

You’re investigating a specific test failure and want to reduce test time
You’ve already hit a known issue and want to skip everything else
You’re preventing high memory or CPU usage in CI after a failure

It gives you fine-grained control over your test pipeline without needing to reconfigure your runner or manually skip specs.

Real-world combo: use all three

Here’s what a more modern, robust Cypress test could look like:

describe('Keyboard-first login flow', () => {
  beforeEach(() => {
    cy.session('admin-session', () => {
      cy.request('POST', '/api/login', {
        email: 'admin@example.com',
        password: 'admin123'
      }).then(({ body }) => {
        window.localStorage.setItem('auth_token', body.token);
      });
    });
  });

  it('should navigate through the login form with keyboard', () => {
    cy.visit('/login');
    cy.get('input[name="email"]').focus();
    cy.press(Cypress.Keyboard.Keys.TAB);
    cy.focused().should('have.attr', 'name', 'password');
  });

  it('should pause before interacting with dashboard', () => {
    cy.visit('/dashboard');
    cy.stop(); // Inspect DOM or state here
    cy.contains('Welcome, admin');
  });
});

This test:

Logs in once using cy.session()
Simulates keyboard navigation with cy.press()
Pauses for inspection with cy.stop()

Clean. Performant. Inspectable.

Conclusion

These new Cypress features are small additions, but they enable big wins:

Shorter, faster tests
Realistic user interaction simulation
Easier debugging and flow validation

If you haven’t tried them yet, now’s the time to experiment.

Cypress isn’t just about writing tests. It’s about creating confidence through repeatable, human-like workflows. And these features bring us closer than ever.

Discover the magic of Typescript

Soumaya Erradi — Sun, 06 Apr 2025 12:47:37 +0000

Typescript is the magic wand for JavaScript development when it comes to developer confidence, scalability, and expressiveness. Building robust web applications today requires better tooling and runtime safety.

This article will introduce you to the powerful features of Typescript, from basic concepts to advanced type manipulation techniques that can enhance your code quality and expressiveness.

Why Typescript?

Let’s be honest, Javascript is powerful but it doesn't scale well by default. As applications grow, dynamic typing can become a limitation. Typescript gives us:

Predictability: Catching bugs at compile time before they reach users.
Tooling superpowers: From autocomplete to inline documentation.
Team confidence: A shared language to describe shape and intent.

Typescript is not here to replace Javascript. It compiles to it, so you can adopt it incrementally.

Typescript vs Javascript

Feature	Javascript	Typescript
Typing	Dynamic	Static (with inference)
Tooling	Limited	Rich (IntelliSense, refactoring)
Maintainability	Can become messy	Easier to scale
Learning Curve	Easy	Steeper, but rewarding

Javascript gives you flexibility. Typescript gives you confidence.

Getting started with Typescript

You can start with a simple install:

npm install -g typescript

Create a config file:

tsc --init

Enable strict mode. It’s worth it.

Typescript fundamentals

Type annotations & inference

let name: string = "Soumaya";
let age = 33; // inferred as number

Basic types

string, number, boolean: Primitive data types.
Arrays: string[] or Array<string> — a list of items of a single type.
Tuples: [string, number] — a fixed-size array with defined types per index.
Enums: For named constants with auto-incrementing values or custom assignments.

enum Direction {
  Up,
  Down,
  Left,
  Right
}

Special types you should know

any: Turns off type checking. Avoid unless necessary.
unknown: Like any but requires type checking before usage.
never: A type that never occurs. Used for functions that throw or never return.

Union & intersection types

Union

let input: string | number;

Represents a variable that can be one of several types.

Intersection

type Admin = { role: string };
type User = { name: string };
type AdminUser = Admin & User;

Combines multiple types into one.

Type guards

function printId(id: string | number) {
  if (typeof id === 'string') {
    console.log(id.toUpperCase());
  } else {
    console.log(id.toFixed(2));
  }
}

Type guards are your runtime safety net. They help Typescript narrow types dynamically.

Interfaces vs type aliases

Use interface when extending shapes. Interfaces are great for object structures.

Use type when composing types, unions, or template literals.

interface Animal {
  name: string;
}
type Dog = Animal & { bark: () => void };

Generics

Generics provide a way to write flexible, reusable functions and types that still enforce strong typing.

function identity<T>(value: T): T {
  return value;
}

T is a type variable. It makes the function reusable for any type.
Used widely in utility functions, libraries, and components.

Built-in utility types

Partial<T> – All properties of T become optional. Useful for update operations.
Readonly<T> – Prevents modification of T's properties.
Pick<T, K> – Select a subset of T’s properties.
Omit<T, K> – Exclude some properties from T.
Record<K, T> – Creates a type with keys K and values of type T.

Example

type User = { id: number; name: string; email: string };
type Preview = Pick<User, "id" | "name">;

Preview is a lighter version of User containing only id and name.

Branded types

Branded types add a unique signature to otherwise compatible types, helping prevent accidental mix-ups when different types share the same structure.

type UserId = string & { readonly brand: unique symbol };
function createUserId(id: string): UserId {
  return id as UserId;
}

Adds a "brand" to make structural types nominal. Prevents accidental mixing of similar-looking types.

Discriminated unions

Discriminated unions allow safe type narrowing based on a common property, typically kind.

type Shape = 
  | { kind: 'circle'; radius: number }
  | { kind: 'square'; side: number };

function area(shape: Shape) {
  switch (shape.kind) {
    case 'circle': return Math.PI * shape.radius ** 2;
    case 'square': return shape.side ** 2;
  }
}

Each shape type is distinguished by a kind field.

Template literal types

Template literal types allow you to construct string-like types using patterns.

type Route = `/${string}`;

Creates types from string patterns. Useful for route matching or string constraints.

Conditional types & infer

Conditional types use the ternary syntax to express type logic. Combined with infer, you can extract information from other types.

type Return<T> = T extends (...args: any[]) => infer R ? R : never;

Extracts the return type R from a function T.

Variadic tuple types

Variadic tuple types enable manipulation of tuples by adding or spreading elements dynamically. This is powerful for function arguments and reusable tuple templates.

type AppendNumber<T extends unknown[]> = [...T, number];

Allows dynamic extension of tuples. Great for typing argument lists.

Recursive types

Recursive types reference themselves to represent nested structures. They're key for typing data like trees or JSON-like data.

type Tree<T> = {
  value: T;
  children?: Tree<T>[];
};

Allows types to reference themselves. Useful for representing nested data structures.

Conclusion

Typescript is more than just type safety. It’s about improving the developer experience, writing expressive code, and building scalable applications. Once you go beyond the basics, you uncover an elegant type system capable of modeling complex behaviors and constraints.

TypeScript offers a comprehensive toolkit to create code that is cleaner, safer, and smarter, from encoding logic with conditional types to inferring return values.

Mastering Typescript opens up new levels of control and clarity in your code, whether you're defining APIs, transforming data structures, or building powerful, reusable components.

The magic is real, and it’s all in the types.

Angular Change Detection with Zoneless

Soumaya Erradi — Sun, 02 Feb 2025 13:09:28 +0000

Change detection is at the heart of every Angular application. It ensures that the application's user interface (UI) stays in sync with its data model. Traditionally, Angular has relied on a mechanism called zones, powered by the zone.js library, to make this happen. But with Angular’s latest version, a new zoneless change detection feature is introduced, marking a significant shift in how developers can optimize their applications.

In this article, we will explore:

How change detection works in Angular.
Problems caused by zones.
The introduction of zoneless mode and how to use it.
Handling complex situations with zoneless change detection.
Why signals and zoneless mode are a powerful combination.
The benefits and revolutionary impact of this feature.

Understanding Change Detection in Angular

Change detection is the process Angular uses to make sure the application's UI is always updated with the latest data. This happens automatically whenever something changes in your application, whether it’s a user action, an HTTP request or a timer event.

In Angular, every component has its own change detection mechanism, which checks if the values in the component's template have changed and updates the DOM accordingly.

Zones and their role

Angular has traditionally used zone.js to patch asynchronous operations such as:

HTTP requests.
Event listeners (e.g., button clicks).
Timers like setTimeout or setInterval.

When any of these operations are completed, zone.js automatically triggers Angular's change detection mechanism, ensuring the UI stays in sync. This makes development easier, as developers don’t need to worry about manually updating the UI.

The problems with Zones

While zone.js simplifies development, it introduces some challenges:

Performance overhead: By patching all asynchronous operations, zone.js adds unnecessary overhead, especially in large or high-performance applications.
Debugging complexity: Debugging issues becomes harder because zone.js modifies how asynchronous operations work under the hood.
Compatibility issues: Some modern browser APIs and third-party libraries don’t work well with zone.js.
Unnecessary change detection: Angular’s change detection runs even when the application’s state hasn’t changed, leading to wasted resources.

The Zoneless revolution in Angular

With the release of Angular v19, the framework introduced an experimental zoneless mode to address these problems. Zoneless mode allows Angular to run without zone.js, giving developers more control over when and how change detection happens.

What does Zoneless mode do?

In zoneless mode:

Angular no longer automatically tracks asynchronous operations.
Developers must manually trigger change detection when data changes.
The application becomes leaner and faster since there’s no overhead from zone.js.

How to use Zoneless mode

Zoneless mode might feel like a significant shift, but breaking it into clear steps ensures a smooth transition. Here's a detailed guide:

Step 1: Disable Zone.js

To disable zones, start by removing the zone.js library from your application.

Update polyfills.ts: Remove or comment out the import for zone.js:

   // polyfills.ts
   // Remove or comment out the following line:
   // import 'zone.js';

Remove from Dependencies: Check your package.json and remove zone.js from the dependencies section:

   {
     "dependencies": {
       "zone.js": "^0.12.0" // Remove this dependency
     }
   }

Uninstall the Library: Run the following command to uninstall zone.js completely:

   npm uninstall zone.js

Step 2: Bootstrap without Zone.js

Angular provides a dedicated function, provideExperimentalZonelessChangeDetection(), to enable zoneless mode in your application. This function ensures that Angular initializes without zone.js and uses the experimental zoneless change detection.

Here’s how to configure it in your main.ts file:

import { bootstrapApplication } from '@angular/platform-browser';
import { provideExperimentalZonelessChangeDetection } from '@angular/core';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideExperimentalZonelessChangeDetection(), // Enable zoneless change detection
  ],
}).catch(err => console.error(err));

Step 3: Manually trigger change detection

Once zones are disabled, Angular will no longer automatically run change detection. You need to trigger it manually when state changes occur.

Using `ChangeDetectorRef`

The ChangeDetectorRef service allows you to invoke change detection at the component level. Additionally, the markForCheck() method is useful in scenarios where you want Angular to schedule change detection for components with OnPush change detection strategy:

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

@Component({
  selector: 'app-root',
  template: `
    <div>
      <h1>Counter: {{ counter }}</h1>
      <button (click)="incrementCounter()">Increment</button>
    </div>
  `,
})
export class AppComponent {
  counter = 0;

  constructor(private cdr: ChangeDetectorRef) {}

  incrementCounter() {
    this.counter++;
    this.cdr.markForCheck(); // Mark the component for checking during the next change detection cycle
  }
}

Using `ApplicationRef`

For global state changes, you can use ApplicationRef.tick() to trigger change detection across the entire application:

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

@Component({
  selector: 'app-global-tick',
  template: `
    <button (click)="updateState()">Update State</button>
    <p>{{ message }}</p>
  `,
})
export class GlobalTickComponent {
  message = 'Initial State';

  constructor(private appRef: ApplicationRef) {}

  updateState() {
    this.message = 'Updated State';
    this.appRef.tick(); // Trigger change detection globally
  }
}

Step 4: Optimize with Signals

Angular signals, introduced with Angular's new reactivity model, are an excellent companion to zoneless mode. Signals track state changes efficiently and automatically update the UI without manual calls to change detection.

Here’s a simple example using signals:

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

@Component({
  selector: 'app-signal-demo',
  template: `
    <h1>Signal Counter: {{ count() }}</h1>
    <button (click)="increment()">Increment</button>
  `,
})
export class SignalDemoComponent {
  count = signal(0);

  increment() {
    this.count.set(this.count() + 1);
  }
}

In this setup, the signal automatically tracks changes, and the UI updates without the need for explicit detectChanges calls.

Handling complex situations

Scenario: multiple data streams

When working with multiple asynchronous streams (e.g., using RxJS), AsyncPipe remains a reliable solution in zoneless mode. It simplifies data binding and eliminates the need for manual change detection:

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

@Component({
  selector: 'app-multi-stream',
  template: `<p>Stream Value: {{ value$ | async }}</p>`
})
export class MultiStreamComponent {
  value$ = interval(1000); // Emits a value every second
}

Why Zoneless mode is revolutionary

Performance gains: Applications become faster and more efficient by eliminating zone-related overhead.
Developer control: Zoneless mode lets you decide when to update the UI, leading to better-optimized apps.
Compatibility: Works seamlessly with modern APIs and third-party libraries.
Enhanced reactivity: Combined with signals, zoneless mode simplifies state management and improves app responsiveness.

Conclusion

The introduction of zoneless change detection in Angular is a game-changer. It empowers developers to build faster, more efficient applications while giving them greater control over how and when updates happen. Coupled with Angular signals, zoneless mode unlocks new possibilities for optimizing performance and simplifying state management.

As Angular continues to evolve, features like this reinforce its position as one of the most versatile and powerful frameworks for modern web development!

Forem: Soumaya Erradi

Angular HTTP Interceptors: A modern guide

1. The core concept: The "toll booth" analogy

2. Defining a Functional Interceptor: HttpInterceptorFn

3. Immutability & Cloning: The modifying rule

4. Registering your Interceptors (Dependency Injection)

5. Real-world power moves: 4 advanced patterns

Pattern A: The Authentication Header (JWT) Interceptor

Pattern B: Global Error Handling with RxJS

Pattern C: Performance logging

Pattern D: A modern loading spinner

Summary of Best Practices

Conclusion

Signal Forms in Angular 21

A real checkout Form

Creating the Form

Nested binding feels natural

Conditional logic without fighting the API

Cross-field validation becomes boring (In a good way)

Derived state is first-class

Synchronizing fields without patching controls

Field state is still there — Just reactive

Why this feels different

Is this ready for Production?

My honest take

Angular’s Resource API: Making async state human again

The pain of async state in Angular

What if async behaved like a signal?

What is the Resource API?

Your first resource

Using a resource in the template

Reactive dependencies: the core idea

Reloading data manually

The three flavors of Resource

resource() – the general-purpose tool

httpResource() – HTTP without boilerplate

rxResource() – real-time streams

Before vs After: a real comparison

Before (classic RxJS setup)

After (Resource API)

Common gotchas

Reading signals outside params()

Accessing value() too early

Does this replace RxJS?

Where should a resource live?

Final thoughts

My Second Semester of 2025

DevFest Lecce — Lecce, Italy - September 12

Come to Code — Pignola, Italy - September 27–28

DevFest Modena — Modena, Italy - October 4–5

Frontmania — Utrecht, The Netherlands - October 8

INIT Conference — Banja Luka, Bosnia and Herzegovina - October 10–11

Codemotion Milan — Milano, Italy - October 14–15

DevFest Roma — Roma, Italy - October 25

Cursor Meetup — Casablanca, Morocco - November 1

Devoxx Morocco — Marrakech, Morocco - November 12–15

Wey Wey Web — Malaga, Spain - November 17–18

JS Poland — Warsaw, Poland - November 19

AngularDay — Verona, Italy - November 21

DevFest Bari — Bari, Italy - November 30

Angular.love Meetup — Warsaw, Poland - December 11

Closing thoughts

How to write a talk proposal that actually gets accepted

The problem: proposals that feel polished, but empty

A talk proposal is not a documentation page

Using AI is not the problem, outsourcing your voice is

What I personally look for when reviewing a proposal

1. A clear angle

2. Evidence of experience (not expertise)

3. Honest scope

4. A human tone

Common mistakes I see again and again

A simple exercise to add a personal touch

Final thought

Discriminated Unions in TypeScript explained simply

The idea

Why this helps

How to use it

1) Define the states

2) Write code that switches on the tag

2. Defining a Functional Interceptor: `HttpInterceptorFn`

`resource()` – the general-purpose tool

`httpResource()` – HTTP without boilerplate

`rxResource()` – real-time streams

Reading signals outside `params()`

Accessing `value()` too early

A) Async fetch without `isLoading`

D) Results and Options (errors without `try/catch` everywhere)

Images: never skip `alt`

`cy.session()`: cache once, reuse everywhere

`cy.press()`: simulate real keyboard navigation

`cy.stop()`: pause Cypress execution programmatically