DEV Community: Davide Passafaro

Angular Meets Generative AI: Best Practices Made Easy

Davide Passafaro — Tue, 26 Aug 2025 07:27:28 +0000

The use of generative AI to produce code is becoming increasingly popular in the developer world. From creating quick prototypes to scaffolding entire features, AI tools are no longer just assistants, they’re starting to become part of our workflow.

With Angular v20.2, a new CLI command allows you to generate a dedicated configuration file for AI models. This file defines project-specific guidelines, enabling generative AI to apply best practices, follow established coding patterns, and implement new functionality while remaining consistent with your codebase.

Let’s walk through how to generate this file and explore the set of rules it contains.

🤖 Generating the AI Configuration Files

Starting with Angular CLI v20.2, when creating a new project, the CLI prompts you to choose whether to include an AI configuration file:

ng new app

You’ll then be prompted to choose one or more AI tools to configure:

? Which AI tools do you want to configure with Angular best practices? 
  See: https://angular.dev/ai/develop-with-ai

❯ ◉ None  
  ◯ Claude                 [ https://docs.anthropic.com/en/docs/claude-code/memory ]  
  ◯ Cursor                 [ https://docs.cursor.com/en/context/rules ]  
  ◯ Gemini                 [ https://ai.google.dev/gemini-api/docs ]  
  ◯ GitHub Copilot         [ https://code.visualstudio.com/docs/copilot/copilot-customization#_custom-instructions ]  
  ◯ JetBrains AI Assistant [ https://www.jetbrains.com/help/junie/customize-guidelines.html ]  
  ◯ Windsurf               [ https://docs.windsurf.com/windsurf/cascade/memories#rules ]

The Angular CLI will generate a separate configuration file for each tool you select, placing it in its designated path:

Gemini → .gemini/GEMINI.md
Copilot → .github/copilot-instructions.md
Claude → .claude/CLAUDE.md
Cursor → .cursor/rules/cursor.mdc
JetBrains → .junie/guidelines.md
Windsurf → .windsurf/rules/guidelines.md

If you already know which AI tool you want to configure, you can skip the prompt and pass it directly as an option:

ng new app --ai-config=gemini
ng new app --ai-config=copilot
ng new app --ai-config=claude
ng new app --ai-config=cursor
ng new app --ai-config=jetbrains
ng new app --ai-config=windsurf

And if you skip this step, you can always add the configuration later in an existing project using one of the following commands:

# Start the prompt to choose which AI tool(s) to configure
ng generate ai-config

# Generate the AI configuration for a specific tool (Gemini in this example)
ng generate ai-config --tool=gemini

🔍 Let’s Analyze the Configuration File

The generated files have the same format for each selected AI tool.

Note: the Cursor file also includes some metadata, nothing to worry about

AI context for code generation

At the top of the file, a context is given to the AI:

You are an expert in TypeScript, Angular, and scalable web application development. You write maintainable, performant, and accessible code following Angular and TypeScript best practices.

This helps guide the AI to produce suggestions and scaffolding that align with the conventions and best practices for your Angular project.

Sections and rules

The rest of the file is then divided into several sections, each defining more context and rules for a specific area of development:

TypeScript Best Practices
Angular Best Practices
Components
State Management
Templates
Services

Here’s the full configuration file with all sections and rules:

## TypeScript Best Practices

- Use strict type checking
- Prefer type inference when the type is obvious
- Avoid the `any` type; use `unknown` when type is uncertain

## Angular Best Practices

- Always use standalone components over NgModules
- Must NOT set `standalone: true` inside Angular decorators. It's the default.
- Use signals for state management
- Implement lazy loading for feature routes
- Do NOT use the `@HostBinding` and `@HostListener` decorators. Put host bindings inside the `host` object of the `@Component` or `@Directive` decorator instead
- Use `NgOptimizedImage` for all static images.
  - `NgOptimizedImage` does not work for inline base64 images.

## Components

- Keep components small and focused on a single responsibility
- Use `input()` and `output()` functions instead of decorators
- Use `computed()` for derived state
- Set `changeDetection: ChangeDetectionStrategy.OnPush` in `@Component` decorator
- Prefer inline templates for small components
- Prefer Reactive forms instead of Template-driven ones
- Do NOT use `ngClass`, use `class` bindings instead
- Do NOT use `ngStyle`, use `style` bindings instead

## State Management

- Use signals for local component state
- Use `computed()` for derived state
- Keep state transformations pure and predictable
- Do NOT use `mutate` on signals, use `update` or `set` instead

## Templates

- Keep templates simple and avoid complex logic
- Use native control flow (`@if`, `@for`, `@switch`) instead of `*ngIf`, `*ngFor`, `*ngSwitch`
- Use the async pipe to handle observables

## Services

- Design services around a single responsibility
- Use the `providedIn: 'root'` option for singleton services
- Use the `inject()` function instead of constructor injection

As you can see, each section contains non-opinionated rules and focuses almost exclusively on using the new Angular APIs over the older ones.

For example, prefer the new Angular Control Flow directives (@if, @for, @switch) instead of *ngIf, *ngFor, and *ngSwitch. Similarly, use Signals and the input()/output() APIs over their older alternatives.

Add your own rules

If you’d like, you’re free to extend the configuration with your own rules, such as naming conventions, ordering preferences, or any other coding standards that better fit your team’s workflow.

You can either add new rules to the existing sections or create entirely new sections if needed.

For instance, a dedicated NgRx section could look like this:

## NgRx Best Practices

- Use feature-specific state slices rather than a single global state object.
- Always define action types using a `[Feature] Event` convention (e.g., `[Auth] Login Success`).
- Group effects logically per feature and keep side-effects outside of components.
- Avoid deeply nested state structures; normalize data when possible.

This file should be treated like code, but written in natural language. Structuring it thoughtfully and keeping it clean and organized is not trivial and should be done with care, just like any other code file.

📖 Useful Links for Further Reading

🎉 Thanks for Reading! Until Next Time! 🚀

If you found this useful, I’d love to hear your thoughts. Drop a comment, give a like, or follow me to stay in the loop. I’ll appreciate it! 👏

Share it with friends, colleagues, or anyone passionate about Angular.
Let’s connect on LinkedIn! 👋😁

Angular Deep Signal: Modeling State in Depth

Davide Passafaro — Mon, 04 Aug 2025 21:01:24 +0000

With the introduction of Signals in Angular, state management has become much clearer, more maintainable, and predictable.

Thanks to primitives like signal(), computed(), and effect(), you can model and derive data effectively while keeping dependencies between different parts of the state under control.

However, updating deep values of a Signal is not as straightforward, often requiring manual interventions on the parent state.

To address this need, the Angular team is currently developing a new Signal primitive that allows reactive access and modification of deep properties within another Signal: Deep Signal.

In this article, you'll explore what Deep Signals are, how they work, and why they can help simplify the code in your Angular applications.

🎯 Accessing and Updating Deep State

Let’s consider an application that manages a user’s personal data.

This is a very common scenario, where the application state contains information such as the user’s first name, last name, and city of residence:

const userModel = signal({
  name: 'Davide',
  lastname: 'Passafaro',
  city: 'Rome'
  }
});

Thanks to computed(), you can easily derive values from this state, for example, to get the user’s first name and city:

const userName = computed(() => userModel().name);

const userCity = computed(() => userModel().city);

Now, suppose you want to allow the user to update their info via a form.

Thanks to ngModel, you can directly bind the form inputs to the Signals:

<p>Nome: <input type="text" [(ngModel)]="userName()"></p>

<p>Città: <input type="text" [(ngModel)]="userCity()"></p>

However, here arises a problem: values derived from computed() are read-only and therefore cannot be updated directly.

The ngModel directive, on the other hand, expects to be able to both read from and write to the associated model.

Linked Signal: a workaround, not exactly a solution

To update a deep property, you are forced to manually modify the parent state by creating a dedicated function.

Following the example, you can define an updateCity function like this:

function updateCity(newCity: string) {
  userModel.update(user => ({ ...user, city: newCity }));
}

At this point, you then connect this function to the form input, explicitly handling the change event:

<p>
  Città:
  <input
    type="text"
    [ngModel]="userCity()"
    (ngModelChange)="updateCity($event)"
  />
</p>

This solution, although functional, is not inherently reactive: it relies on an explicit call to the updateCity() function, leaving you responsible for maintaining state consistency.

And there are no guarantees that this will always happen systematically.

To work around this limitation, you can use linkedSignal(): a function that allows creating a derived Signal that is also writable.

By combining this with an effect(), you can achieve a sort of two-way synchronization between the derived value and the main state:

const userModel = signal({
  name: 'Davide',
  lastname: 'Passafaro',
  city: 'Rome'
  }
});

const userCity = linkedSignal(
  () => () => userModel().city
);

effect(() => {
  userModel.set({...userModel(), city: userCity())
});

In this scenario, the value of userCity() is derived from userModel(), but it can also be directly updated via userCity.set().

Your form becomes much more straightforward:

<p>Nome: <input type="text" [(ngModel)]="userName()"></p>

<p>Città: <input type="text" [(ngModel)]="userCity()"></p>

Every change to userCity() is intercepted by the effect(), which accordingly updates the main state. This way, you achieve a manual, homemade two-way synchronization.

Awesome!!!

Well, not exactly…

You do solve the problem, but at the cost of increased complexity:

Why do you use linkedSignal() instead of a simple computed()?
And why do you need that effect()?

These are all questions that future maintainers of the code, or even the future ourselves, might ask when faced with unclear code that doesn’t clearly explain the “why” behind the choices made.

For this reason, we need a more robust, natively bidirectional solution that doesn’t rely on manual workarounds and remains clear and explicit for anyone who reads or maintains the code in the future.

This is exactly where Deep Signals come into play.

🧬 The new Deep Signal primitive

With the new Deep Signal primitive, Angular introduces a robust and declarative solution for managing deep state.

A Deep Signal allows you to directly access and modify nested properties inside a Signal reactively and bidirectionally.

How to create a Deep Signal

As with other primitives, Angular provides a dedicated function, deepSignal(), to create a Deep Signal:

const userModel = signal({
  name: 'Davide',
  lastname: 'Passafaro',
  city: 'Rome'
  }
});

const userCity = deepSignal(userModel, 'city');

The deepSignal() function accepts two parameters: the parent Signal containing the state from which you want to extract a property, and the key that identifies that property within the structure, expressed either as a string or as a Signal containing a string.

The value returned by deepSignal() is effectively a bidirectional Signal: you can read its value just like with a normal computed(), but you can also update it directly using the set() or update() methods, without having to manually reconstruct the parent state.

In the example:

console.log(userCity()); // Prints "Rome"

userCity.set('Turin');   // Updates userModel().city

Being a Signal, it can then be used seamlessly within templates as well:

<p>Città: <input type="text" [(ngModel)]="userCity()"></p>

The ngModel directive is now fully compatible: every change to the input field will directly update the deep state inside userModel(), and vice versa.

This approach drastically reduces the necessary boilerplate and improves code readability and consistency, making access and updates to nested state portions more straightforward, explicit, and safe.

Performance of Deep Signals

Deep Signals are not only more convenient to use but also bring significant performance advantages.

As previously said, without them, updating a nested property requires updating the parent Signal:

const userModel = signal({
  name: 'Davide',
  lastname: 'Passafaro',
  city: 'Rome'
  }
});

userModel.set({...userModel(), city: 'Turin');

This means that even the smallest change, like updating just the city property, will trigger all effects and derived states that depend on any part of the parent userModel state.

Therefore, even those only interested in name or lastname will be notified, and every derived state will be recalculated. These will then detect that their data hasn’t actually changed and will skip further updates.

But still, the performance cost remains significant, especially in applications with complex states or many connected effects.

Deep Signal solves this problem through a more granular and targeted dependency management: it updates nested properties directly, notifying only those listening to that specific portion of the state.

This way, only the effects and derived states that care about the modified property are notified, drastically reducing the number of unnecessary notifications and recalculations, with clear performance benefits.

But that’s not all.

🧱 Structural Signals: When Structure Matters

The introduction of Deep Signals paves the way for another very useful Signal primitive: Structural Signals.

A Structural Signal is derived from a WritableSignal and returns its full value, similar to a Computed Signal, in this form:

const userModel = signal({
  name: 'Davide',
  lastname: 'Passafaro',
  city: 'Rome'
  }
});

const computedUserModal = computed(() => userModel());

The only significant difference is that a Structural Signal is not notified when changes occur through a Deep Signal.

It only detects changes when the parent Signal is updated directly.

By combining Structural Signals and Deep Signals, you can achieve more granular and intelligent control over updates, avoiding unnecessary triggers caused by new references that don’t actually change the content:

const userModel = signal({
  name: 'Davide',
  lastname: 'Passafaro',
  city: 'Rome'
});

// Structural Signal: returns the entire object
const userSnapshot = structuralSignal(userModel);

// Deep Signal: accesses a specific nested property
const userCity = deepSignal(userModel, 'city');

// Effect that reacts only to full structural changes
effect(() => {
  console.log('🧱 Structural update:', userSnapshot());
});

// Effect that reacts only to changes in the city property
effect(() => {
  console.log('🌍 City changed:', userCity());
});

// Update only the city: triggers only the Deep Signal effect
userCity.set('Milan');
// Output:
// 🌍 City changed: Milan

// Structural update (new object): triggers both effects
userModel.set({
  name: 'Davide',
  lastname: 'Passafaro',
  city: 'Turin'
});
// Output:
// 🌍 City changed: Turin
// 🧱 Structural update: { name: 'Davide', lastname: 'Passafaro', city: 'Turin' }

In this example, you can observe a precise behavior:

If you update only userCity through the Deep Signal, only those listening to that property (like the first effect()) will be notified.
If you replace the entire userModel object, structural observers (like the second effect()) will also be notified.

✅ Final Thoughts

The introduction of Deep Signals and Structural Signals is an exciting addition to the Angular ecosystem.

Being able to update derived state within a Signal directly is a major step forward for code readability, maintainability, and performance.

That said, something is still missing.

Currently, Deep Signals only support nested properties at a single level of depth. It’s not yet possible to reactively access deeper properties or state derived from more complex computations.

These limitations don’t take away from the value of the new primitives, they’re just a clear signal (badum-tss 🥁) of the direction Angular is heading. With each new release, it’s becoming more powerful and flexible.

All that’s left for us is to wait, ready to play with the next innovations. 🤓

Useful links for further reading

Deep signal, deep magic — Angular PR #62962

Thanks for reading! 🫶🏻

If you enjoyed the read and found it useful, leave a comment, like, or hit follow to stay in the loop. I’ll appreciate it! 👏

Don’t forget to share it with your community, tech friends, or anyone who might find it helpful! And follow me on LinkedIn, let’s connect! 👋😁

Exploring Angular httpResource: a new approach to async data fetching

Davide Passafaro — Thu, 20 Mar 2025 11:16:31 +0000

In the past two years, Angular has embarked on a journey to revolutionize its reactive model, introducing signals as core primitives for synchronous reactivity within the framework. More recently, this journey has expanded into the realm of asynchronous reactivity with the new Resource API.

With the latest updates, Angular has gone even further by introducing a specialized resource type: httpResource. This addition extends the Resource API, offering a more efficient way to handle HTTP requests.

In this article, I’ll explore how httpResource works and how to use it in real-world scenarios, starting with a quick refresh of the Resource API.

The Resource API

The Angular Resource API is designed to simplify asynchronous resource loading by leveraging signals.

It offers a streamlined approach to managing data requests, tracking loading states, and automatically refreshing data when the signals on which the resource depends change.

How to use a Resource?

To use a resource, you can use the resource() function, where you define:

A request function that returns the parameters for the async request;
A loader function that fetches data based on the request parameters.

Here’s a simplified example:

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

const RESOURCE_URL = 'https://jsonplaceholder.typicode.com/todos/';

private id = signal(1);

private myResource = resource({
    request: () => ({ id: this.id() }),
    loader: ({ request }) => fetch(RESOURCE_URL + request.id),
});

A resource automatically tracks the request parameters and, whenever they are updated, fetches new data using the loader function.

Most importantly, it monitors the status of the data-fetching operation, tracking the resource’s current value, status, and any errors.

For more details about the Resource API, including its lifecycle, error handling, and how to consume a resource, check out my previous article:

Angular resource() and rxResource() APIs: what you need to know

Davide Passafaro ・ Jan 1 '25

#angular #frontend #webdev #javascript

Now that we’ve had a good refresh on the Resource API, let’s dive into the new httpResource. 💪🏻

The httpResource

An httpResource is a specialized type of resource designed to handle HTTP requests and expose all related request information via signals.

httpResponse( ) function

To create an httpResource you can easily use the httpResource() function:

import { signal } from '@angular/core';
import { httpResource, HttpResourceRequest } from '@angular/common/http';
import { Todo } from './todo.model';

const RESOURCE_URL = 'https://jsonplaceholder.typicode.com/todos/';

id = signal(1);

staticHttpResource = httpResource<Todo>(
    RESOURCE_URL + this.id()
);

reactiveHttpResource = httpResource<Todo>(
    () => RESOURCE_URL + this.id()
);

configuredHttpResource = httpResource<Todo>(
    { url: RESOURCE_URL + this.id() } as HttpResourceRequest
);

reactiveConfiguredHttpResource = httpResource<Todo>(
    () => ({ url: RESOURCE_URL + this.id() } as HttpResourceRequest)
);

Note: similar to a resource, an httpResource requires an injection context to be created. You can create one as a directive variable, instantiate it inside the constructor, or provide a specific injection context upon creation.

The httpResource() function requires only one parameter, which can be:

A string, representing the URL from which to fetch the data;
A reactive function that returns a string, the resource will fetch the data from the new URL whenever it changes due to a signal update;
An object of type HttpResourceRequest, which allows specifying additional details such as headers and request body;
A reactive function that returns a HttpResourceRequest object, the resource will fetch the data with the new request parameters whenever this object changes due to a signal update.

This flexibility allows httpResource() to adapt to various application needs, simplifying asynchronous resource consumption in a declarative way.

Under the hood, the provided parameter value is used to generate a function that creates an HttpRequest. This function is then passed to the basic resource implementation as the request function.

By providing reactive functions, httpResource can track to signal changes, ensuring the resource updates dynamically when dependencies change.

Note: you can find a detailed explanation of HttpResourceRequest below 👇🏻

Configure the Resource with HttpResourceOptions

The httpResource() function accepts an optional second parameter of type HttpResourceOptions, allowing you to specify the following properties:

defaultValue: the value that the resource will take in Idle, Loading, or Error states. If not specified, the resource will default to undefined;
parse: a function that processes the raw response of the http request before assigning it to the resource value. If not specified, TypeScript will infer the provided type through a type assertion. It allows validation, transformation, or schema enforcement:

import { httpResource} from '@angular/common/http';
import { defaultUser, isValidUser, toUser } form './user.utils';

userResource =
  httpResource<User>(() => `/users/${userId()}`, {
    defaultValue: defaultUser,
    parse: (raw) => {
      if (!isValidUser(raw)) {
        throw new Error("Invalid user data received");
      }
      return toUser(raw);
    },
  });
}

injector: overrides the Injector used by the httpResource instance to destroy itself when the parent component or service is destroyed;
equal: equality function used to compare the response value.

Fetching data types other than JSON

By default, an httpResource assumes the response type is JSON.

In order to request a different type of data, you can use specific variants of httpResource() function provided by httpResource:

httpResource.text(): to handle responses in plain text format;
httpResource.blob(): to handle binary data, such as images or files;
httpResource.arrayBuffer(): to handle raw binary data as ArrayBuffer.

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

// Fetching plain text
textResource = httpResource.text(() => '/api/endpoint', {
  defaultValue: ''
});

// Fetching binary data (e.g., image)
imageResource = httpResource.blob(() => '/api/image', {
  defaultValue: new Blob()
});

// Fetching raw binary data as ArrayBuffer
arrayBufferResource = httpResource.arrayBuffer(() => '/api/data', {
  defaultValue: new ArrayBuffer(0)
});

HttpClient integration and Interceptors support

Under the hood, httpResource leverages on the HttpClient, so to use it, you need to provide it to your component or service, usually via provideHttpClient or by importing HttpClientModule.

This integration allows you to leverage any HttpInterceptor you have in place for request transformation, authentication handling, and error management. This way, you can seamlessly integrate httpResource into your existing app while fully benefiting from your existing HTTP setup.

Note: the HttpClient implementation may be removed in future updates, but it’s likely that an alternative solution will be provided to ensure continued functionality. So, keep an eye on future updates! 🫣

Real-World Use Cases

Theory is great, but it’s the practical implementation that truly matters.
Let’s dive into some real-world examples using httpResource.

Forms and Search optimizations

When building dynamic forms or search features, optimizing data requests is essential. One of the most common strategies is to reduce unnecessary API calls by controlling when and how requests are triggered.

This is easily achievable by tracking input changes and applying techniques to ensure requests are only made when the user has stopped typing or when the input value actually changes.

When dealing with Observable-based events, you can use operators like debounceTime to delay emissions until a specified time has passed without new values, or distinctUntilChanged to ensure only unique values are emitted.

However, since signals do not rely on the concept of time like Observables, these strategies cannot be applied directly when using httpResource.

In order to work around this limitation, you can combine the power of signals and Observables by leveraging the toObservable() and toSignal() functions provided by the @angular/core/rxjs-interop library.

This allows you to transform signals into Observables, enabling you to apply operators like debounceTime and distinctUntilChanged, and then convert the results back into a signal that you can use inside the httpResource.

import { signal } from '@angular/core';
import { httpResource } from '@angular/common/http';
import { toObservable, toSignal } from '@angular/core/rxjs-interop';

const RESOURCE_URL = 'https://jsonplaceholder.typicode.com/todos/';

id = signal(1);

// Convert the signal into an observable and apply debounceTime
idQuery$ = toObservable(this.id).pipe( debounceTime(3000) );

// Convert the observable back to a signal
query = toSignal(this.idQuery$);

// Use the query signal inside httpResource to fetch data
myResource = httpResource.text(
  // This is triggered only after the debounce
  () => RESOURCE_URL + this.query()
);

Note: the distinctUntilChanged operator is not not necessary here because signals already avoid emitting unless their value actually changes. 🤓

This hybrid approach gives you the flexibility to use time-based strategies while retaining the efficiency and simplicity of httpResource and signals.

Great! 🤩

Disabling the request without destroying the resource

In some cases, you might want to disable the request without destroying the resource entirely. For instance, when data fetching should only happen after a specific user action, such as clicking a button.

Instead of making the request immediately, you can conditionally enable it based on certain conditions, like so:

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

const RESOURCE_URL = 'https://jsonplaceholder.typicode.com/todos/';

id = signal(1);
shouldFetchData = signal(false);

myResource = httpResource<User[]>(() => {
  const shouldFetchData = this.shouldFetchData(); // Custom condition
  return shouldFetchData ? `${RESOURCE_URL}${this.query()}` : undefined;
});

In this example, httpResource will only trigger the API request if the shouldFetchData signal is set to true.

If the condition is false, the function returns undefined, preventing any API call from being made and resetting the values of the httpResource.

Returning undefined is not the best, but it still gets the job done. 😅

HttpResourceRequest in detail

Providing an HttpResourceRequest object to the httpResource() function allows you to specify additional details for customizing the HTTP request made by the httpResource, enabling you to define the following properties:

url: the URL of the request. It should not include query parameters, which can be specified through the dedicated params property;
method: the HTTP method for the request. By default, the value is GET;
body: the body to include in the request. If no Content-Type header is specified, Angular will try to set one based on the body type.
params: query parameters to append to the URL, either as HttpParams or an object with key-value pairs, where values can be strings, numbers, booleans, or arrays of these types;
headers: headers to include with the request, either as HttpHeaders or a plain object with header names as keys and string or array values;
context: dictionary of key-value pairs to store additional context for the request, allowing it to carry custom metadata for handling or logging;
reportProgress: if set to true, enables progress events for the request. These events are provided through the HttpResource.progress signal;
withCredentials: specifies whether to set the withCredentials flag on the outgoing request. When true, it allows the browser to send cookies and authentication information with the request;
transferCache: configures the server-side rendering transfer cache for the request. It can be a boolean or an object with an includeHeaders array that specifies which headers to include in the transfer cache.

Designed for fetching data only

Even though you can define a different HTTP method using HttpResourceRequest, the new httpResource is primarily designed for fetching data, just like the fundamental Resource API.

This flexibility is provided to allow the API to consume data that doesn’t necessarily align with standard HTTP specifications.

However, it’s important to note that it is not safe to use an httpResource, or any resource, to save/delete data in such a way, as each update could abort previously initiated requests. As a result, operations like POST, PUT, or DELETE may not be guaranteed to complete successfully.

Thanks for reading! 🫶🏻

I’m excited an honored to share that I’ve officially become a Google Developer Expert (GDE) in Angular! 🎉

Thank you all for your support, I promise I’ll be writing more frequently, as this just got serious now. 😜🚀

If you enjoyed the read and found it useful, leave a comment, like, or hit follow to stay in the loop. I’ll appreciate it! 👏

Don’t forget to share it with your community, tech friends, or anyone who might find it helpful! And follow me on LinkedIn, let’s connect! 👋😁

Angular resource() and rxResource() APIs: what you need to know

Davide Passafaro — Wed, 01 Jan 2025 15:00:00 +0000

The release of Angular v19, just a few weeks ago, marks a significant milestone in the signal revolution within the framework, with the Input, Model, Output and Signal Queries APIs now officially promoted to stable.

But that's not all! This major version also introduces powerful new tools designed to further advance the signal revolution: the new Resource API.

As the name suggests, this new Resource API is designed to simplify loading asynchronous resources by harnessing the full power of signals!

IMPORTANT: at the time of writing, the new Resource API is still experimental. This means it may change before becoming stable, so use it at your own risk. 😅

Let's dive into how it works and how it simplifies handling async resources!

The Resource API

Most signal APIs are synchronous, but in real-world applications, it is essential to handle asynchronous resources, such as fetching data from a server or managing user interactions in real-time.

This is where the new Resource API comes into play.

Using a Resource, you can easily consume an asynchronous resource via signals, allowing you to easily manage data fetching, handle loading states, and trigger a new fetch whenever the associated signal parameters change.

resource( ) function

The easier way to create a Resource is by using the resource() function:

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

const RESOURCE_URL = 'https://jsonplaceholder.typicode.com/todos/';

private id = signal(1);

private myResource = resource({
    request: () => ({ id: this.id() }),
    loader: ({ request }) => fetch(RESOURCE_URL + request.id),
});

This function accepts a ResourceOptions configuration object as input, allowing you to specify the following properties:

request: a reactive function that determines the parameters used to perform the request to the asynchronous resource;
loader: a loading function that returns a Promise of the resource's value, optionally based on the provided request parameters. This is the only required property of ResourceOptions;
equal: equality function used to compare the loader's return value;
injector: overrides the Injector used by the Resource instance to destroy itself when the parent component or service is destroyed.

Thanks to these configurations, we can easily define an asynchronous dependency that will always be consumed efficiently and kept up-to-date.

Resource life cycle

Once a Resource is created, the loader function is executed, then the resulting asynchronous request starts:

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

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

const id = signal(1);
const myResource = resource({
  request: () => ({ id: id() }),
  loader: ({ request }) => fetch(RESOURCE_URL + request.id)
});
console.log(myResource.status()); // Prints: 2 (which means "Loading")

Whenever a signal that the request function depends on changes, the request function runs again, and if it returns new parameters, the loader function is triggered to fetch the updated resource's value:

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

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

const id = signal(1);
const myResource = resource({
  request: () => ({ id: id() }),
  loader: ({ request }) => fetch(RESOURCE_URL + request.id)
});

console.log(myResource.status()); // Prints: 2 (which means "Loading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 4 (which means "Resolved")
console.log(myResource.value()); // Prints: { "id": 1 , ... }

id.set(2); // Triggers a request, causing the loader function to run again
console.log(myResource.status()); // Prints: 2 (which means "Loading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 4 (which means "Resolved")
console.log(myResource.value()); // Prints: { "id": 2 , ... }

If no request function is provided, the loader function will run only once, unless the Resource is reloaded using the reload method (more below).

Finally, once the parent component or service is destroyed, the Resource is also destroyed unless a specific injector has been provided.

In such cases, the Resource will remain active and be destroyed only when the provided injector itself is destroyed.

Aborting requests with abortSignal

To optimize data fetching, a Resource can abort an outstanding requests if the request() computation changes while a previous value is still loading.

To manage this, the loader() function provides an abortSignal, which you can pass to ongoing requests, such as fetch. The request listens for the abortSignal and cancels the operation if it's triggered, ensuring efficient resource management and preventing unnecessary network requests:

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

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

const id = signal(1);
const myResource = resource({
  request: () => ({ id: id() }),
  loader: ({ request, abortSignal }) =>
    fetch(RESOURCE_URL + request.id, { signal: abortSignal })
});

console.log(myResource.status()); // Prints: 2 (which means "Loading")

// Triggers a new request, causing the previous fetch to be aborted
// Then the loader function to run again generating a new fetch request
id.set(2);

console.log(myResource.status()); // Prints: 2 (which means "Loading")

Based on this, it's recommended to use the Resource API primarily for GET requests, as they are typically safe to cancel without causing issues.

For POST or UPDATE requests, canceling might lead to unintended side effects, such as incomplete data submissions or updates. However, if you need similar functionality for these types of requests, you can use the effect() method to safely manage the operations.

How to consume a Resource

The Resource API provides several signal properties for its state, that you can easily use directly within your components or services:

value: contains the current value of the Resource, or undefined if no value is available. As a WritableSignal, it can be manually updated;
status: contains the current status of the Resource, indicating what the Resource is doing and what can be expected from its value;
error: if in the error state, it contains the most recent error raised during the Resource load;
isLoading: indicates whether the Resource is loading a new value or reloading the existing one.

Here's an example of how to consume a Resource within a component:

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

const BASE_URL = 'https://jsonplaceholder.typicode.com/todos/';

@Component({
  selector: 'my-component',
  template: `
    @if (myResource.value()) {
      {{ myResource.value().title }}
    }

    <button (click)="fetchNext()">Fetch next item</button>
  `
})
export class MyComponent {
  private id = signal(1);

  protected myResource = resource({
    request: () => ({ id: this.id() }),
    loader: ({ request }) =>
      fetch(BASE_URL + request.id).then((response) => response.json()),
  });

  protected fetchNext(): void {
    this.id.update((id) => id + 1);
  }
}

In this example, the Resource is used to fetch data from an API based on the value of the id signal, which can be incremented by clicking a button.

Whenever the user clicks the button, the id signal value changes, triggering the loader function to fetch a new item from the remote API.

The UI automatically updates with the fetched data thanks to the signals properties exposed by the Resource API.

Check the status of a Resource

As mentioned earlier, the status signal provides information about the current state of the resource at any given moment.

The possible values of the status signal are defined by the ResourceStatus enum. Here's a summary of these statuses and their corresponding values:

Idle = 0: the Resource has no valid request and will not perform any loading. value() is undefined;
Error = 1: the loading has failed with an error. value() is undefined;
Loading = 2: the resource is currently loading a new value as a result of a change in its request. value() is undefined;
Reloading = 3: the resource is currently reloading a fresh value for the same request. value() will continue to return the previously fetched value until the reloading operation completes;
Resolved = 4: the loading is completed. value() contains the value returned from the loader data-fetching process;
Local = 5: the value was set locally via set() or update(). value() contains the value manually assigned.

These statuses help track the Resource's progress and facilitate better handling of asynchronous operations in your application.

hasValue( ) function

Given the complexity of these statuses, the Resource API provides a hasValue() method, which returns a boolean based on the current status.

This ensures accurate information about the Resource's status, providing a more reliable way to handle asynchronous operations without relying on the value, which might be undefined in certain states.

hasValue() {
  return (
    this.status() === ResourceStatus.Resolved ||
    this.status() === ResourceStatus.Local ||
    this.status() === ResourceStatus.Reloading
  );
}

This method is reactive, allowing you to consume and track it like a signal.

isLoading( ) function

The Resource API also provides an isLoading signal, which returns whether the resource is currently in the Loading or Reloading state:

readonly isLoading = computed(
  () =>
    this.status() === ResourceStatus.Loading ||
    this.status() === ResourceStatus.Reloading
);

Since isLoading is a computed signal, it can be tracked reactively, allowing you to monitor the loading state in real-time using signals APIs.

Resource value as a WritableSignal

The value signal provided by a Resource is a WritableSignal, which allows you to update it manually using the set() and update() functions:

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

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

const id = signal(1);
const myResource = resource({
  request: () => ({ id: id() }),
  loader: ({ request }) => fetch(RESOURCE_URL + request.id)
});

console.log(myResource.status()); // Prints: 2 (which means "Loading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 4 (which means "Resolved")
console.log(myResource.value()); // Prints: { "id": 1 , ... }

myResource.value.set({ id: 2 });
console.log(myResource.value()); // Prints: { id: 2 }
console.log(myResource.status()); // Prints: 5 (which means "Local")

myResource.value.update((value) => ({ ...value, name: 'Davide' });
console.log(myResource.value()); // Prints: { id: 2, name: 'Davide' }
console.log(myResource.status()); // Prints: 5 (which means "Local")

Note: as you can see, manually updating the value of the signal will also set the status to 5, which means "Local", to indicate that the value was set locally.

The manually set value will persist until either a new value is set or a new request is performed, which will override it with a new value:

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

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

const id = signal(1);
const myResource = resource({
  request: () => ({ id: id() }),
  loader: ({ request }) => fetch(RESOURCE_URL + request.id)
});

console.log(myResource.status()); // Prints: 2 (which means "Loading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 4 (which means "Resolved")
console.log(myResource.value()); // Prints: { "id": 1 , ... }

myResource.value.set({ id: 2 });
console.log(myResource.value()); // Prints: { id: 2 }
console.log(myResource.status()); // Prints: 5 (which means "Local")

id.set(3); // Triggers a request, causing the loader function to run again
console.log(myResource.status()); // Prints: 2 (which means "Loading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 4 (which means "Resolved")
console.log(myResource.value()); // Prints: { "id": 3 , ... }

Note: the value signal of the Resource API uses the same pattern of the new LinkedSignal API, but does not use it under the hood. 🤓

Convenience wrappers methods

To simplify the use of the value signal, the Resource API provides convenience wrappers for the set, update, and asReadonly methods.

The asReadonly method is particularly useful as it returns a read-only instance of the value signal, allowing access only for reading and preventing any accidental modifications.

You can use this approach to create services that manage and track changes to resource values by exporting a read-only instance of the value:

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

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

export class MyService {
  const id = signal(1);

  const myResource = resource({
    request: () => ({ id: id() }),
    loader: ({ request }) => fetch(RESOURCE_URL + request.id })
  });

  public myValue = myResource.value.asReadonly();

  setValue(newValue) {
    // Wrapper of `myResource.value.set()`
    myResource.set(newValue);
  }

  addToValue(addToValue) {
    // Wrapper of `myResource.value.update()`
    myResource.update((value) => ({ ...value, ...addToValue });
  }
}

// Usage of the service in a component or other part of the application
const myService = new MyService();

myService.myValue.set(null); // Property 'set' does not exist in type 'Signal'

myService.setValue({ id: 2 });
console.log(myService.myValue()); // Prints: { id: 2 }

myService.addToValue({ name: 'Davide' });
console.log(myService.myValue()); // Prints: { id: 2, name: 'Davide' }

This will prevent consumers from modifying the value, reducing the risk of unintended changes, improving consistency in complex data management.

Reload or destroy a Resource

When working with asynchronous resources, you may face scenarios where refreshing the data or destroy the Resource becomes necessary.

To handle these scenarios, the Resource API provides two dedicated methods that offer efficient solutions for managing these actions.

reload( ) function

The reload() method instructs the Resource to re-execute the asynchronous request, ensuring it fetches the most up-to-date data:

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

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

const id = signal(1);
const myResource = resource({
  request: () => ({ id: id() }),
  loader: ({ request }) => fetch(RESOURCE_URL + request.id)
});

console.log(myResource.status()); // Prints: 2 (which means "Loading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 4 (which means "Resolved")

myResource.reload(); // Returns true if a reload was initiated
console.log(myResource.status()); // Prints: 3 (which means "Reloading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 5 (which means "Local")

The reload() method returns true if a reload is successfully initiated.

If a reload cannot be performed, either because it is unnecessary, such as when the status is already Loading or Reloading, or unsupported, like when the status is Idle, the method returns false.

destroy( ) function

The destroy() method manually destroys the Resource, destroying any effect() used to track request changes, canceling any pending requests, and setting the status to Idle while resetting the value to undefined:

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

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

const id = signal(1);
const myResource = resource({
  request: () => ({ id: id() }),
  loader: ({ request }) => fetch(RESOURCE_URL + request.id)
});

console.log(myResource.status()); // Prints: 2 (which means "Loading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 4 (which means "Resolved")

myResource.destroy(); // Returns true if a reload was initiated
console.log(myResource.status()); // Prints: 1 (which means "Idle")
console.log(myResource.value()); // Prints: undefined

After a Resource is destroyed, it will no longer respond to request changes or reload() operations.

Note: at this point, while the value signal remains writable, the Resource will lose its intended purpose and no longer serves its function, becoming useless. 🙃

rxResource( ) function

Like nearly all signal-based APIs introduced so far, the Resource API also offers an interoperability utility for seamless integration with RxJS.

Instead of using the resource() method to create a Promise-based Resource, you can use the rxResource() method to use Observables:

import { resource, signal } from "@angular/core";
import { rxResource } from '@angular/core/rxjs-interop';
import { fromFetch } from 'rxjs/fetch';

const RESOURCE_URL = "https://jsonplaceholder.typicode.com/todos/";

const id = signal(1);
const myResource = rxResource({
  request: () => ({ id: id() }),
  loader: ({ request }) => fromFetch(RESOURCE_URL + request.id)
});

console.log(myResource.status()); // Prints: 2 (which means "Loading")

// After the fetch resolves

console.log(myResource.status()); // Prints: 4 (which means "Resolved")
console.log(myResource.value()); // Prints: { "id": 1 , ... }

Note: the rxResource() method is in fact exposed by the rxjs-interop package.

The Observable produced by the loader() function will consider only the first emitted value, ignoring subsequent emissions.

Thanks for reading so far 🙏

Thank you all for following me throughout this wonderful 2024. 🫶🏻

It has been a year full of challenges, but also very rewarding. I have big plans for 2025 and I can't wait to start working on them. 🤩

I’d like to have your feedback so please leave a comment, like or follow. 👏

Then, if you really liked it, share it among your community, tech bros and whoever you want. And don’t forget to follow me on LinkedIn. 👋😁

Angular Forms new unified control state change events

Davide Passafaro — Mon, 10 Jun 2024 15:18:49 +0000

The release of Angular v18 brought a bunch of exciting new features and improvements to the framework.

One of these features is particularly promising, as it introduces a new capability within the Angular Forms library, by enhancing the AbstractControl class with unified control state change events.

As usual in my articles, before delving into the main topic, let's first review some fundamentals. This will help you better grasp the upcoming contents.

Angular Reactive Forms: the fundamentals

Angular Reactive Forms offer a model-driven approach to handling form inputs, providing synchronous access to the data model, powerful tools for inputs validation and change tracking through Observables.

The Reactive Forms data model is composed using the following classes:

FormControl: represents a single form input, its value is a primitive;
FormGroup: represents a group of FormControl, its value is an object;
FormArray: represents a list of FormControl, its value is an array.

A common example of form can be represented by a FormGroup like this:

import { FormGroup, FormControl, FormArray } from '@angular/forms';

const articleForm = new FormGroup({
  title: "new FormControl(''),"
  content: new FormControl(''),
  tags: new FormArray([])
});

Note: there is also the FormRecord class, an extension of the FormGroup class, which allows you to dynamically create a group of FormControl instances.

All these classes, hereafter referred to just as controls, are derived from the AbstractControl class, and thus share common properties and methods.

Template binding

Angular Reactive Forms model-driven approach is powered by various directives provided by the library itself, which facilitate the integration of form controls with HTML elements.

Let's take the following FormGroup as an example:

this.articleForm = new FormGroup({
  author: new FormGroup({
    name: new FormControl(''),
  }),
  tags: new FormArray([ new FormControl('Angular') ]),
});

You can easily bind it to the template using the provided directives:

<form [formGroup]="articleForm">
  <div formGroupName="author">
    <input formControlName="name" />
  </div>

  <div formArrayName="tags">
    <div *ngFor="let tag of tags.controls; index as i">
      <input [formControlName]="i" />
    </div>
  </div>
</form>

What is important to remember, without delving into an exhaustive but out-of-scope explanation, is that the FormGroupDirective allows us to easily create a button to reset the form and a button to submit its value:

<form [formGroup]="articleForm">
  <!-- form template -->

  <button type="reset">Clear</button>
  <button type="submit">Save</button>
</form>

The FormGroupDirective intercepts the click events emitted by these buttons to trigger the control's reset() function, which resets the control to its initial value, and the directive's ngSubmit output event.

Listening for value changes

In order to listen for value changes to perform custom operations, you can subscribe to the valueChanges observable of the control you want to track:

myControl.valueChanges.subscribe(value => {
  console.log('New value:', value)
});

Disabled controls

Each control can be set to disabled, preventing users from editing its value. This mimics the behavior of the HTML disabled attribute.

To accomplish this, you can either create a control as disabled, or use the disable() and enable() and functions to toggle this status:

import { FormControl } from '@angular/forms';

const myControl = new FormControl({ value: '', disabled: true });
console.log(myControl.disabled, myControl.enabled) // true, false

myControl.enable();
console.log(myControl.disabled, myControl.enabled) // false, true

myControl.disable();
console.log(myControl.disabled, myControl.enabled) // true, false

As you can notice in the example above, the AbstractControl class provides two dedicated properties to describe this status: disabled and enabled.

Validators

To enforce specific rules and ensure that your controls meet certain criteria, you can also specify some validation rules, or validators.

Validators can be synchronous, such as required or minLength, or asynchronous, to handle validation that depends on external resources:

import { FormControl, Validators } from '@angular/forms';
import { MyCustomAsyncValidators } from './my-custom-async-validators.ts';

const myFormControl = new FormControl('', {
  validators: [ Validators.required, Validators.minLength(3) ],
  asyncValidators: [ MyCustomAsyncValidators.validate ]
});

Based on these rules, the AbstractControl class provides also some properties that describe the status of the validity:

valid: a boolean indicating whether the control value passed all of its validation rules tests;
invalid: a boolean indicating whether the control value passed all of its validation rules tests; It is the opposite of the valid property;
pending: a boolean indicating whether the control value is in the process of conducting a validation check.

FormControlStatus

Both the disabled status and the validation status are interconnected.
In fact, they are derived by the status property, which is typed as follows:

type FormControlStatus = 'VALID' | 'INVALID' | 'PENDING' | 'DISABLED';

Note: valid, invalid, pending, enabled and disabled properties are indeed just getters derived from the status property 🤓

Pristine and Touched

The AbstractControl class provides also several properties that describe how the user has interacted with the form:

pristine: a boolean indicating whether the control is pristine, meaning it has not yet been modified;
dirty: boolean indicating whether the control has been modified;
untouched: a boolean indicating whether the control has not yet been touched, meaning that it has not been interacted with yet;
touched: a boolean indicating whether the control has been touched.

Now that we've revisited some of the fundamentals of Angular Reactive Forms, it's finally time to introduce the main topic of this article.

New unified control state change events

Starting from Angular v18, the AbstractControl class now exposes a new events observable to track all control state change events.

Thanks to this, you can now monitor FormControl, FormGroup and FormArray classes through the following events: PristineEvent, PristineEvent, StatusEvent and TouchedEvent.

myControl.events
  .pipe(filter((event) => event instanceof PristineChangeEvent))
  .subscribe((event) => console.log('Pristine:', event.pristine));

myControl.events
  .pipe(filter((event) => event instanceof ValueChangeEvent))
  .subscribe((event) => console.log('Value:', event.value));

myControl.events
  .pipe(filter((event) => event instanceof StatusChangeEvent))
  .subscribe((event) => console.log('Status:', event.status));

myControl.events
  .pipe(filter((event) => event instanceof TouchedChangeEvent))
  .subscribe((event) => console.log('Touched:', event.touched));

These capabilities are very powerful, especially because, apart from the valueChange, it was previously not easy to properly track the state changes.

Additionally to this, the FormGroup class can also emit two additional events through the events observable: FormSubmittedEvent and FormResetEvent.

myControl.events
  .pipe(filter((event) => event instanceof FormSubmittedEvent))
  .subscribe((event) => console.log('Submit:', event));

myControl.events
  .pipe(filter((event) => event instanceof FormResetEvent))
  .subscribe((event) => console.log('Reset:', event));

Both the FormSubmittedEvent and FormResetEvent are inherited by the FormGroupDirective and are, in fact, emitted only by the directive itself.

Additional insights

Thanks to this new addition, the following AbstractControl methods have been updated to support the emitEvent parameter:

markAsPristine(): marks the control as pristine;
markAsDirty(): marks the control as dirty;
markAsTouched(): marks the control as touched;
markAsUntouched(): marks the control as untouched;
markAllAsTouched(): marks the control and its descendant as touched.

Thanks for reading so far 🙏

I’d like to have your feedback so please leave a comment, like or follow. 👏

Then, if you really liked it, share it among your community, tech bros and whoever you want. And don’t forget to follow me on LinkedIn. 👋😁

Angular fallback content in ng-content

Davide Passafaro — Wed, 08 May 2024 17:54:25 +0000

Angular v18 recently introduced a new feature to easily define a fallback content in ng-content elements. In this article, I will discuss about it.

However, before diving into it, I will also explore how it was already possible to achieve the same result in Angular v17 or earlier versions.

When building flexible and reusable UI components, content projection stands as a fundamental tool at your disposal. It is a pattern in which you insert, or project, the content you want to use inside another component.

When configuring a component, defining a fallback content can be useful to ensure something is displayed if no content is provided.

Define fallback content in ng-content elements

Up until Angular v18, there was not a built-in support to fallback content for ng-content. However, this didn’t imply there was no workaround.

Let’s take a look at one of the potential implementation strategies:

import { Component, ElementRef, computed, viewChild } from '@angular/core';

@Component({
  standalone: true,
  selector: 'my-component',
  template: `
    @if(!hasContent()){
      <div> Default content </div>
    }

    <div #wrapper>
      <ng-content></ng-content>
    </div>
  `,
})
export class MyComponent {
  wrapper = viewChild.required<ElementRef<HTMLDivElement>>('wrapper');

  hasContent = computed(
    () => this.wrapper().nativeElement.innerHTML.length > 0
  );
}

The idea behind it is to wrap the ng-content within an element, and utilize the viewChild API to determine whether there is projected content or not.

Then, based on that, the fallback content is displayed using the @if API provided by the new control flow, or the ngIf directive.

Note: in older versions of Angular you may need to refactor this a bit, but I hope the concept of this strategy is clear. If not please feel free to contact me 🫶🏻

Angular v18: fallback content in ng-content

Starting from Angular v18, implementing a fallback content in ng-content elements is extremely easier.

You just need to put the fallback content inside the ng-content tag:

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

@Component({
  standalone: true,
  selector: 'my-component',
  template: `
    <ng-content select="header"> Default header </ng-content>

    <ng-content> Default main content </ng-content>

    <ng-content select="footer"> Default footer </ng-content>
  `,
})
export class MyComponent {}

As you can see, this new feature allows you to easily define a dedicated fallback content for each ng-content element in your component.

So, considering the following example:

<my-component>
  <footer> New footer </footer>
</my-component>

The resulting template will be:

Default header

Default main content

<footer> New footer </footer>

Note: before Angular v18, this would result in an error being thrown ❌

Fallback content strategies limitations

It is important to highlight that both strategies share the same limitation: Angular content projection is evaluated on component creation.

This means that if you render the projected content conditionally, for example using an @if condition or the ngIf directive, the fallback content will not be displayed, even if the associated condition is set to false.

This limitation can be easily overcome, with different solutions depending on the specific use case you might have, but it’s important to remember about it when implementing the strategies I’ve presented.

Thanks for reading so far 🙏

I’d like to have your feedback so please leave a comment, like or follow. 👏

Then, if you really liked it, share it among your community, tech bros and whoever you want. And don’t forget to follow me on LinkedIn. 👋😁

Redirecting Guards and Resolvers in Angular v18 with RedirectCommand

Davide Passafaro — Mon, 29 Apr 2024 07:00:00 +0000

In the modern era of web development, creating dynamic and interactive applications has become the norm. Implementing features that are exclusive to certain users, or available under specific conditions, can be a very complex challenge.

For this reason, Angular offers a routing system based on Routes, rules and components, enabling you to can easily design your applications.

In this article, I will discuss about safeguarding Routes redirecting the user elsewhere, using also a new feature introduced in Angular v18.

But before we proceed, let's have a brief review about Angular Router…

Angular Router Guards and Resolvers

Angular Router library allows you to manage navigation within your Angular application, defining a list of Routes.

Each Route is defined by a series of information, such as the path to access it, the Angular component to load, child Routes and much more:

import { Route } from '@angular/router';
import { MyFeatureComponent, MyFeatureGuard } from './my-feature';

const routes: Route[] = [
  {
    path: 'my-feature',
    component: MyFeatureComponent,
    canActivate: [MyFeatureGuard],
    data: {
      id: "my-feature-id"
    }
  }
];

You can protect one or more Routes, restricting the access or the exit, based on certain conditions, using functions called Guards:

import { Route } from '@angular/router';
import { MyService } from './my-feature';

const myRoute: Route = [
  path: 'my-feature',
  canMatch: [() => inject(MyService).canMatch()],
  canActivate: [() => inject(MyService).canActivate()],
  canActivateChild: [() => inject(MyService).canActivateChild()],
  canDeactivate: [() => inject(MyService).canDeactivate()],
];

There are four types of Angular Guards, each with a different role:

canMatch: used to verify that a Route can be loaded. You can define multiple Routes for a single path and use this guard to select only one based on certain conditions;
canActivate: used to determine whether a user can activate a particular Route. For example, you can use it to control access to pages reserved only for certain users;
canActivateChild: similar to canActivate, but it controls also the access to child Routes of a main Route. It runs on every navigation towards a child Route, even if it started from another child Route;
canDeactivate: used to verify whether a user can exit a given Route. For example, you can use it to ask for confirmation before leaving a page.

Note: originally, Guards were implemented as Injectable services. Following the introduction of the inject() function, it was possible to define them as functions. As a result, Injectable Guards are currently deprecated.

Furthermore, you can use Resolver functions to prepare data for a Route:

import { Route } from '@angular/router';
import { MyService } from './my-feature';

const myRoute: Route = [
  path: 'my-feature',
  resolve: {
    user: () => inject(MyService).getUserInfo(),
    config: () => inject(MyService).getUserConfig()
  }
];

Using Resolvers is a great approach to ensure the presence of data before accessing a Route, avoiding to deal with missing data in a page.

Now that I covered the basics, let's see how to protect your Routes by redirecting users elsewhere.

Use Guards and Resolvers to redirect navigation

Angular Guards allow you to prevent access or exit to one or more Routes, blocking navigation.

However, to ensure a smoother user experience, it is often preferable to redirect the user to another Route.

Thanks to Guards, we can achieve this very easily, starting a new navigation before blocking the current one:

import { inject } from '@angular/core';
import { Route, Router } from '@angular/router';
import { MyPage } from './pages/my-page';

const route: Route = {
  path: 'my-page',
  component: MyPage,
  canActivate: [
    () => {
      const router = inject(Router);

      router.navigate(['./my-other-page']);
      return false;
    },
  ],
};

You can achieve a similar result using the Resolvers, starting a new navigation inside them:

import { Route, Router } from '@angular/router';
import { MyService } from './my-feature';

const myRoute: Route = [
  path: 'my-feature',
  resolve: {
    user: () => {
      const router = inject(Router);

      router.navigate(['./my-other-page']);
      return null;
    }
  }
];

Redirect with UrlTree

Alternatively, you can redirect navigation by having Guards and Resolvers return a UrlTree representing the new Route:

import { inject } from '@angular/core';
import { Route, Router, UrlTree } from '@angular/router';
import { MyPage } from './pages/my-page';

const route: Route = {
  path: 'my-page',
  component: MyPage,
  canActivate: [
    () => {
      const router: Router = inject(Router);

      const urlTree: UrlTree = router.parseUrl('./my-other-page');
      return urlTree;
    },
  ],
};

However, this technique does not allow you to redirect navigation using NavigationExtras, as allowed by the previous technique:

canActivate: [
  () => {
    const router = inject(Router);

    router.navigate(['./my-other-page'], { skipLocationChange: true });
    return false;
  }
]

Redirect with RedirectCommand

To overcome this, Angular v18 introduces a new RedirectCommand class capable of handling NavigationExtras, enabling you to redirect navigation in Guards and Resolvers:

import { inject } from '@angular/core';
import { RedirectCommand, Route, Router, UrlTree } from '@angular/router';
import { MyPage } from './pages/my-page';

const route: Route = {
  path: 'my-page',
  component: MyPage,
  canActivate: [
    () => {
      const router: Router = inject(Router);
      const urlTree: UrlTree = router.parseUrl('./my-other-page');

      return new RedirectCommand(urlTree, { skipLocationChange: true });
    },
  ],
};

The introduction of this new RedirectCommand class ensures great maintainability for Guards and Resolvers.

Having been designed specifically for these use cases, it can be easily extended to adapt to any necessary new parameters in the future.

Thanks for reading so far 🙏

I’d like to have your feedback so please leave a comment, like or follow. 👏

Then, if you really liked it, share it among your community, tech bros and whoever you want. And don’t forget to follow me on LinkedIn. 👋😁

Angular new output() function

Davide Passafaro — Wed, 24 Apr 2024 07:00:00 +0000

During latest months, Angular v17 has introduced a set of new function-based APIs focused on enhance Signal integration within components and directives. This includes Signal Inputs, Model Inputs and Signal Queries.

Considering the full picture, we are only missing one core API to conclude this journey, and this article is dedicated to precisely that: Angular v17.3.0 latest addition, the new output() function.

The new `output()` API

Similar to the function-based APIs introduced so far, you now have a brand new output() function designed to replace the @Output decorator.

To declare an output, you can now use the output() function when we declare a property of a component or directive:

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

@Component({
  selector: 'my-component',
  standalone: true,
  template: `<button (click)="emitClick($event)">Click here</button>`,
})
export class MyComponent {

  buttonClick = output<MouseEvent>();

  alias = output<MouseEvent>({ alias: 'aliasClick' });

  emitClick(event: MouseEvent): void {
    this.buttonClick.emit(event);
    this.alias.emit(event);
  }
}

As you can see from the example, this API also supports the alias property and exposes the emit() function.

Furthermore, you can listen for the output event in the parent components, using Angular event binding syntax in the template:

<my-component
  (buttonClick)="myFunction($event)"
  (aliasClick)="myFunction($event)"
/>

So far, everything works almost identically to @Output decorator-based outputs.

Let’s now move on to the subscribe() function, which brings some changes.

How to subscribe to outputs programmatically

Using the output() function you get an instance of type OutputEmitterRef:

buttonClick: OutputEmitterRef<MouseEvent> = output<MouseEvent>();

In addition to the already mentioned emit() method, which has remained unchanged on the surface, this class also exposes a subscribe() method to listen to the event programmatically:

import { Component, Signal, effect, viewChild } from '@angular/core';
import { MyComponent } from './my-component';

@Component({
  selector: 'my-parent-component',
  standalone: true,
  imports: [MyComponent],
  template: `<my-component />`,
})
export class MyParentComponent {
  myComponentRef: Signal<MyComponent> = viewChild.required(MyComponent);

  constructor() {
    effect(() => {

      this.myComponentRef().myOutput.subscribe((event: MouseEvent) => {
        console.log('Manual subscription:', event);
      });

    });
  }
}

The subscription generated by this class is not based on RxJs, so you can’t use the pipe() function and operators. Nevertheless, it still exposes an unsubscribe() function to terminate it programmatically:

const subscription = this.myComponentRef().myOutput.subscribe(
 (event: MouseEvent) => {
   // Unsubscribes to listen only the first event, if any
   subscription.unsubscribe();
  }
);

It is also automatically completed when the component, or directive, is destroyed.

New rxjs-interop functions

To further enhance the capabilities of this new API, two additional functions have been introduced in the RxJs Interop package.

`outputFromObservable()`

Thanks to the brand new outputFromObservable() function, you can now create an output starting from an Observable.

The generated output emits each new value emitted by the Observable:

import { Component, OutputRef } from '@angular/core';
import { outputFromObservable } from '@angular/core/rxjs-interop';
import { interval } from 'rxjs';

@Component({
  selector: 'my-timer-component',
  standalone: true,
  template: `...`,
})
export class MyTimerComponent {

 timer: OutputRef<number> = outputFromObservable(interval(1000));

 timerAlias = outputFromObservable(interval(1000), { alias: 'timerChange' });

}

Both the Observable and the output are automatically completed when the component, or directive, is destroyed.

If an error occurs, the Observable is interrupted, consequently the output stops emitting and the error propagates (if not caught).

`outputToObservable()`

Thanks to the new outputToObservable() function we can instead transform an output into an Observable:

import { Component, Signal, effect, viewChild } from '@angular/core';
import { outputToObservable } from '@angular/core/rxjs-interop';
import { MyComponent } from './my-component';

@Component({
  selector: 'my-parent-component',
  standalone: true,
  imports: [MyComponent],
  template: `<my-component />`,
})
export class MyParentComponent {
  myComponentRef: Signal<MyComponent> = viewChild.required(MyComponent);

  constructor() {
    effect(() => {

      outputToObservable(this.myComponentRef().myOutput)
        .subscribe((event: MouseEvent) => {
          console.log('Manual subscription:', event);
        });

    });
  }
}

Again, both the Observable and the output are automatically completed when the component, or directive, is destroyed.

Furthermore, due to the absence of errors in the outputs, the resulting Observable never emits error notifications.

Thanks for reading so far 🙏

I’d like to have your feedback so please leave a comment, like or follow. 👏

Then, if you really liked it, share it among your community, tech bros and whoever you want. And don’t forget to follow me on LinkedIn. 👋😁

Angular HostAttributeToken: the new way to inject attributes

Davide Passafaro — Sun, 21 Apr 2024 22:00:00 +0000

Over the latest months Angular has been evolving rapidly, introducing new features and a ton of improvements, many of these with the aim of improving maintainability and performance.

In this article I want to introduce you to the latest addition brought by Angular v17.3.0: the new HostAttributeToken class.

This new API allows you to inject host attributes using the inject() function, similar to the functionality of the @Attribute decorator.

The @Attribute decorator is perhaps the lesser-known Angular decorators.
Therefore, before delving into how the HostAttributeToken class works, let’s take a moment to review the fundamentals.

@Attribute: do you really need an input?

Let’s start from a simple scenario in which you want to develop a component requiring a configurable property.

Specifically, you want to provide this property as a constant string literal, because it will not change throughout runtime:

<my-divider size="small" />

What you would normally do is to create an input for that property:

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

export type DividerSize = 'small' | 'big';

@Component({
  selector: 'my-divider',
  template: '<hr [class]="size" />',
  standalone: true,
})
export class MyDivider {
  @Input() size: DividerSize;
}

Which is fine and works quite well. Perhaps too much…

By creating an input, you are instructing Angular to create a binding to that property and check it during each change detection cycle.

That is really excessive, you only need that property to be checked once during component initialization. 🤯

To make this more performant you can instead inject the host-element attribute in the constructor thanks to the @Attribute decorator:

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

export type DividerSize = 'small' | 'big';

@Component({
  selector: 'my-divider',
  template: '<hr [class]="size" />',
  standalone: true,
})
export class MyDivider {
  constructor(@Attribute('size') size: string) {}
}

Using @Attribute, Angular will read the value only once and never again.

Note: This approach works as well with Directives, feel free to give it a shot!!!

Now that we have covered the basics, let me introduce you to the main topic of this article: new HostAttributeToken class.

Inject an Attribute using HostAttributeToken class

Since the release of Angular 14 there is now a cleaner approach to inject providers without using the constructor class: the inject() function.

Up until now, this inject() function allowed to inject easily components, directives and pipes, but it was missing a method to inject host attributes.

And that’s precisely why the HostAttributeToken class was introduced:

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

export type DividerSize = 'small' | 'big';

@Component({
  selector: 'my-divider',
  template: '<hr [class]="size" />',
  standalone: true,
})
export class MyDivider {
  size: string = inject( new HostAttributeToken('size') );
}

By injecting an HostAttributeToken class within the inject function, you get the corresponding host-element attribute value.

This new API works similarly to @Attribute, with a notable difference: instead of returning null when the attribute is missing, it throws an error.

This change was made to align the behavior with other injection tokens.

Thanks for reading so far 🙏

I’d like to have your feedback so please leave a comment, like or follow. 👏

Then, if you really liked it, share it among your community, tech bros and whoever you want. And don’t forget to follow me on LinkedIn. 👋😁

Angular Signal Queries: Simplifying DOM Querying

Davide Passafaro — Mon, 15 Apr 2024 07:00:00 +0000

Following Signal Inputs and Model Inputs, another Signal API has landed in the Angular ecosystem with the release of v17.2.0: Signal Queries.

Signal Queries offer an alternative approach to the decorator-based queries, namely @ViewChild, @ViewChildren, @ContentChild and @ContentChildren, supplying query results as a Signal.

With queries, you can retrieve references to components, directives, DOM elements, and more. Let’s see what has changed with Signal Queries.

View queries

View queries allow you to retrieve and interact directly with elements in a component’s own template, also known as view.

Both @ViewChild and @ViewChildren now have a Signal counterpart.

viewChild

Using the new viewChild() function you can retrieve a single element:

import { Component, ElementRef, Signal, viewChild } from '@angular/core';

@Component({
  selector: 'my-component',
  standalone: true,
  template: '<input #inputEl />',
})
export class MyComponent {
  inputElement: Signal<ElementRef | undefined> = viewChild('inputEl');
}

This function accepts every parameter that @ViewChild supports and offers the same functionalities, providing you the query result as a Signal.

When a query does not find any result its value is undefined, this happens commonly using Control Flow statement like @if and @for.
Because of this, a viewChild() Signal value type is ElementRef | undefined.

If you are sure about the presence of at least one matching result, you can use the dedicated viewChild.required() function and get rid of undefined:

import { Component, ElementRef, Signal, viewChild } from '@angular/core';

@Component({
  selector: 'my-component',
  standalone: true,
  template: '<input #inputEl />',
})
export class MyComponent {
  inputElement: Signal<ElementRef> = viewChild.required('inputEl');
}

But be careful, when a required query fails to find any results, Angular throws a dedicated error:

viewChildren

Using the new viewChildren() function you can retrieve multiple elements:

import { Component, ElementRef, Signal, viewChildren } from '@angular/core';

@Component({
  selector: 'my-component',
  standalone: true,
  template: `
    <input #inputEl />

    @if (showSecondInput) {
      <input #inputEl />
    }
  `,
})
export class MyComponent {
  showSecondInput = true;

  inputElementList: Signal<readonly ElementRef[]> = viewChildren('inputEl');
}

Similarly to viewChild() API, the viewChildren() function accepts every parameter that @ViewChildren supports and offers the same functionalities, providing you the query result as a Signal.

When a viewChildren() query does not find any result, its value is an empty array, this guarantees the results array is always initialized.

Content queries

Content queries allow you to retrieve and interact directly with elements in a component’s content.

A component’s content is represented by the elements provided thought content projection, nesting elements inside the component tag in the template where it is used. For example:

<my-component>
  <span> Hello ;) </span>

  <input #inputEl />
</my-component>

Note: apart for the target template where the queries are performed, content queries APIs and view queries APIs work identically.
Because of that the next section of the article totally relies on the previous one.

Similar to our previous discussion on view queries, both @ContentChild and @ContentChildren now have as well a Signal counterpart.

contentChild

Using the new contentChild() and contentChild.required() functions you can retrieve a single element:

import { Component, contentChild, ElementRef, Signal } from '@angular/core';

@Component({
  selector: 'my-component',
  standalone: true,
  template: `
    <div>
      <ng-content />
    </div>
  `,
})
export class MyComponent {
  inputElement: Signal<ElementRef | undefined> = contentChild('inputEl');

  inputElementReq: Signal<ElementRef> = contentChild.required('inputEl');
}

Identically to the viewChild() function, when a required contentChild() function query fails to find any results, Angular throws a dedicated error:

contentChildren

Using the contentChildren() function you can retrieve multiple elements:

import { Component, contentChildren, ElementRef, Signal } from '@angular/core';

@Component({
  selector: 'my-component',
  standalone: true,
  template: `
    <div>
      <ng-content />
    </div>
  `,
})
export class MyComponent {
  inputElementList: Signal<readonly ElementRef[]> = contentChildren('inputEl');
}

Identically to the viewChildren() function, when a contentChildren() query does not find any result, its value is an empty array.

Some rules you need to be careful

This new functions, viewChild(), viewChildren(), contentChild() and contentChildren(), only work if used to declare queries by initializing a component or a directive property.

Calling them outside of component and directive property initialization will produce no error, but the query will not find any result:

import { Component, ElementRef, Signal, viewChild } from '@angular/core';

@Component({
  selector: 'my-component',
  standalone: true,
  template: `
    <div #el></div>
  `,
})
export class MyComponent {
  el = viewChild('el'); // It works!

  constructor() {
    const myEl: Signal<undefined> = viewChild('el'); // No error
    console.log(myEl()); // undefined
  }
}

Signal Queries vs Decorator Queries

Having the queries results as Signals means that we can compose them with other Signals, using computed() and effect() functions.

This is a significant advantage, as it enhances the flexibility and functionality of our codebase, leading the way to all the improvements in change detection that Signals brought to the framework.

In addition to that, Signal Queries offer other benefits:

More predictable timing: query results are accessible as soon as they’re available;
Simpler API surface: every query result is provided as a Signal, and queries with multiple results (viewChildren() and contentChildren()) return always a defined array;
Improved type safety: cases with undefined as possible result are fewer, thanks to required() functions and default array for multiple results;
More accurate type inference: TypeScript can infer more accurate types when a type predicate is used or when you explicit a read option;
Lazier updates: as for all Signals, Angular updates queries results lazily. This means that the read operation are performed only when your code explicitly reads the query results.

Thanks for reading so far 🙏

I’d like to have your feedback so please leave a comment, like or follow. 👏

Then, if you really liked it, share it among your community, tech bros and whoever you want. And don’t forget to follow me on LinkedIn. 👋😁

Angular Model Inputs: two-way binding inputs with Signals

Davide Passafaro — Tue, 09 Apr 2024 07:00:00 +0000

Angular journey towards the full integration of Signals has moved forward with the latest release of Angular v17.2.0, introducing a new API to allow two-way binding with Signal Inputs: Model Inputs.

Before proceeding, I kindly suggest you to read my previous article “Angular Signal Inputs: road to Signal Components”, in which you will found a more exhaust explanation about the advantages of Signal Inputs:

Angular Signal Inputs: road to Signal Components

Davide Passafaro ・ Apr 6 '24

#angular #frontend #webdev #javascript

This article is strictly connected to the previous, and is meant to fulfill the open point about the two-way binding with Signal Inputs.

Now that Model Inputs are available it’s time to deepen them.

How to create a Model Input

Just like Signal Inputs, Model Inputs are meant to replace inputs created with the @Input decorator, exposing the input value as a Signal.

To create a Model Input you just need to use the model() function provided by @angular/core package:

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

@Component({ ... })
export class MyComponent {
  myProp: ModelSignal<string | undefined> = model<string>();
}

Your input will be typed as ModelSignal, a special type of Signal that Angular internally updates whenever a new value is bound.

The update( ) function

Two-way binding allows both parent and child components to update the value of a bonded input and to share then the same identical value.

To enable the update from the child component, ModelSignal API exposes a dedicated update() function to update an input based on the current value:

updateProp(): void {
  this.myProp.update((current) => current + ' - Updated!!!');
}

The two-way binding

Using Angular’s two-way binding syntax when binding a value from the parent component to the child component, the ModelSignal update from the child component will therefore go back up to the parent component:

<my-component
  [(myProp)]="parentProp"
  (myPropChange)="onPropChangeMethod($event)"
></my-component>

Both parent and child component will have the property value synced.
The parent component will also get an output notification named as the input name with “Change” appended, carrying the new value as event object.

Model Inputs with default and required values

As you probably noticed in the previous examples, by creating a Model Input you can provide to the model() function a type argument to define the type of the ModelSignal value:

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

@Component({ ... })
export class MyComponent {
  myProp: ModelSignal<string | undefined> = model<string>();
}

Due to the optional nature of the input value, ModelSignal values are typed as possibly undefined.

To get rid of those, you can provide a default value to the model() function:

myProp: ModelSignal<string> = model('default');

Alternatively, you can define your Model Inputs as required thought a dedicated model.required() function:

myRequiredProp: ModelSignal<string> = model.required<string>();

Input options: alias and transform function

As classic Angular inputs, Model Inputs support also the alias option:

myProp = model('default-value', { alias: 'myPropAlias' });

Allowing us to decouple the child component input variable name and the DOM property name used by parent components to bound the input value:

<my-component [(myPropAlias)]="parentProp"></my-component>

Where is the transform( ) function?

Regarding the transform() function, the last classic inputs option we are familiar with, the model() function does not support it.

This make sense to me, just think about the conflicts between the two-way nature of Model Inputs, and the role of the transform() function to transform the input value only inside a component.

Luckily, you can overcome this absence using the computed() function, which allows you to define derived values starting from a Signal:

import { Component, computed, model, ModelSignal, Signal } from '@angular/core';

@Component({ ... })
export class MyComponent {
  myProp: ModelSignal<string> = model('default');

  myComposedProp: Signal<number> = computed(
      () => this.modelOptional()?.length || 0
    );
}

In this way the value defined using the computed() function is confined inside child component.

Thanks for reading so far 🙏

I’d like to have your feedback so please leave a comment, like or follow. 👏

And if you really liked it please follow me on LinkedIn. 👋

Angular Signal Inputs: road to Signal Components

Davide Passafaro — Sat, 06 Apr 2024 18:52:17 +0000

Angular v17.1.0 has been released recently and it introduced a new amazing input API designed to enable early access to Signal Inputs.

Signal Inputs introduction is the initial act of the upcoming rise of Signal Components and zoneless Angular application, enhancing already both code quality and developer experience. Let’s delve into how they work.

Bye @Input decorator; Welcome input( ) function

Creating a Signal Input is quite simple:
rather than creating an input using the @Input decorator, you should now use the input() function provided by @angular/core.

Let’s see an example creating an input of string type:

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

@Component({ ... })
export class MyComponent {
  myProp = input<string>();
}

Using the input() function your inputs will be typed as InputSignal, a special type of read-only Signal defined as following:

An InputSignal is similar to a non-writable signal except that it also carries additional type-information for transforms, and that Angular internally updates the signal whenever a new value is bound.

More specifically your Signal Inputs will be typed as the following:

myProp: InputSignal<ReadT, WriteT = ReadT> = input<ReadT>(...)

Where ReadT represents the type of the signal value and WriteT represents the type of the expected value from the parent.
Although these types are often the same, I’ll delve deeper into their role and differences discussing the transform function later on.

Let’s go back to the previous example focusing on the input value type:

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

@Component({ ... })
export class MyComponent {
  myProp: InputSignal<string | undefined, string | undefined> = input<string>();
}

Those undefined are given by the optional nature of the input value.

To define your input as required, and thus get rid of those nasty undefined, the input API offers a dedicated required() function:

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

@Component({ ... })
export class MyComponent {
  myProp: InputSignal<string, string> = input.required<string>();
}

Alternatively you can provide a default value to the input() function:

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

@Component({ ... })
export class MyComponent {
  myProp: InputSignal<string, string> = input<string>('');
}

No more ngOnChanges()

Nowadays you typically use ngOnChanges and setter functions to perform actions when an input is updated.

With Signal Inputs you can take advantage of the great flexibility of Signals to get rid of those functions using two powerful tools: computed() and effect().

Computed Signals

Using computed() you can easily define derived values starting from your inputs, one or more, that will be always updated based on the latest values:

import { Component, InputSignal, Signal, computed, input } from '@angular/core';

@Component({ ... })
export class MyComponent {
  description: InputSignal<string, string> = input<string>('');

  descriptionLength: Signal<number> = computed(() => this.description.length);
}

So each time description value is modified, the value of descriptionLength is recalculated and updated accordingly.

Effect

With effect() you can define side effects to run when your inputs, one or more, are updated.

For example, imagine you need to update a third-party script you are using to build your chart component when an input is updated:

import Chart from 'third-party-charts';
import { effect, Component, InputSignal, input } from '@angular/core';

@Component({ ... })
export class MyComponent {
  chartData: InputSignal<string[], string[]> = input.required<string[]>();

  constructor() {
    const chart = new Chart({ ... });

    effect((onCleanup) => {
      chart.updateData(this.chartData());

      onCleanup(() => {
        chart.destroy();
      });
    });
  }
}

Or even perform an http request:

import { HttpClient } from '@angular/common/http';
import { effect, Component, InputSignal, inject, input } from '@angular/core';

@Component({ ... })
export class MyComponent {
  myId: InputSignal<string, string> = input.required<string>();

  response: string = '';

  constructor() {
    const httpClient = inject(HttpClient);

    effect((onCleanup) => {
      const sub = httpClient.get<string>(`myurl/${this.myId()}/`)
        .subscribe((resp) => { this.response = resp });

      onCleanup(() => {
        sub.unsubscribe();
      });
    });
  }
}

Using computed() and effect() will make your components more robust and optimized, enhancing also a lot the maintainability of the code.

Alias and transform function

In order to guarantee a smoother migration from decorator-based inputs, Signal Inputs supports also alias and transform function properties:

import { HttpClient } from '@angular/common/http';
import { effect, Component, InputSignal, inject, input } from '@angular/core';

@Component({ ... })
export class MyComponent {
  textLength: InputSignal<number, string> = input<number, string>(0, {
    alias: 'descriptionText',
    transform: (text) => text.length
  });
}

In particular, thanks to transform function you can define a function that manipulates your input before it is available in the component scope and this is where the difference between ReadT and WriteT comes into play.

In fact using the transform function can create a mismatch between the type of the value being set from the parent, represented by WriteT, and the type of the value stored inside your Signal Input, represented by ReadT.

For this reason, when creating a Signal Input with the transform function you can specify both ReadT and WriteT as the function type arguments:

mySimpleProp: InputSignal<ReadT, WriteT = ReadT> = input<ReadT>(...)

myTransformedProp: InputSignal<ReadT, WriteT> = input<ReadT, WriteT>( ... , {
  transform: transformFunction
});

As you can see, without the transform function the value of WriteT is set as identical to ReadT, while using the transform function both ReadT and WriteT are defined distinctly.

What about two-way binding?

There is no way to implement two-way binding with Signal Inputs, but there is a dedicated API called Model Input that exposes an update() function to fulfill this behavior.

👇🏼 You can find my dedicated article here: 👇🏼

Angular Model Inputs: two-way binding inputs with Signals

Davide Passafaro ・ Apr 9 '24

#angular #frontend #webdev #javascript

Thanks for reading so far 🙏

I’d like to have your feedback so please leave a comment, like or follow. 👏

And if you really liked it please follow me on LinkedIn. 👋

DEV Community: Davide Passafaro

Angular Meets Generative AI: Best Practices Made Easy

🤖 Generating the AI Configuration Files

🔍 Let’s Analyze the Configuration File

AI context for code generation

Sections and rules

Add your own rules

📖 Useful Links for Further Reading

🎉 Thanks for Reading! Until Next Time! 🚀

Angular Deep Signal: Modeling State in Depth

🎯 Accessing and Updating Deep State

Linked Signal: a workaround, not exactly a solution

🧬 The new Deep Signal primitive

How to create a Deep Signal

Performance of Deep Signals

🧱 Structural Signals: When Structure Matters

✅ Final Thoughts

Useful links for further reading

Thanks for reading! 🫶🏻

Exploring Angular httpResource: a new approach to async data fetching

The Resource API

How to use a Resource?

Angular resource() and rxResource() APIs: what you need to know

Davide Passafaro ・ Jan 1 '25

The httpResource

httpResponse( ) function

Configure the Resource with HttpResourceOptions

Fetching data types other than JSON

HttpClient integration and Interceptors support

Real-World Use Cases

Forms and Search optimizations

Disabling the request without destroying the resource

HttpResourceRequest in detail

Designed for fetching data only

Thanks for reading! 🫶🏻

Angular resource() and rxResource() APIs: what you need to know

The Resource API

resource( ) function

Resource life cycle

Aborting requests with abortSignal

How to consume a Resource

Check the status of a Resource

hasValue( ) function

isLoading( ) function

Resource value as a WritableSignal

Convenience wrappers methods

Reload or destroy a Resource

reload( ) function

destroy( ) function

rxResource( ) function

Thanks for reading so far 🙏

Angular Forms new unified control state change events

Angular Reactive Forms: the fundamentals

Template binding

Listening for value changes

Disabled controls

Validators

FormControlStatus

Pristine and Touched

New unified control state change events

Additional insights

Thanks for reading so far 🙏

Angular fallback content in ng-content

Define fallback content in ng-content elements

Angular v18: fallback content in ng-content

Fallback content strategies limitations

Thanks for reading so far 🙏

Redirecting Guards and Resolvers in Angular v18 with RedirectCommand

Angular Router Guards and Resolvers

Use Guards and Resolvers to redirect navigation

Redirect with UrlTree

Redirect with RedirectCommand

Thanks for reading so far 🙏

Angular new output() function

The new output() API

How to subscribe to outputs programmatically

New rxjs-interop functions

outputFromObservable()

outputToObservable()

Thanks for reading so far 🙏

The new `output()` API

`outputFromObservable()`

`outputToObservable()`