DEV Community: Gérôme Grignon

Angular 21.1 Release: What's New and How to Use It

Gérôme Grignon — Thu, 15 Jan 2026 11:41:46 +0000

Angular 21.1 is now available, delivering meaningful improvements to Signal Forms, Control Flow syntax, Router APIs, and developer tooling. This release focuses on developer experience refinements and fills important gaps in the existing APIs.

In this guide, we'll break down each feature, explain when you should use it, and provide practical code examples to help you adopt these changes in your projects.

What's in This Release

Signal Forms: New formField directive and form focus capabilities
Control Flow: Multi-case support in @switch blocks
Image Loaders: Custom transformations for major CDN providers
Router: isActive as a Signal, experimental route cleanup, and Navigation API integration
Developer Tooling: New stability debugger for SSR/hydration debugging
Template Expressions: Support for spread operators and rest arguments

Signal Forms Improvements

Angular's Signal Forms API continues to mature with this release, addressing real-world usage patterns and developer feedback.

The New formField Directive

Angular 21.1 introduces the formField directive as the preferred way to bind Signal Form Controls to form elements. While the existing field directive continues to work, the Angular team recommends adopting formField going forward.

Why the change? The name field proved too generic, potentially conflicting with other libraries or custom directives in your application. The formField directive provides a more explicit, Angular-specific namespace.

<!-- Previous approach (still works, but will be deprecated) -->
<input type="email" [field]="loginForm.email" />

<!-- Recommended approach -->
<input type="email" [formField]="loginForm.email" />

Under the hood, both directives share the same implementation. Looking at Angular's internal code reveals they're literally interchangeable options:

readonly formFieldBindings: Signal<readonly (Field<unknown> | FormField<unknown>)[]>;

Migration tip: While both options work today, expect a migration schematic in a future release to automate the transition. Start using formField in new code now to minimize future migration work.

Note: The formField directive was technically introduced in Angular 21.0.8, but this release ensures full compiler support and parity with the field directive.

Programmatically Focus a Form

A common UX pattern is focusing the first input field when a form loads or after validation errors. Angular 21.1 makes this straightforward with the new focusBoundControl() method.

Previously, you needed to manually target specific fields using viewChild or template references. Now you can focus the first bound control of an entire form:

// Focus the first field in the form
this.loginForm().focusBoundControl();

This method finds the first element bound via field or formField directive and focuses it—perfect for:

Form initialization
After form reset
When validation fails (focus the first invalid field)
Accessibility improvements

Thanks to Matthieu Riegler for clarifying the intended use case for this feature!

Signal Forms Bug Fixes

This release addresses several edge cases and missing capabilities in Signal Forms:

Control Flow: Multi-Case Switch Blocks

One of the most requested Control Flow features is here: you can now combine multiple @case() conditions for a single block in @switch.

Before Angular 21.1

@switch(status) {
  @case('pending') {
    <status-badge>Waiting</status-badge>
  }
  @case('processing') {
    <status-badge>Waiting</status-badge>
  }
  @case('completed') {
    <status-badge>Done</status-badge>
  }
}

With Angular 21.1

@switch(status) {
  @case('pending')
  @case('processing') {
    <status-badge>Waiting</status-badge>
  }
  @case('completed') {
    <status-badge>Done</status-badge>
  }
}

This eliminates code duplication and makes your templates more readable—especially useful for:

Grouping similar states (loading, pending, processing)
Handling multiple enum values with the same UI
Reducing template maintenance burden

Image Loader Enhancements

If you're using Angular's NgOptimizedImage directive with a CDN provider, you now have more control over image transformations. Angular 21.1 adds custom transformation support for:

Cloudflare Images
Cloudinary
ImageKit
Imgix

This means you can apply provider-specific transformations (like format conversion, quality adjustments, or effects) while still benefiting from Angular's optimized image loading.

For implementation details and configuration examples, see the official NgOptimizedImage documentation.

Enhanced Template Expression Support

Angular's template compiler now supports additional JavaScript expression features:

Rest arguments in function calls
Spread elements in arrays
Spread expressions in objects

@let merged = {...defaultConfig, ...userConfig};
@let combined = {a: 1, ...partialObject, b: 2};
@let nested = {config: {...{nested: {...deepConfig}}}};

A word of caution: While these features are now supported, they can make templates harder to read and debug. Consider keeping complex logic in your component class and exposing simple, computed values to templates. Templates should primarily handle presentation, not data transformation.

Debugging Application Stability

Server-Side Rendering (SSR) and hydration issues often manifest as applications that never "stabilize"—preventing hydration from completing or causing unexpected behavior.

Angular 21.1 introduces provideStabilityDebugging() to help diagnose these issues:

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

export const appConfig: ApplicationConfig = {
  providers: [
    // Add during development to debug stability issues
    provideStabilityDebugging(),
  ],
};

This utility is provided by default in dev mode when using provideClientHydration. You can also add it manually to the application providers for use in production bundles or when using SSR without hydration, for example. The feature logs information to the console if the application takes longer than expected to stabilize.

For detailed usage instructions, see Debugging Application Stability in the official documentation.

Router Improvements

Route Provider Cleanup (Experimental)

A long-standing behavior in Angular Router: providers defined at the route level were never destroyed when navigating away. This could lead to memory leaks and unexpected state persistence.

Angular 21.1 introduces an experimental feature to automatically clean up route-level injectors:

import {
  provideRouter,
  withExperimentalAutoCleanupInjectors,
} from "@angular/router";

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withExperimentalAutoCleanupInjectors()),
  ],
};

When to use this: If your routes define providers that hold significant state or resources, enabling this feature ensures proper cleanup. Test thoroughly, as this changes the lifecycle behavior your application may depend on.

Router.isActive as a Signal

The Router.isActive method is now a computed Signal, enabling fine-grained reactivity for navigation state:

// Old approach (deprecated)
const isActive = this.router.isActive('/dashboard', true);

// New Signal-based approach
const isActive = this.router.isActive('/dashboard', true); // Returns Signal<boolean>

Bundle size note: This feature adds approximately 1.3KB to your bundle, but it's tree-shakable. Applications not using Router.isActive or RouterLinkActive won't pay this cost.

If you're implementing custom route reuse strategies, you can now integrate with this new behavior. See the custom route reuse strategies documentation for details.

Platform Navigation API Integration (Experimental)

The browser's Navigation API provides a modern approach to handling navigation. Angular 21.1 exposes experimental integration:

import { withExperimentalPlatformNavigation } from "@angular/router";

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withExperimentalPlatformNavigation()),
  ],
};

This experimental feature allows Angular Router to leverage browser-native navigation handling for potentially improved performance and better integration with browser features like the back/forward cache.

SSR API Parity

createApplication Improvements

The createApplication function now accepts a BootstrapContext parameter, bringing it to parity with bootstrapApplication. This matters when you're building custom SSR solutions or test harnesses that need fine-grained control over application creation.

Additionally, createApplication now works with JIT-compiled components, removing a previous limitation that required AOT compilation.

Summary

Angular 21.1 delivers practical improvements across the framework.

The Signal Forms API continues to mature, Control Flow becomes more expressive, and developer tooling improves. These incremental improvements compound over time, making Angular applications easier to build and maintain.

For tracking Angular features across versions, check out our Can I Use - Features tool, and stay updated with the latest releases through Release Insights.

Understanding takeUntilDestroyed in Angular

Gérôme Grignon — Mon, 18 Aug 2025 07:38:35 +0000

Angular applications often rely on Observables for handling asynchronous operations, such as HTTP requests, user events, or real-time data streams. Managing the lifecycle of these subscriptions is crucial to prevent memory leaks and unexpected behavior, especially as components and services are created and destroyed.

One of the most effective tools for this in modern Angular is the takeUntilDestroyed operator, introduced in the @angular/core/rxjs-interop package.

What is takeUntilDestroyed?

takeUntilDestroyed is an RxJS operator that automatically completes an Observable when the calling context (such as a component, directive, or service) is destroyed. This means you no longer need to manually unsubscribe from Observables in your ngOnDestroy lifecycle hook, takeUntilDestroyed handles it for you.

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

@Component({...})
export class MyComponent {
  private someService = inject(SomeService);
  constructor() {
    this.someService.getData()
      .pipe(takeUntilDestroyed())
      .subscribe(data => {
        // handle data
      });
  }
}

When the component is destroyed, the subscription is automatically cleaned up, preventing memory leaks and side effects from lingering subscriptions. This is especially important for Observables that emit multiple values over time, such as those from interval, Subject, or real-time data sources, as opposed to HTTP requests with HttpClient, which complete automatically after a single emission.

It does not mean you should not care about the unsubscription of HTTP Requests: Letting them live after the component destruction could lead to some side effects you want to avoid.

Usage outside of the injection content

If you need to use it outside of an injection context, you can inject a DestroyRef and pass it explicitly:

import { DestroyRef, inject } from '@angular/core';

export class MyComponent {
  private someService = inject(SomeService);
  private destroyRef = inject(DestroyRef);

  getData() {
    this.someService.getData()
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe();
  }
}

Best practices

When data from your observable is meant to be used only in a template, prefer relying on the async pipe to subscribe. Angular will automatically clean the subscription when the component is destroyed.

Angular: Beyond the Fog #2

Gérôme Grignon — Tue, 20 May 2025 12:24:16 +0000

Since I created Angular Docs AI assistant (powered by Kapa.ia), some questions have been left unanswered due to some level of uncertainty as the AI model faced some limitations.

Discover some of these questions and how a personal understanding of Angular, its ecosystem, and the community helps to provide better answers!

How does Angular Docs AI chat work?

Angular Docs AI sources are angular.dev, Angular GitHub Discussions and Angular GitHub Issues.

These sources are refreshed weekly.

Test it out: Angular Docs AI

Is it possible to set the OnPush strategy for all components at once?

Angular only allows you to set the OnPush strategy for a component if you set it explicitly in the component metadata.

@Component({
  selector: "app-root",
  templateUrl: "./app.component.html",
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class AppComponent {}

You can set the OnPush strategy as default for new components in your angular.json file but there is no way to toggle the strategy for all components at once.

"schematics": {
    "@schematics/angular:component": {
      "changeDetection": "OnPush"
    }
  }

Was Angular Can I Use developed with AI?

No, Angular Can I Use data was generated by manually exploring multiple sources (Angular documentation, blog posts, and source code) to find proper information. That was one of the key motivations behind creating this project: to have a reliable source of information.

AI could have helped, but it would have faced some limitations.

Where is the style guide content?

The official style guide is available at angular.dev/style-guide.
Its content will be updated with the Angular 20 release, make it simpler to focus on Angular and up to date based on latest Angular API changes.
Some of these changes will impact how we name files generated by Angular CLI ng generate commands.

Can I use Signal input in 17.0.9?

No it's been introduced in 17.1.0 as developer preview, you can check Angular Can I use for release information.

Can you write me a song about Angular?

I'm sorry, but the knowledge sources do not contain any information or examples about explaining Angular in song form. They only provide technical and descriptive details about Angular and its features. If you would like a technical explanation or have another question about Angular, please let me know!

Angular Docs AI has been built to be helpful and informative, never intending to be used for creative purposes, but if you want to write a song about Angular, I'm sure you will find a way to do it.

But you are lucky, Younes Jaaidi just created a song about Angular, check it out: https://www.youtube.com/watch?v=D-Xc3Uo_s6s

Can I use standalone components in Angular 13?

No, standalone components were introduced in Angular 14, as an experimental feature, then stabilized in Angular 15.

Is httpressource safe to use?

httpResource has been introduced as an experimental feature in Angular 19.2.0.
It means it might never become stable at all or have significant breaking changes.

You can already use it in your projects, but I'd discourage using it in production.

Angular: Beyond the fog #1

Gérôme Grignon — Tue, 13 May 2025 12:29:10 +0000

Since I created Angular Docs AI assistant (powered by Kapa.ia), some questions have been left unanswered due to some level of uncertainty as the AI model faced some limitations.

Discover some of these questions and how a personal understanding of Angular, its ecosystem, and the community helps to provide better answers!

What's new in Angular 20?

As the Angular 20 release is currently planned for 26th May week, the current official documentation is still based on Angular 19. Community content is also quite limited, and a decent amount of it is AI-generated content, providing unverified information.

I'm currently working on providing you with the most up-to-date information about Angular 20, with a dedicated dashboard: feature list, commit history, Can I Use focus, tutorials, and quizzes.

It'll be publicly shared for the Angular 20 release date and will work at creating such content for all future Angular releases, even before they are released!

Why have I heard that constructor based DI may be replaced by the inject function?

The 2 solutions are currently supported, and there is no plan to replace one with the other.

However, part of the upcoming new official style guide is to recommend using the inject function, as explained in the style guide RFC summary.

I need a button component using TailwindCSS v4. Use the purple color

Tailwind is a great project, but unrelated to Angular. You can find the Tailwind color palettes here. You'll have to choose the right value based on your design system and dark/light themes: there is no default 'purple color'.

Is it best to use React or Angular?

Quoting Mark Thompson, Angular Devrel: build great web apps!
And today, you can choose what you like best to create great web apps.

Besides different mindsets, the main difference is that Angular is a full framework with its own official ecosystem, while React is a library. That's not about battling who is a framework or not, but by being a library, React enabled a lot of different ecosystems to grow around it, being both a blessing and a curse, leading to innovation but inconsistency between projects.

My only true recommendation would be to prefer React for mobile or SSR applications, as community projects (Expo for mobile and Next.js for SSR) are more mature and easier to set up.

Should I use ngModel or reactive form controls?

There are just different mindsets: you won't be limited by choosing one over the other.
The community was used to advocate for reactive forms, but lately, more people have been sharing the benefits of using template-driven forms with ngModel. A few years ago, Ward Bell gave a great talk about it: Prefer Template-Driven Forms .

The Angular team started making some experiments with the Signals API to provide a Signals Forms API, but it has not been unveiled yet. It's not part of the upcoming v20.0.0 release. However, we could dream of an experimental version released in some minor v20 version.

I'd encourage you to choose an API and to stick with it for your project's consistency.

How to use effect without a constructor?

You can create a local variable in your class Component to reference an effect, rather than using it in a constructor:

export class MyComponent {
  myEffect = effect(() => {
    console.log("effect");
  });
}

I'd still recommend using the constructor as a way to organize the code and make it more readable.
As you won't need this reference, it avoids creating some conflicts at naming local variables.

How to learn NgRx?

The Angular Docs AI assistant is not shaped to answer about community projects: like any other project, the best solution to get started is to explore the official library documentation.

Mind NgRx now offers three approaches to manage your app state:

@ngrx/store : the original project, inspired by Redux
@ngrx/component-store : to manage component state
@ngrx/signals : a new API to manage state with signals

Discover the original post on Angular courses: https://www.angular.courses/beyond-the-fog/2025-05-13

Introducing Router outlet Input in Angular 19

Gérôme Grignon — Sat, 31 Aug 2024 07:19:56 +0000

In modern frontend frameworks it's common to nest components and share data between them.
Angular provides input binding to pass data from parent to child components. However it only works when the child selector is directly used in the parent template.

Angular 19 introduced, Router outlet Input, a feature available from version 19.0.0-next.0 to pass data directly to components loaded via the router outlet.
With this feature, you can now directly pass data to a routed component, eliminating the need for intermediary services in many cases.

How to use Router outlet Input

Using Router outlet Input is straightforward. Similar to how you pass data to a direct child component using input, you can now pass data to the directive using the new routerOutletData input. Here’s how it works:

Suppose you have an articles signal in your parent component. You can pass it to the router outlet like this:

<router-outlet [routerOutletData]="articles()" />

On the routed component's side, you can access this data using the ROUTER_OUTLET_DATA injection token:

import {ROUTER_OUTLET_DATA} from "@angular/router";

@Component({
 ...
})
export class RoutedComponent {
  data = inject(ROUTER_OUTLET_DATA);
}

The injected data is provided as a Signal<unknown> type. Since Angular doesn’t infer the type, you might want to cast it to the expected type for a better development experience:

import {ROUTER_OUTLET_DATA} from "@angular/router";

@Component({
 ...
})
export class RoutedComponent {
  data = inject(ROUTER_OUTLET_DATA) as Signal<Article[]>;
}

When to use it

Router outlet Input is particularly useful when you need to share data between a parent component and multiple child components routed via the router outlet. Instead of recalculating the same data in each child component, you can compute it once in the parent component and pass it down. This approach not only reduces redundancy but also keeps your child components focused on their specific logic.

For example, imagine you have a list of articles and a sidebar with filters. You can compute the filtered articles in the parent component and pass this data to the router outlet. Each child component can then use this precomputed data in various ways, such as:

Displaying a filtered list of articles
Showing a tag cloud based on the filtered articles
Generating a chart of articles categorized by tags

By updating the filters in the parent component, the new data is reactively updated to the active routed child component. This ensures that your child components always have the latest data without additional computations or service calls.

Conclusion

The introduction of Router Outlet Data Input in Angular 19 is a powerful addition that simplifies data sharing between routed components. By leveraging this feature, you can write more efficient, maintainable, and cleaner Angular applications.

Ready to explore this new feature? Check out the official release notes for more details and start simplifying your Angular apps today!

Common Pitfalls in TypeScript with HTTP Calls

Gérôme Grignon — Fri, 26 Jul 2024 11:44:44 +0000

When working with TypeScript to make HTTP calls, it's easy to fall into certain traps that can lead to unexpected behavior and bugs. In this blog post, we'll discuss three common errors and how to avoid them.

Type Mismatch in HTTP Response

Issue: Typing your HTTP call response in TypeScript doesn't guarantee that the actual response body will match your type.

Explanation: TypeScript's type system only works at compile-time. It helps you catch type errors while writing code, but it doesn't enforce type correctness at runtime. This means that even if you define a type for your HTTP response, there's no guarantee that the server will return data in the expected format.

TypeScript is only about the code you write!

Example:

interface User {
  id: number;
  firstName: string;
  email: string;
}

async function fetchUser(userId: number): Promise<User> {
  const response = await fetch(`https://api.example.com/users/${userId}`);
  const data: User = await response.json();
  return data;
}

In the above example, if the server returns a response where the firstName field is missing or using a different format like first_name, TypeScript won't warn you. The mismatch will only become apparent at runtime.

Solution: Use runtime validation to ensure the response matches the expected type. Libraries like valibot or zod can help with this.
Rather than creating an interface, use a type inferred from a schema and parse the response data with the schema.

Example with zod:

import { z } from "zod";

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string(),
});

type userSchema = z.infer<typeof UserSchema>;

async function fetchUser(userId: number): Promise<User> {
  const response = await fetch(`https://api.example.com/users/${userId}`);
  const data = await response.json();
  return UserSchema.parse(data); // Runtime validation
}

Nested Data in Response

Issue: Some APIs nest the actual data in a response wrapper, often under a data property. If you don't check the response structure, you might end up with incorrect data handling.
It often happen with paginated data where the top level object contains metadata like total, page, perPage, etc.

Besides the requirement for pagination, you might struggle due to your company's API design guidelines. Some people use data while others use result or response.

Example:

{
  "data": {
    "id": 1,
    "name": "Alice",
    "email": "alice@mail.com"
  },
  "total": 1,
  "page": 1
}

In this example, the server response is expected to have a data property that contains the actual user object. If the structure changes, you won't be notified by TypeScript.

Solution: Always check and validate the response structure. Once again using a library like zod can help with this.

Example:

import { z } from "zod";

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string(),
});

const ResponseSchema = z.object({
  data: UserSchema,
});

type User = z.infer<typeof UserSchema>;

async function fetchUser(userId: number): Promise<User> {
  const response = await fetch(`https://api.example.com/users/${userId}`);
  const data = await response.json();
  const parsedData = ResponseSchema.parse(data);
  return parsedData.data;
}

Class Instances from HTTP Responses

Issue: Using a class to type your HTTP response doesn't automatically create instances of that class. The response data will just be plain objects.

Example:

class User {
    constructor(
        public id: number,
        public firstName: string,
        public lastName: string
    ) {
    }

    getFullName(): string {
        return `${this.firstName} <${this.lastName}>`;
    }
}

async function fetchUser(userId: number): Promise<User> {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    const data = await response.json();
    return data as User;
}

In the example above, using getFullName on the returned User object will result in a runtime error because data is not an instance of the User class.

Solution: Manually instantiate the class with the response data.

Example:

class User {
    constructor(
        public id: number,
        public firstName: string,
        public lastName: string
    ) {
    }

    getFullName(): string {
        return `${this.firstName} <${this.lastName}>`;
    }
}

async function fetchUser(userId: number): Promise<User> {
  const response = await fetch(`https://api.example.com/users/${userId}`);
  const data = await response.json();
  return new User(data.id, data.name, data.email);
}

Now, the User instance will have the getDisplayName method available.

Conclusion

TypeScript is a powerful tool for catching type errors at compile-time, but it doesn't enforce type safety at runtime. When dealing with HTTP responses, always validate the response structure and instantiate classes manually to avoid common pitfalls. Using libraries like zod for runtime validation can greatly enhance the reliability of your TypeScript applications.

Announcing RealWorld Angular

Gérôme Grignon — Mon, 22 Jul 2024 11:28:44 +0000

I'm pretty excited to announce this new open-source project!

I've been maintaining RealWorld project for 3 years and decided to create a spin-off to focus on Angular.

Once upon a time... RealWorld

RealWorld is an open-source project created by Albert Pai and Eric Simons back in 2016.
You can find their announcement here.

In a nutshell, it aims to provide examples apps built with different frameworks but still adhering to the same API spec.
If you know TodoMVC, RealWorld is quite about the same philosophy but with more complete examples.

At the time of writing, RealWorld is close to 80k GitHub Stars and includes 204 example apps listed here.

What is RealWorld Angular compared to RealWorld

This new project is a spin-off focusing on Angular.
As RealWorld is about comparing frameworks with a limited list of example apps for each of them (for maintainability reasons), this new project aims to do quite about the same but by showcasing Angular libraries.

Why a spin-off

As an Angular Discord server moderator, questions about recommended example apps are quite common.
But in most situations, examples are limited StackBlitz projects or small demos by Angular library maintainers.

The goal is both to provide a more Real world situation to showcase technical aspects or library integration in an Angular project and to build a great playground with example apps you can test, customize, or update.

Angular app template

RealWorld Angular will provide a demo application and API spec.
But it'll be a new more complete application to open opportunities to enhance it with examples apps:

what about adding i18n?
what about using a state management library?
what about choosing template-driven forms over Reactive Forms?
what about using SSR over CSR?
and so on...

Unlike RealWorld requiring most example apps to start from scratch with a new framework, a GitHub starter template will be provided to focus on details.

RealWorld provided a blogging platform as a demo. RealWorld Angular will provide an event platform demo, with way more situations to showcase Angular features and modern best practices used in web applications.

Where is the template?

This project is built in public and this template is still WIP: the first current step is the creation of the API, built with Nitro.

Community

By focusing on a framework and providing an app template, it'll be easier with this project to engage with the community and create open-source contribution opportunities.
Based on the template, Examples apps will be created on-demand in the GitHub organization, providing Maintainer role to anyone willing to help by contributing to a new example app: Trust by design!

Discover a more complete introduction to RealWorld Angular on the GitHub organization.

Display Angular @empty block at the right time!

Gérôme Grignon — Fri, 08 Mar 2024 12:31:51 +0000

The new Control Flow syntax for Angular has been introduced with Angular 17 release, as a developer preview.

It replaces *ngIf, *ngFor, and *ngSwitch with a new syntax that is more expressive and easier to read.

@for(article of articles$ | async; track article.id) {
  <article>
    <h2>{{ article.title }}</h2>
    <p>{{ article.content }}</p>
  </article>
}

The Angular team added a new feature to enhance the @for block: the @empty block.

The content of this block will be displayed if the list is empty or undefined.

@for(article of articles$ | async; track article.id) {
  <article>
    <h2>{{ article.title }}</h2>
    <p>{{ article.content }}</p>
  </article>
} @empty {
  <p>No articles found</p>
}

The problem

A common misconception is to think that the @empty block is evaluated only once the data is retrieved from an asynchronous call.

In most usecases, you iterate over a list of items retrieved from an API.

As the API call is asynchronous, the list is undefined/empty at the component initialization.

From our point of view:

The list is evaluated as empty
The data is retrieved from the API
The list is evaluated once again and display the empty block if the list is empty

From an end user point of view:

The empty block is displayed at the beginning
The view is updated with the list of items once the data is retrieved if a non-empty list is returned

It means we are displaying the empty block at the wrong time!

For a second (or more depending on your API response time), the user sees the empty block before the list is displayed.
They might think that the list is really empty, while it's not.

The solution

You need to wrap your existing logic to deal with the loading state of the list.

@if(articles$ | async as articles) {
    @for(article of articles; track article.id) {
    <article>
        <h2>{{ article.title }}</h2>
        <p>{{ article.content }}</p>
  </article>
    } @empty {
        <p>No articles found</p>
    }   
} @else {
    <p>Loading...</p>
}

There, instead of displaying the @empty block while you are waiting for the list to be retrieved, you display a loading message.
The @empty block will be evaluated once the list is retrieved and displayed at the right time.

Add a favicon to your Storybook application

Gérôme Grignon — Tue, 21 Feb 2023 10:47:22 +0000

Favicons, short for "favorite icons," are small images or icons that appear in the browser tab, bookmarks, and other areas of the browser UI. Adding a favicon to your Storybook application can help to:

Improve branding and visual appeal: A well-designed favicon can help to reinforce your brand and make your Storybook application more visually appealing.
Enhance user experience: Favicons can make it easier for users to find and recognize your Storybook application among multiple tabs or bookmarks, enhancing the user experience.
Build trust and credibility: A favicon can also help build trust and credibility with your users by demonstrating attention to detail and a commitment to providing a professional and high-quality application.

Adding a favicon is a small but significant step that can help improve the user experience and make your Storybook application more memorable and distinctive.

So why not take this small but impactful step today and give your Storybook application that extra touch of visual appeal and professionalism?

To add a favicon for Storybook, follow these steps:

Create or obtain a favicon file matching the supported formats.
Place the favicon file in the public folder of your Storybook project as defined in your configuration.
Open the .storybook/manager-head.html file in your project, or create it if it doesn't exist.
Add the following code to the file to reference the favicon file:

<link rel="shortcut icon" href="/favicon.ico">

Save the file and restart your Storybook server. Your favicon should now be visible in the browser tab for your Storybook application.

Warning: The default Storybook favicon overrides the new one with Chrome by running the application locally.

Which projects will you contribute to this year?

Gérôme Grignon — Mon, 02 Jan 2023 08:12:09 +0000

Let's jump into this new year by contributing to new open-source projects!
What's your pick?

You shouldn't use EventEmitters in Angular services

Gérôme Grignon — Thu, 06 Jan 2022 09:37:06 +0000

Cover photo by Debby Hudson on Unsplash

By reviewing Angular code daily through mentoring or community support, I happen to find EventEmitters being used in Angular services.

Here is an example with a service dedicated to broadcasting some data to other parts of the application :


export class DataService {
  data: EventEmitter<Data> = new EventEmitter<Data>();

  updateData(data: Data): void {
    this.data.emit(data);
  }
}

By using dependency injection, a component can subscribe to the EventEmitter to receive the emitted values :


export class MyComponent {
  constructor(private readonly dataService: DataService) {}

  ngOnInit() {
    this.dataService.data.subscribe(() => {
      // do whatever you want
    });
  }
}

It works: if another part of the application uses updateData to emit a value, the component will receive it.

So why shouldn't you use it?

Let's take a look at EventEmitter API.
Here is a simplified version of the original EventEmitter codebase based on its usage in the previous code samples :

class EventEmitter extends Subject<any> {
  constructor() {
    super();
  }

  emit(value?: any) {
    super.next(value);
  }

  subscribe(observerOrNext?: any, error?: any, complete?: any): Subscription {
    const sink = super.subscribe({next: observerOrNext, error: error, complete: complete});

    return sink;
  }
}

From creating your EventEmitter to the subscription, you use nothing more than the extended class : a Subject.

The first motivation not to use an EventEmitter over a Subject is to keep it simple stupid (KISS), as a Subject already provides you all you need.

The second reason lies in the original purpose of an EventEmitter as explained in the reference API :

Use in components with the @Output directive to emit custom events synchronously or asynchronously, and register handlers for those events by subscribing to an instance.

By using it for another purpose might lead to bugs if changes occur on this API for the benefit of its original purpose.

How to refactor your codebase

A reminder of the previous usage:

export class DataService {
  data: EventEmitter<Data> = new EventEmitter<Data>();

  updateData(data: Data): void {
    this.data.emit(data);
  }
}

The required changes are:

the type from EventEmitter to Subject
the exposure of the Subject as a private resource for the service to avoid external emissions
the creation of a public Observable version of the Subject you can subscribe to
an update to match the API to emit a new value

export class DataService {
  // change the type and the visibility
  private dataSubject: Subject<Data> = new Subject<Data>();
  // create a public observable out of the subject for external usage
  data$: Observable<Data> = this.dataSubject.asObservable();

  updateData(data: Data): void {
    // update the API
    this.dataSubject.next(data);
  }
}

Such a move is also a great opportunity to explore variant Subjects: BehaviorSubject, ReplaySubject, and AsynSubject.

Happy coding!

[GitHub Actions] Complete CI-CD Javascript Workflow

Gérôme Grignon — Thu, 09 Dec 2021 00:59:51 +0000

Features

This workflow includes common continuous integration/deployment tasks you can easily reuse for any web javascript project.

It includes:

collaboration comments
quality tests
deployment on Netlify
audit with Lighthouse

It works on push and pull request situations.

To showcase this workflow, i chose the Dojo RealWorld implementation.

My Workflow

Repository workflows

Collaboration first!

Alone we can do so little; together we can do so much.
Helen Keller

Open source contributions are not just about code.
That's all about people collaborating to move a project forward.

If the contributor is making their first pull request to the project, welcome them accordingly. First open source contributions can be overwhelming as there so many considerations: code of conduct, license, guidelines...

Even if GitHub makes it easy by onboarding new contributors when they land on a project, don't hesitate to provide additional context:

first_interaction:
    if: github.event_name == 'pull_request'
    name: 'first interaction'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/first-interaction@v1
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          pr-message: |
            Thanks for your first pull request on this project!
            This is a kindly reminder to read the following resources:
            - [code of conduct]()
            - [contribution guidelines]()
            It'll help us to review your contribution and to ensure it's aligned with our standards.

I'm not a new contributor! Who cares?

Not being a new contributor doesn't mean you should be ignored. As a review can be delayed, provide an instant comment to welcome new contributions. Even an automated one shows how much you care:

greetings:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: kerhub/saved-replies@v1.0.0
        with:
          token: "${{ secrets.GITHUB_TOKEN }}"
          reply: |
            Hi @${{ github.event.pull_request.user.login }}, thanks for being part of the community :heart:
            We'll review your contribution as soon as possible!

Reusable workflows

When i started this workflow, i used actions/cache to cache dependencies and speed up the workflows.

- name: Cache node modules
        uses: actions/cache@v2
        env:
          cache-name: cache-node-modules
        with:
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-
            ${{ runner.os }}-build-
            ${{ runner.os }}-

Meanwhile i discovered some changes happened to actions/setup-node in July, removing the need of the previous boilerplate

Time to refactor? Not so much!

Such change didn't affect my workflow as such implementation detail was already hidden in a dedicated and reusable job by using the GitHub new feature: Reusable Workflows

This reusable workflow is isolated in a dedicated repository.

on:
  workflow_call:
    inputs:
      command:
        required: true
        type: string

jobs:
  node_job:
    name: 'node job'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2.4.1
        with:
          node-version: '14'
          cache: 'npm'
      - run: npm ci
      - run: ${{inputs.command}}

Automate quality checks

Note: The quality checks use the previous reusable workflow

Make your code Prettier

Prettier is a famous code formatter.
It removes all original styling* and ensures that all outputted code conforms to a consistent style.

prettier:
    uses: kerhub/reusable-workflows/.github/workflows/node-job.yml@main
    with:
      command: npm run prettier --check \"**\"

Ensure maintainability with a linter

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs.

linter:
    uses: kerhub/reusable-workflows/.github/workflows/node-job.yml@main
    with:
      command: npx eslint --fix src/**/*.ts

Quality means doing it right even when no one is looking.
Henry Ford

The future yourself will thank you for being able to push code with confidence thanks to tests.

unit_tests:
    name: 'unit tests'
    uses: kerhub/reusable-workflows/.github/workflows/node-job.yml@main
    with:
      command: npm run test

Deployment

You don't want to manually deploy anymore.

Review changes before they go live!

You want to preview changes due to a pull request.
Netlify provides a preview feature for such a need!
By running this job on a pull request, a preview url will be created.

deploy_preview:
    name: 'deploy preview'
    if: github.event_name == 'pull_request'
    needs: [prettier, linter, unit_tests]
    uses: kerhub/workflows/.github/workflows/netlify-preview-deploy.yml@main
    with:
      build_directory: './output/dist'
    secrets:
      netlifyAuthToken: "${{ secrets.NETLIFY_AUTH_TOKEN }}"
      netlifySiteId: "${{ secrets.NETLIFY_SITE_ID }}"
      repoToken: "${{ secrets.GITHUB_TOKEN }}"

It uses a reusable workflow once again:

on:
  workflow_call:
    inputs:
      build_directory:
        required: true
        type: string
      build_command:
        required: false
        type: string
        default: 'npm run build'
    secrets:
      repoToken:
        required: true
      netlifyAuthToken:
        required: true
      netlifySiteId:
        required: true

jobs:
  netlify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2.4.1
        with:
          node-version: '14'
          cache: 'npm'
      - run: npm ci
      - run: ${{inputs.build_command}}
      - name: Deploy to Netlify
        uses: nwtgck/actions-netlify@v1.2
        with:
          publish-dir: './output/dist'
          github-token: ${{ secrets.repoToken }}
          deploy-message: "Deploy from GitHub Actions"
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.netlifyAuthToken }}
          NETLIFY_SITE_ID: ${{ secrets.netlifySiteId }}

Push to production!

By pushing code directly or by merging a pull request, this job will deploy a new version of your web app.

deploy_live:
    name: 'deploy live'
    if: github.event_name == 'push'
    needs: [prettier, linter, unit_tests]
    uses: kerhub/workflows/.github/workflows/netlify-live-deploy.yml@main
    with:
      build_directory: './output/dist'
    secrets:
      netlifyAuthToken: "${{ secrets.NETLIFY_AUTH_TOKEN }}"
      netlifySiteId: "${{ secrets.NETLIFY_SITE_ID }}"

It uses a reusable workflow once again:

on:
  workflow_call:
    inputs:
      build_directory:
        required: true
        type: string
      build_command:
        required: false
        type: string
        default: 'npm run build'
    secrets:
      netlifyAuthToken:
        required: true
      netlifySiteId:
        required: true

jobs:
  netlify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2.4.1
        with:
          node-version: '14'
          cache: 'npm'
      - run: npm ci
      - run: ${{inputs.build_command}}
      - name: Deploy to Netlify
        uses: nwtgck/actions-netlify@v1.2
        with:
          publish-dir: './output/dist'
          production-deploy: true
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.netlifyAuthToken }}
          NETLIFY_SITE_ID: ${{ secrets.netlifySiteId }}

Audit

Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.

By pushing changes to your repository, it shouldn't affect performance and common best practices.

The workflow includes 2 jobs for such a need:

a preview one for the custom preview url (related reusable workflow)
a live one using the production url (related reusable workflow)

lighthouse_preview:
    name: 'lighthouse preview'
    needs: deploy_preview
    uses: kerhub/reusable-workflows/.github/workflows/lighthouse-preview.yml@main
    with:
      siteName: 'dojo-realworld'
    secrets:
      netlifyAuthToken: "${{ secrets.NETLIFY_AUTH_TOKEN }}"
  lighthouse_live:
    name: 'lighthouse live'
    needs: deploy_live
    uses: kerhub/reusable-workflows/.github/workflows/lighthouse-live.yml@main
    with:
      siteUrl: 'https://dojo-realworld.netlify.app/'

Are we really done yet?

Open source contribution requires to spend significant time on it as you need to:

understand its goal to ensure your contribution will match
to read all guidelines
to wait for a review before your contribution

Such dedication on a project worths to greet the contributor, not to just merge their work.

But...there is no pull_request merged event.
To identify a merged content, you need 2 informations:

the event (push)
the merged status of the pull request

Here is the solution i used in a dedicated workflow:

on:
  pull_request:
    types: closed

jobs:
  contribution-greetings:
    if: github.event.pull_request.merged
    runs-on: ubuntu-latest
    steps:
      - name: greet the contributor
        uses: kerhub/saved-replies@v1.0.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          reply: |
            Thanks @${{ github.event.pull_request.user.login }}!
            Your contribution is now fully part of this project :rocket:

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

Workflow YAML Files:

Additional Resources / Info

GitHub Actions used:

GitHub Reusable Workflows created: