Matej Jakšić

SignalState redefines Angular state management. Discover how @ngrx/signals simplifies state updates, boosts performance, and cuts boilerplate. 

SignalState: A New Standard for Angular Component State

Angular's state management is evolving. For years, we have relied on the "Service with a Subject" pattern or @ngrx/component-store to manage component state.

Now, with the release of  SignalState, Angular developers have a new way to handle component state that leverages Angular’s native Signals API. The NgRx team recommends @ngrx/signals as the preferred alternative to @ngrx/component-store.

To manage global state, we can use SignalStore, which is also part of @ngrx/signals, however this will be explained in another blog post.


What are signals, anyway?

A signal is a wrapper around a value that notifies interested consumers when that value changes.

Instead of manually subscribing to changes or managing streams with RxJS, signals automatically track state updates and trigger re-renders when their values change. With signals, you have less boilerplate code and your components become more declarative.


What makes @ngrx/signals special?

Unlike native Angular signals, @ngrx/signals is a dedicated state management solution.

It bundles powerful utilities like signalState and patchState—which help you define and update your component’s state.

💡The idea is simple: instead of scattering state logic throughout your component, you centralize it in one place.

This not only makes your code cleaner but also easier to maintain and debug.


Getting started with @ngrx/signals


Installation

To begin using @ngrx/signals, install the package via ng-add

ng add @ngrx/signals@latest

Or with npm/yarn/pnpm:

npm install @ngrx/signals


Basic component example

Let’s create a simple todo component to see signals in action. The code below defines a signal state with two todos, computed signal for todos counter, and addToDo() method that adds a new, unique todo:

import { Component, computed } from '@angular/core';
import { signalState, patchState } from '@ngrx/signals';

interface Todo {
  id: number;
  title: string;
  content: string;
}

@Component({
  selector: 'app-todo',
  template: `
    <ng-container>
      <h2>Todos (Total: {{ todoCount() }})</h2>
      <ul>
        @for (todo of state(); track todo.id) {
        <li>
          <h3>{{ todo.title }}</h3>
          <p>{{ todo.content }}</p>
        </li>
        }
      </ul>
      <button (click)="addTodo()">Add Todo</button>
    </ng-container>
  `
})
export class TodoComponent {
  state = signalState<Todo[]>([
    { id: 1, title: 'Shopping List', content: 'Eggs' },
    { id: 2, title: 'Work', content: 'Finish NgRx tutorial' }
  ]);

  // Computed signal for total todos
  todoCount = computed(() => this.state().length);

  // Add a new todo
  addTodo() {
    const newId = this.state().length + 1;
    patchState(this.state, [
      ...this.state(),
      { id: newId, title: `New Todo ${newId}`, content: 'Some new task' }
    ]);
  }
}



Instead of creating additional signal or a new object in the state, we used computed signal which derives its value from other signals.

Benefits of using computed:

 * Reactivity: The computed function allows you to derive values (like the count of todos) based on the state without explicitly managing or mutating the state.
 * Automatic updates: The todoCount() value automatically updates whenever the state changes

State can be updated in multiple ways.

The patchState function offers a type-safe method for updating specific parts of your state. It accepts a SignalState or SignalStore instance as its first argument, followed by partial states or state updaters as additional arguments.

// Providing a partial state object.
  addTodo() {
    const newId = this.state().length + 1;
    patchState(this.state, [
      ...this.state(),
      {
        id: newId,
        title: `New Todo ${newId}`,
        content: "Some new task",
        completed: false,
      },
    ]);
  }

  // Providing a partial state updater.
  addTodo() {
    const newId = this.state().length + 1;
    patchState(this.state, (todos) => [
      ...todos,
      {
        id: newId,
        title: `New Todo ${newId}`,
        content: "Some new task",
        completed: false,
      },
    ]);
  }

  // Providing a sequence of partial state objects and/or updaters.
  addTodo() {
    const newId = this.state().length + 1;
    patchState(
      this.state,
      (todos) => [
        ...todos,
        {
          id: newId,
          title: `New Todo ${newId}`,
          content: "Some new task",
          completed: false,
        },
      ],
      (todos) => [...todos]
    );
  }


Custom state updates

A custom state updater is a function that returns a state update operation. This operation can be a partial update to the state, and is typically used when you want to modify a specific part of the state without affecting the rest of the state.

 // Dynamic update for Todo title or content
  setTodoProperty(id: number, property: keyof Todo, value: any): PartialStateUpdater<Todo[]> {
    return (state) => state.map(todo =>
      todo.id === id ? { ...todo, [property]: value } : todo
    );
  }

  // Function to update the title of a todo
  changeTodoTitle(id: number, title: string) {
    patchState(this.state, this.setTodoProperty(id, 'title', title));
  }

  // Function to update the content of a todo
  changeTodoContent(id: number, content: string) {
    patchState(this.state, this.setTodoProperty(id, 'content', content));
  }


Replacing @ngrx/component-store with @ngrx/signals

For many Angular projects, @ngrx/component-store has been the go-to solution for local state management.

However, with the introduction of @ngrx/signals, for the new projects—and even when refactoring existing ones—developers are encouraged to adopt @ngrx/signals to replace @ngrx/component-store for managing component state.

This change is driven by signals’ ability to simplify state updates and improve performance by triggering re-renders only when necessary.


Performance and developer experience

Thanks to signals reactive nature, only UI elements are dependent on a specific signal update when that signal's value changes.

This targeted approach enhances performance, particularly in apps with frequent or granular state changes. The simple API also reduces complexity, which means developers can focus on building features instead of managing complex state infrastructure.


Conclusion

SignalState offers a fresh, efficient way to manage component state in Angular applications.

By leveraging Angular’s new Signals API, it reduces boilerplate while providing a powerful, reactive model for state management. For developers used to the traditional @ngrx/component-store, this approach provides an excellent migration path to a more modern architecture.

Try integrating @ngrx/signals into your next Angular project and experience the benefits of reactive state management firsthand.

Happy coding! 🥳

Thank you for your the time to read this blog! Feel free to share your thoughts about this topic and drop us an email at hello@prototyp.digital.

Development

SignalState: The New Standard for Component State in Angular

Learn how to use CVAs to create custom form controls. This guide covers CVA concepts and practical implementation using standalone components.

Angular Control Value Accessor Guide: Build a Component

Custom form controls are essential in Angular applications. From fancy date pickers and dynamic sliders to star rating components, Control Value Accessors (CVAs) enable seamless integration with Angular's forms API.

In this guide, we'll examine Control Value Accessors, their use cases, and demonstrate how to build a reusable Star Rating Component using Angular's standalone component architecture.


What Are Control Value Accessors?

Control Value Accessors (CVAs) are a fundamental part of Angular's forms ecosystem. They enable custom form components to integrate with Angular's form APIs (FormControl, FormGroup, ngModel) — working just like native form elements such as <input> and <select>.

Control Value Accessors enable you to:

 * Bind values from a form to a custom component
 * React to changes in the component's value
 * Support Angular's validation and state tracking


When to Use Control Value Accessors

You should implement a Control Value Accessor when you need:

 1. Custom Form Components: Such as sliders, star ratings, dropdown selectors, etc.
 2. Form Integration: Your component needs to work with formControlName or ngModel
 3. Complex UI Logic: Your component handles asynchronous data or manages multiple values


When Not to Use Control Value Accessors

If your component doesn't need form integration or won't use Angular's forms API, stick with a simple @Input() and @Output() approach. Implementing a Control Value Accessor when it's not needed only adds unnecessary complexity to your component.


Benefits of Using formControlName with CVAs

Using formControlName with CVAs offers:

 * Seamless Integration: Automatic value synchronization, validation, and state tracking
 * Clean API: Simply use formControlName for direct binding instead of passing FormControl through @Input()
 * Validation Support: Access Angular's built-in and custom validators effortlessly
 * Reusable Components: Create standardized interfaces that work consistently across your application


Building a Star Rating Component with CVA (Standalone)

Let's build a star rating component that works seamlessly with Angular's reactive forms using Control Value Accessors. For simplicity, the template will be inline.


Step 1: Create the Star Rating Component

We'll start by creating a standalone component for the star rating. It will:

 1. Render 5 clickable stars.
 2. Allow the user to select a rating.
 3. Work seamlessly with Angular forms using formControlName.

import { Component, forwardRef } from '@angular/core';
import { ControlValueAccessor, NG_VALUE_ACCESSOR } from '@angular/forms';
import { CommonModule } from '@angular/common';

@Component({
  selector: 'app-star-rating',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div class="stars" role="radiogroup" aria-labelledby="star-rating-label">
      <ng-container *ngFor="let star of stars; let i = index">
        <i
          class="star"
          [attr.aria-checked]="i < value ? 'true' : 'false'"
          [class.filled]="i < value"
          (click)="onStarClick(i)"
        >
          ★
        </i>
      </ng-container>
    </div>
  `,
  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      useExisting: forwardRef(() => StarRatingComponent),
      multi: true,
    },
  ],
  styleUrls: ['./star-rating.component.scss'],
})
export class StarRatingComponent implements ControlValueAccessor {
  value = 0;
  stars = Array(5).fill(false);

  private onChange: (value: number) => void = () => {};
  private onTouched: () => void = () => {};

  writeValue(value: number): void {
    this.value = value || 0;
  }

  registerOnChange(fn: (value: number) => void): void {
    this.onChange = fn;
  }

  registerOnTouched(fn: () => void): void {
    this.onTouched = fn;
  }

  onStarClick(index: number): void {
    this.value = index + 1;
    this.onChange(this.value);
    this.onTouched();
  }
}



Step 2: Create the Rating Form

Next, we’ll create a standalone form component to demonstrate how the star rating component works with Angular’s reactive forms.

import { Component } from '@angular/core';
import {
  FormBuilder,
  FormGroup,
  Validators,
  ReactiveFormsModule,
} from '@angular/forms';
import { CommonModule } from '@angular/common';
import { StarRatingComponent } from '../star-rating/star-rating.component';

@Component({
  selector: 'app-rating-form',
  standalone: true,
  imports: [CommonModule, ReactiveFormsModule, StarRatingComponent],
  template: `
     <form [formGroup]="form" (ngSubmit)="onSubmit()">
      <label for="rating" id="star-rating-label">Rate your experience</label>
      <app-star-rating formControlName="rating"></app-star-rating>

      
      <div
        *ngIf="ratingControl?.touched && ratingControl?.invalid"
        class="error-message"
        role="alert"
      >
        {{ errorMessage }}
      </div>

      <div class="form-buttons">
        <button type="submit" [disabled]="form.invalid">Submit</button>
        <button type="button" (click)="reset()">Reset</button>
      </div>
    </form>
  `,
  styleUrls: ['./rating-form.component.scss'],
})
export class RatingFormComponent {
  form: FormGroup;

  constructor(private fb: FormBuilder) {
    this.form = this.fb.group({
      rating: [0, [Validators.required, Validators.min(1)]], // Default initial value
    });
  }

  // Get the rating control once to avoid repetition
  get ratingControl() {
    return this.form.get('rating');
  }

  // Get the error message based on the validation
  get errorMessage(): string {
    const control = this.ratingControl;
    if (control?.hasError('required')) return 'Please select a rating.';
    if (control?.hasError('min')) return 'Rating must be at least 1.';
    return '';
  }

  // Handle form submission
  onSubmit(): void {
    if (this.form.valid) {
      console.log('Form Submitted with Rating:', this.form.value);
    }
  }

  // Handle form reset and trigger error message
  reset(): void {
    this.form.reset();
    this.ratingControl?.markAsTouched();
  }
}


Finally, after adding some styling, app looks like this:


Key Takeaways

 1. Seamless Forms Integration: CVA lets you build custom controls that feel native to Angular's forms ecosystem.
 2. Simplified Reusability: Using formControlName makes custom controls straightforward to implement and maintain.
 3. Encapsulation of Logic: CVAs encapsulate the internal behavior of your custom controls, keeping the API clean for parent components.


Final Thoughts

Control Value Accessors are a powerful feature in Angular, especially when paired with standalone components. They make custom form controls reusable, maintainable, and fully compatible with Angular’s forms API. If your app relies heavily on forms, mastering CVAs is a must for creating a seamless user experience.

Happy coding! 🎉

You can find the whole source code in the Github repo.

Thank you for your the time to read this blog! Feel free to share your thoughts about this topic and drop us an email at hello@prototyp.digital.

Building Custom Form Controls in Angular

In this article, you can learn how to implement the Intersection Observer API using Angular and RxJS and supercharge your application. 

How to implement Intersection Observer API in Angular? - Prototyped

Nowadays, web applications are becoming more and more complex. Thus, one of the most important factors becomes the performance of the site. The Intersection observer API provides a way to asynchronously observe changes of two elements in relation to each other. For example, a target element with an ancestor element or with the viewport. Because of that, it provides a variety of different use-cases that developers can use to create more efficient and performant web applications.


Use-cases

Why would you want to use this API? Intersection information can be very useful for many things such as:

 * Improving performance by only loading components that are visible on the screen
 * Lazy-loading images or lists of content that requires HTTP requests to be rendered
 * Implementing parallax effects where more content is loaded as you scroll
 * Calculating ad revenue based on ad visibility
 * Performing tasks or animations based on whether or not the user will see the result


Creating an intersection observer

Using the example taken from MDN, here’s an example of how to create intersection observer.



let options = {
  root: document.querySelector('#scrollArea'),
  rootMargin: '0px',
  threshold: 1.0
}

let observer = new IntersectionObserver(callback, options);

As we can create an intersection observer by calling its constructor and passing it a callback function and the options object.

Options object contains the following fields:

 * root - element that is used as the viewport for checking the visibility of the target. If not specified it defaults to page viewport
 * rootMargin - takes a value that will be used to calculate how much margin from the root an element needs to have to be considered “visible”. For example, we can start loading an image before it is fully visible to minimize the time needed to load it
 * threshold - number inside the interval [0,1] which defines at what percentage of the target’s visibility should the observer’s callback be executed, the default is 0 (meaning as soon as even one pixel is visible, the callback will be run), while 1 means that the threshold isn't considered passed until every pixel is visible


Integrating the Intersection Observer API with Angular

As we want to change the appearance/behaviour of DOM elements, we can make an Angular directive that can be used on these elements. To expose public API from directive we will use exportAs property inside directive decorator.



@Directive({
selector: '[appObserveElement]',
exportAs: 'intersection',
})


After that we need to define necessary Intersection Observer options we will use @Input() and @Output decorators. In addition to that, we will also define a few extra properties.

 * debounceTime - tells us when the user has stopped scrolling
 * isContinuous - flag that we use to decide whether we want to continue observing an element for visibility changes
 * isIntersecting - emits an event that tells us if the element is intersecting
 * intersecting - a public property that we use to trigger changes to the template



@Input() root: HTMLElement | null = null
@Input() rootMargin = '0px 0px 0px 0px'
@Input() threshold = 0
@Input() debounceTime = 250
@Input() isContinuous = false

@Output() isIntersecting = new EventEmitter<boolean>()

intersecting = false


Since we are using Typescript, we can define our options object as type IntersectionObserverInit.

After that, we can finally create our Intersection Observer.



createAndObserve () {
    const options: IntersectionObserverInit = {
      root: this.root,
      rootMargin: this.rootMargin,
      threshold: this.threshold,
    }

    return new Observable<boolean>(subscriber => {
      const intersectionObserver = new IntersectionObserver(entries => {
        const { isIntersecting } = entries[0]
        subscriber.next(isIntersecting)

        isIntersecting &&
          !this.isContinuous &&
          intersectionObserver.disconnect()
      }, options)

      intersectionObserver.observe(this.element.nativeElement)

      return {
        unsubscribe () {
          intersectionObserver.disconnect()
        },
      }
    })
      .pipe(debounceTime(this.debounceTime))
      .subscribe(status => {
        this.isIntersecting.emit(status)
        this._isIntersecting = status
      })
  }


In this method, we create an observer and wrap it inside of observable. Inside this observable, we define an unsubscribe() function where we disconnect from the Intersection Observer observable. Then we use a pipe function with debounceTime operator and subscribe to the changes and do our main status-changing logic. After that, all that is left to do is unsubscribe from the observable inside ngOnDestroy() lifecycle method.


Applying our directive

To use the appObserveElement, we add it to the HTML template with the directive name as an attribute. Then we pass our properties if we want to change some default value. Now we can use our directive reference to access our _isIntersecting property or we can use our isIntersecting() event to do some logic.



<mat-card
        class="example-card"
        *ngFor="let item of [].constructor(5); index as index"
        appObserveElement
        #intersection="intersection"
        [class.example-card--is-intersecting]="intersection._isIntersecting"
        (isIntersecting)="isIntersecting($event, index)"
        [isContinuous]="true"
>

The complete source code can be found at: https://github1s.com/matejjaksic/intersection-observer


To conclude

In this article, we’ve learned what is Intersection Observer and how we can apply it inside Angular. We have created a simple directive that can be reusable and is very versatile because we can change many properties with our @Input decorators. In the example, we can see how we can use our exportAs property to expose our directive inside the template. We’ve also implemented an emitter that we can use to do some logic inside our main component.

Thank you for your the time to read this blog! Feel free to share your thoughts about this topic and drop us an email at hello@prototyp.digital.

AuthorMatej Jakšić

Start a Project