Forem: Nicolas Frizzarin

Angular Signals Form: Validation and Logic

Nicolas Frizzarin — Mon, 15 Sep 2025 21:10:41 +0000

Introduction

In the previous article, we explored how to create a form based entirely on signals. However, that was a simple form with no business logic and, most importantly, no validation.

This article aims to detail how we can write our business logic simply and in a scalable way.

Just a reminder

Just a reminder, the form we created is as follows:

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}


@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model
}

As shown in the previous article, a FieldState instance exposes a signal (and therefore a reactive state) like valid or disabled. However, this state isn't defined directly. In reality, it's a derived state (technically, it's a computed). This derived state comes directly from the field logic part of the form.

Adding Field Logic

One of the key aspects of signals-based forms in Angular is the very definition of business logic and validation. This definition is done declaratively in TypeScript when the form is defined. This implies two important things:

There are no imperative commands to modify a field's state later on; in other words, there are no methods like disable.
A field can be required or disabled based on other signals or static conditions.

Essentially, the business and validation logic is represented by a schema. A schema can be considered as a blueprint containing all our business rules for:

The entire form
A specific Field

schema is defined using the schema function. This function is generically typed and takes:

The FieldPath interface as a generic type.
A function that takes the FieldPath as an input and defines its business logic.

The generic type here is of utmost importance because it's what dictates the rule's definition:

a Todo type schema defines the rules for a Todo type field
a Boolean type schema defines the rules for a Boolean type field

Type and rule definition are extremely linked. This link ensures that the field's logic is perfectly aligned with the form's structure.

A Schema can be created by calling schema() and passing it a schema function, or just passing a schema function directly to form() or other methods that expect a Schema.

Once you have defined a schema, you associate it with your Field structure by passing it as the second argument to the form() function

let's have some code

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}

@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel, (path: FieldPath<Todo>) => {}); // we create the form which is linked to the model
}

In this example, we've defined a schema by its function. The main drawback of this solution is that it's not scalable. The schema here can't be exported by a library or reused across an application.

let' rework a little bit the previous code

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}

/**
* Define a schema exportable:
* - let you to create some library that export your custom schema
* - could be used later in an other place of your application
*/
export const TodoSchema = schema<Todo>(path => {});

@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  });
  todoForm = form(this.todoModel, TodoSchema);
}

Right now, our schema doesn't do... anything. Let's see how we can add some functionality to it.

Let's have some logic

Just like with Reactive Forms, there are built-in validations. You'll find the classic validation types:

For a complete list of existing validators, please go here

Let's add some validation to our form.

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}

/**
* Define a schema exportable:
* - let you to create some library that export your custom schema
* - could be used later in an other place of your application
*/
export const TodoSchema = schema<Todo>(path => {
  required(path.title);
  required(path.description);
  minLength(path.description, 10);
});

@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  });
  todoForm = form(this.todoModel, TodoSchema);
}

If you want to use your own validation logic instead of the built-in validators, two new functions are available to us:

validate
error

The `validate` function

The validate function is used to add custom validation to a field. A single field can have multiple validation rules, and all validation rule errors can be found in the FieldState.

Example:

const emailSchema = schema<string>(path => {
  validate(path, (value) => {
    const email = value();
    const sfeirPattern = /^\w+\.\w@sfeir.com$/;
    return sfeirPattern.test(email) ? 
      [] : [{ kind: 'sfeir-mail-incorrect', message: 'Required format: x.x@sfeir.com'}]
  });
})

This function can be much more powerful than a simple email validator. Since the function takes a FieldPath as its first parameter, it can validate a single field but also an entire form :). For the die-hard fans of Zod, it becomes very easy to link the form's validation with Zod's validation.


const UserSchema = z.object({
  name: z.string().min(1, 'Name is required'),
  email: z.string().email('Invalid email'),
  age: z.number().min(18, 'Must be 18 or older'),
});

const userFormSchema = schema<User>(path => {
  validate(path, ({ value }) => {
    const validation = UserSchema.safeParse(value());
    return validation.success ?
      [] :
      validation.error!.issues.map(issue => ({
        kind: `${issue.path[0]_${issue.expected}`
        message: issue.message
      }))
  });

/**
* Focus of ({ value }) => {}
* This function is called an helper fonction
* Helper function take an object with three properties
* - value: signal that return the value of the `FieldPath`
* - valueOf: function that take a `FieldPath` and return the associate value
* - stateOf: function that take a `FieldPath` and return the `FieldState` of this `FieldPath`
* - fieldOf: function that take a `FieldPath` and return the `Field` of this `FieldPath` 
*/
});

The `error` function

The error function is a simplified version of the validate function due to its return type. Unlike the validate function, error function returns a boolean, optionally with a message that's properly formatted for the user experience.

true if the validation is successful
false if the validation fails

const emailSchema = schema<string>(path => {
  error(path, (value) => {
     const email = value();
     const sfeirPattern = /^\w+\.\w@sfeir.com$/;
     return sfeirPattern.test(email)
   }, 'Required format: x.x@sfeir.com');
})

Composition built-in

As the examples above show, validation with form signals is very powerful, but it can get quite verbose and quickly complicate our form.

This is where schema composition and flexibility become very useful.

Let's go back to the example above.

export const TodoSchema = schema<Todo>(path => {
  required(path.title);
  required(path.description);
  minLength(path.description, 10);
  maxLength(path.description, 150);
});

We're adding three validations to the description field. When the model is small, the impact is minimal, but as it grows, poor structuring and business logic management become a nightmare.

This is where the composition pattern truly makes sense.

The composition pattern is a simple pattern based on the act of composing. You compose smaller things to solve a complex problem.

With Signals Form, it's entirely possible to compose with schemas. This composition happens around the simple apply function.

The apply function lets you assign a schema to a FieldPath. This function, therefore, allows for two things.

To break down our form validation into smaller schemas
To share generic schemas throughout our application, or even better, across an multiple application if we create a schema library.

const descriptionSchema = schema<string>(path => {
  required(path);
  minLength(path.description, 10);
  maxLength(path.description, 150);
});

export const TodoSchema = schema<Todo>(path => {
  required(path.title);
  apply(path.description, descriptionSchema);
});

The apply function has some new companions.

applyEach allows you to apply a schema to each element of an array. This function therefore takes an Array-type FieldPath and a schema
applyWhen which allows a schema to be applied conditionally. This function therefore takes the fieldPath on which to apply the validation, the condition to apply the validation, and finally the schema.


interface User {
  email: string;
  password: string;
  confirmPassword: string;
}

const UserSchema = schema<User>(path => {
  required(path.email);
  applyWhen(
     path.confirmPassword,
     ({ valueOf }) => Boolean(valueOf(path).password),
     (confirmPasswordPath) => {
       required(confirmPassword)
     }
  )
});

@Component({
  selector: 'app-user',
  templateUrl: './user-form.html',
  imports: [Control]
})
export class AppForm {
  usersModel = signal<User[]>([]);
  usersForm = form(this.usersModel, (path => {
    applyEach(path);
  });
}

Conclusion

The business logic of a form is defined using a schema, which can be thought of as a blueprint.

The signal form package provides numerous helpers, including built-in validators and tools that allow for the use of the composition pattern within forms.

What previously required a lot of code and extensive thought about form structure can now be accomplished with just a few simple lines of code.

This really shows a strong desire to improve the developer experience and abstract away the complexity of form creation, allowing developers to focus on their business logic.

Signals Form: Introduction

Nicolas Frizzarin — Tue, 09 Sep 2025 06:17:00 +0000

Introduction and Disclaimer

First and foremost, the APIs that will be mentioned in this article are still highly experimental and may be subject to change in the future. As with all experimental APIs, I do not recommend using them in an application that is scheduled to go into production in the near future.

Today, and to no great surprise, the Angular Team is trying to incorporate signals as much as possible into existing APIs. Naturally, forms aren't being left behind, and a new type of form is emerging: Signal forms. This addition brings the total number of possible forms in Angular to three:

React Form: forms controlled by the component
Template Driven Form: forms controlled by the template
Signal Form: forms controlled by signals

Mindset of Signal Forms

No matter the framework or library you use to create a form, a form is simply a set of UI fields that allow the user to enter structured data, which can be governed by validation rules to ensure its integrity.

With Signal forms, this concept is separated into four distinct parts:

Data model: the form's current data model
Field State: the metadata associated with a form field (value, validity, and control state)
Field logic: the business logic of the field (validation rules, conditional display of the field)
UI Control: the control that enables interaction between native elements, custom components, and the user.

One of the key points of Signal's form is that it doesn't maintain its own data internally. Instead, we, the developers, expose this data model through a signal that the library will use as the uniq source for the fields of our form.

To illustrate this in code :)

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[];
}


@Component({
  selector: 'app-form',
  templateUrl: './app-form.html'
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model

}

Establishing the model as the single source of truth means two important things:

Any modifications to the model, via the set or update function, will automatically update the form field.
Any modifications to the form due to user interaction with a field will update the model.

A tree of Field

Calling the form function gives the developer access to a Field tree. The form itself is a Field called the Root Field.

A Field instance provides its state, which later allows you to retrieve its value, validity, and more and it can be retrieve by calling the Field function.

Let's illustrate that with a bit of code :)

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}


@Component({
  selector: 'app-form',
  templateUrl: './app-form.html'
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model

  titleField: Field<string> = this.todoForm.title;
  firstAssigned: Field<Assigned> = this.todoForm.assigned[0];
  firstAssignedName: Field<string> = firstAssigned.name;

}

Field Instance

As explained previously, a Field instance returns the state of that field. The state is composed of 6 main points.

value: A WritableSignal that allows you to read and write the value of a field.
errors: A signal for retrieving validation errors on the field.
valid: A signal for retrieving the field's validity.
disabled: A signal for retrieving whether the field is disabled.
touched: A signal to know if the user has interacted with the field or one of its children.
dirty: A signal to know if the field or one of its children is dirty.

For more details on what a field instance can offer, or to see the concrete implementation, please refer to the following

Let's illustrate that with a bit of code.

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}


@Component({
  selector: 'app-form',
  template: `<button [disabled]="titleField().valid()">Submit</button>`
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model

  titleField: Field<string> = this.todoForm.title;
  firstAssigned: Field<Assigned> = this.todoForm.assigned[0];
  firstAssignedName: Field<string> = firstAssigned.name;
}

Binding the field to UI elements

We have now completed the data model definition, form creation, field tree navigation, and field instance retrieval.

It is now important to connect the UI element (input, textarea, or even a custom component) to the field so the user can interact with the control.

In Angular, the Signal Form provides a built-in directive, so you can see the source code here

This directive will have several responsibilities:

Two-way data binding to update the field's value (both from user interaction and programmatically).
Binding the field's business logic (validation rules, read-only status, etc.).
Relaying the various possible events on the control (dirty, touched, etc.).
Internally, injecting the NgControl token to get useful methods and ensure interoperability.

Here, we clearly see the intention to create a bridge between the HTML logic and Angular's forms, leveraging all the power they can provide.

Let's materialize this with some code :)

interface Assigned {
  name: string;
  firstname: string;
}

interface Todo {
  title: string;
  description: string;
  status: TodoStatus;
  assigned: Assigned[]
}


@Component({
  selector: 'app-form',
  templateUrl: './app-form.html',
  imports: [Control]
})
export class AppForm {
  todoModel = signal<Todo>({ 
    title: '',
    description: '', 
    status: 'not_begin',
    assigned: []
  }); // We create the model that will be the source of truth for the form and it's tree field

  todoForm = form(this.todoModel); // we create the form which is linked to the model
}

<form novalidate>
  <input type="text" [control]="todoForm.title" />
  <input type="text" [control]="todoForm.description" />
  <select [control]="todoForm.status">
    <option [ngValue]="not_begin">Not Begined</option>
    <option [ngValue]="in_progress">In Progress</option>
    <option [ngValue]="finished">Finished</option>
  </select>
</form>

Conclusion

This marks the end of the first article in a series of three. This article aimed to lay the foundations for Signal's forms.

We were able to understand how Signal's forms work by detailing their main components.

However, for now, our form contains no validation, and as a reminder, validation consists of the business logic of our field. This step will be detailed in the second article.

What to remember here is that the developer has complete control over the data model they expose. This data model will subsequently allow for the connection between the Field and the value.

The form function allows for the creation of a field tree. It is possible to navigate this tree using dot notation.

A Field instance allows you to retrieve its state by calling a function, which enables you, for example, to know its current value.

The Next Generation of Dynamic Component

Nicolas Frizzarin — Tue, 01 Apr 2025 05:34:31 +0000

Préambule

Before anything else, I want to clarify that Angular has not changed its way of dynamically creating components. The API has evolved, and what will be shown and explained in this article is still in preview and may change before the release of Angular version 20.

This article is based on the angular-next-1 version.

Introduction

With Angular, there are several ways to dynamically create components and 'attach' them to the view and the change detection cycle. However, until now, some features like setting inputs, or responding to outputs were not feasible on certain APIs (createComponent).

This article presents the evolution of the createComponent API with a reminder of the other APIs allowing the dynamic creation of components.

NgComponentOutlet: Declarative way to dynamic component creation

The NgComponentOutlet directive is a simple way to create components dynamically. It uses a declarative approach.

This directive takes several input parameters, one of which is required: the component to be created.

@Component({ 
  select: 'app-parent',
  template: `
    <ng-container *ngComponentOutlet="dynamicComponent" />
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 component: Type<HelloComponent> | null = null;

 async loadComponent(): Promise<void> {
   component = (await import('./hello.component')).HelloComponent;
 }
}

The above code represents the implementation of the basic API of the ngComponentOutlet directive.
When the button is clicked, the loadComponent method is called. This method lazily loads the HelloComponent component (a little performance is always nice). The instance of the HelloComponent component is then assigned to the component variable.

The directive, NgComponentOutlet, which takes as input named ngComponentOutlet the instance of a component, will attach the HostView of the component in the current view.

Recently, more specifically Angular version 16, this directive allows inputs to be set automatically in the dynamic component using the ngComponentOutletInputs input

This input takes an object that will bind an input of the dynamic component to a value.

@Component({ 
  template: `Hello {{ name }}`
})
export class HelloComponent {
  name = input('DevTo');
}


@Component({ 
  selector: 'app-parent',
  template: `
    <ng-container *ngComponentOutlet="dynamicComponent; inputs: { 
      name: 'This is Angular' }" />
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 component: Type<HelloComponent> | null = null;

 async loadComponent(): Promise<void> {
   component = (await import('./hello.component')).HelloComponent;
 }
}

Through this example, the input name is passed to the HelloComponent component. When the HostView of the HelloComponent component is inserted into the current view, the screen will display Hello This is Angular.

This method works very well if you know in advance which component is going to be created dynamically. Now let's imagine that the method loadComponent conditionally loads two components:

the HelloComponent component taking an input name
the AngularComponent component taking no input

... 
 component: Type<HelloComponent | AngularComponent> | null = null;
 isAngular = signal(false);

 async loadComponent(): Promise<void> {
   if(isAngular()) {
     component = (await import('./angular.component')).AngularComponent;
   }else {
     component = (await import('./hello.component')).HelloComponent;
   }
 }

In the case where component is an AngularComponent instance, the application will not build. An error will be raised explaining that the AngularComponent component must have an input called name even if this component has no use for it.

Another sticking point: at the moment it is not possible to react to outputs of the component created dynamically in the parent component.

This is where the createComponent function comes in.

The update of createComponent function

Please note that what follows is based on the Angular-next-1 version and may potentially change in the future.

If you would like to take a look at the sources, it's this way:

Generally, to create a dynamic component with a more functional approach, we use the createComponent function which we will explain using the ViewContainerRef class.

@Component({ 
  select: 'app-parent',
  template: `
    <section #dynamicSection></section>
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 dynamicSection = viewChild<ViewContainerRef>('dynamicSection', { read: ViewContainerRef } );

 async loadComponent(): Promise<void> {
   const helloComponent = (await import('./hello.component')).HelloComponent
   this.dynamicSection.createComponent(helloComponent);
 }
}

In the above code, a section with a reference named dynamicSection serves as a container for displaying the dynamically created component.
When the user clicks on the button, the loadComponent method loads the HelloComponent component, then the createComponent function creates the component, attaches the host view of this component to the current view and, of course, registers this component in the change detection cycle.
Thus, when the parent component is destroyed, the hook onDestroy of the dynamic component will also be called, thus avoiding any memory leaks.

The createComponent method returns a ComponentRef. This class allows the setInput function to set inputs to the dynamic component. But once again, we cannot react to events from the dynamic component in the parent component.

Today, in Angular version 20, it is possible to go much further than setting inputs. We can

bind inputs
bind outputs
create a two-way binding between parent and child (dynamic)
apply host directives to the dynamic component and bind inputs and outputs

This function is possible thanks to the standalone component and also to the appearance of signals as Angular's primary reactive system.

@Component({ 
  template: `Hello {{ name }}
    <button type="button" (click)="refresh()">Refresh</button>
  `
})
export class HelloComponent {
  name = input('DevTo');
  refreshName = output<void>();

  refresh(): void {
    this.refreshName.emit()
  }
}

@Component({ 
  select: 'app-parent',
  template: `
    <section #dynamicSection></section>
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 name = signal('DevTo');
 dynamicSection = viewChild<ViewContainerRef>('dynamicSection', { read: ViewContainerRef } );

 onRefresh = () => this.name.set('This is Angular');

 async loadComponent(): Promise<void> {
   const helloComponent = (await import('./hello.component')).HelloComponent
   this.dynamicSection.createComponent(helloComponent,{
     bindings: [
       inputBinding('name', this.name),
       outputBinding('refreshName', this.onRefresh),
     ]
   });
 }
}

In the above code, the HelloComponent component will be created dynamically by mapping the input name to the value This is Angular and mapping the outPut refreshName to the onRefresh function.

This way, when the user clicks on the Refresh button, the onRefresh function will be called.

Be careful to pass an arrow function so as not to lose the context

Let's go a little further, let's imagine that we want to apply a directive on the dynamic component, this directive will be in charge of adding a class red if the name is “This is Angular”.
With the new definitions of the createComponent function, this scenario is now possible.


@Directive({ 
  selector: '[rainbow]',
  host: {
   '[class.red]'= 'isRed()';
  }
})
export class ColorDirective {
  name = input<string>('');
  isRed = computed(() => this.name() === 'This is Angular');
}

@Component({ 
  template: `Hello {{ name }}
    <button type="button" (click)="refresh()">Refresh</button>
  `
})
export class HelloComponent {
  name = input('DevTo');
  refreshName = output<void>();

  refresh(): void {
    this.refreshName.emit()
  }
}

@Component({ 
  select: 'app-parent',
  template: `
    <section #dynamicSection></section>
    <button type="button" (click)="loadComponent()">Load</button>`,
  imports: [NgComponentOutlet]
})
export class ParentComponent {
 name = signal('DevTo');
 dynamicSection = viewChild<ViewContainerRef>('dynamicSection', { read: ViewContainerRef } );

 onRefresh = () => this.name.set('This is Angular');

 async loadComponent(): Promise<void> {
   const helloComponent = (await import('./hello.component')).HelloComponent
   this.dynamicSection.createComponent(helloComponent,{
     bindings: [
       inputBinding('name', () => 'This is Angular'),
       outputBinding('refreshName', this.onRefresh),
     ],
     directives: [
       { type: ColorDirective,
         bindings: [
           inputBinding('name', this.name),
         ]
       }
     ]
   });
 }
}

In the example above, the ColorDirective will be applied to the HelloComponent dynamic component by binding the input name.

Initially, the value of the signal name will be DevTo which sets the variable isRed to false

When the user clicks on the refresh button, the onRefresh function will be called, setting the value of the signal name to This is Angular, and thus the variable isRed will have the value true, applying the red css class

Conclusion

With the arrival of Angular 20, creating dynamic components by binding inputs and outputs has never been easier.

This new definition of the createComponent function gives us more freedom in the dynamic creation of components. The use case of dynamically creating a component based on certain conditions becomes much easier, to the point of imagining the possibility of “composing our dynamic components”.

In the future, it will therefore become increasingly easy to create Angular applications by applying the composition pattern.

The next improvement in Angular reactivity

Nicolas Frizzarin — Fri, 15 Nov 2024 13:43:20 +0000

Introduction

Since the latest versions of Angular, a new primitive reactivity system has been developed within the framework: signals!

Today, with hindsight, we realize that certain use cases had not been covered, and obviously the Angular team being very reactive will provide us with helpers to cover these uses cases.

What are these uses cases? What solutions are going to be put in place, and how are they going to be used?

Process of resetting one signal relative to another

Let's start by illustrating this problem.

Let's imagine we have a basket of fruit with a certain quantity.
The quantity is managed by a component, which inputs the fruit.

@Component({
  template: `<button type="button" (click)="updateQuantity()"> 
    {{quantity()}}
    </button>`
})
export class QuantityComponent() {
  fruit = input.required<string>();
  count = signal(1);

  updateQuantity(): void {
    this.count.update(prevCount => prevCount++);
  }
}

Here the variable must be reset if the input price fruit changes.

A simple solution would be to use an effect

@Component({
  template: `<button type="button" (click)="updateQuantity()"> 
    {{quantity()}}
    </button>`
})
export class QuantityComponent() {
  fruit = input.required<string>();
  quantity = signal(1);

  countEffect(() => {
    this.fruit();
    this.quantity.set(1);
  }, { allowSignalWrites: true })

  updateQuantity(): void {
    this.quantity.update(prevCount => prevCount++);
  }
}

The preceding code is bad practice. Why is this the big question?

We need to set the signalWrites option to true in order to set the signal quantity. This is due to a misinterpretation of the given problem.
In our case, we want to synchronize two variables which, in our materialization, are desynchronized

The counter is not independent of the fruit, which is our initial source. In reality, here we have a component state, whose initial source is the fruit and the rest is a derivative of the fruit.

Materialize the problem as follows

@Component({
  template: `<button type="button" (click)="updateQuantity()"> 
    {{fruitState().quantity()}}
    </button>`
})
export class QuantityComponent() {
  fruit = input.required<string>();

  fruitState = computed(() => ({
    source: fruit(),
    quantity: signal(1),
  }));

  updateQuantity(): void {
    this.fruitState().quantity.update(prevCount => prevCount++);
  }
}

This materialization strongly links the fruit to its quantity.
So as soon as the fruit changes, the computed variable fruitState is automatically recalculated. This recalculation returns an object with the quantity property, which is a signal initialized to 1.

By returning a signal, the variable can be incremented on click and simply reset when the fruit changes.

It's a relatively simple pattern to set up, but can't we simplify it?

The LinkedSignal function to the rescue.

With the arrival of Angular 19, a new function for calculating derived signals.

Until now, we had the computed function, but this function returns a Signal and not a WrittableSignal, which would have been practical in our previous use case for the quantity variable.

This is where LinkedSignal comes in. LinkedSignal, as its name suggests, allows you to strongly link two signals together.

If we return to our previous case, this function would allow us to simplify the code as follows:

@Component({
  template: `<button type="button" (click)="updateQuantity()"> 
    {{quantity()}}
    </button>`
})
export class QuantityComponent() {
  fruit = input.required<string>();
  quantity = linkedSignal({ source: fruit, computation: () => 1 });

  updateQuantity(): void {
    this.quantity.update(prevCount => prevCount++);
  }
}

The linkedSignal function is defined as follows:

linkedSignal(computation: () => D, options?: { equal?: ValueEqualityFn<NoInfer<D>>; }): WritableSignal<D>;

linkedSignal(options: { source: () => S; computation: (source: NoInfer<S>, previous?: { source: NoInfer<S>; value: NoInfer<D>; }) => D; equal?: ValueEqualityFn<NoInfer<D>>; }): WritableSignal<D>;

In the first definition, the “abbreviated” definition, the linkedSignal function takes a computation function as a parameter and a config object.

const quantity = input.required<number>();
const price = linkedSignal(() => quantity() * 0);

In this previous exemple, because the computation function depends of the quantity sigal, when the quantity change, the computation function is reevaluated.

In the second definition, the linkedFunction method takes an object as a parameter with three properties

the source: the signal on which the computation function bases its re-evaluation
the computation function
a parameter object

Contrary to the “abbreviated” computation function, here the computation function takes as parameters the value of the source and a “precedent”.

const fruits = signal(['apple', 'orange']);
const choice = linkedSignal({
  source: fruits,
  computation: (source, previous) => {
    if(!Boolean(previous)) {
      return 'apple';
    }
    return previous.source.find(fruit => fruit === previous.value) ||   
      'apple';
  }
})

The new Resource Api

Angular 19 will introduce a new API for simple data fetching and retrieval of query status (pending etc), data and errors.

For those who are a little familiar with the framework, this new API works a bit like the useRessource hook.

Let's take a look at an example:


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

@Component()
export class FruitComponent {
  fruitId = input.required<string>();
  fruitRessource = resource({
    loader: () => {
      return fetch(`https://myFruit.com/${this.fruitId()}`).then(response => 
      response.json());
    },
  });

  fruitRessourceEffect(() => {
    console.log("Status: ", this.todoResource.status());
    console.log("Value: ", this.todoResource.value());
    console.log("Error: ", this.todoResource.error());
  })
}

There are several things to know about this code snippet

There are several things to note in this snippet code:

by default, the loader takes a promise as parameter
the fruitRessource type is a WrittableRessource, which will enable us to modify the data locally if required
the request for fruit details is sent directly to the server when the resource fuitResource is created
this.fruitId() is untracked in the loader, so no new request will be send if the fruitId change
WrittableRessource have a method refresh to refresh the data

The following effect will print those value

Status: 'pending'
Value: undefined,
Error: undefined,

// When the promise is resolved, we enter again in the effect, because the status and value are signals and they changed

Status: 'resolved'
Value: { name: 'apple', count: 2 },
Error: undefined,

as explained above, by default the fruitId signal is untracked.

So how do you restart the http request each time the value of this signal changes, but also how do you cancel the previous request in the event that the value of the fruitId signal changes and the response to the previous request didn't arrive?

The resource function takes another property called request.

This property takes as its value a function that depends on signals and returns their value.


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

@Component()
export class FruitComponent {
  fruitId = input.required<string>();
  fruitRessource = resource({
    request: this.fruitId
    loader: (request, abortSignal) => {
      return fetch(`https://myFruit.com/${request}`}, { signal: abortSignal }).then(response => 
      response.json());
    },
  });

  fruitRessourceEffect(() => {
    console.log("Status: ", this.todoResource.status());
    console.log("Value: ", this.todoResource.value());
    console.log("Error: ", this.todoResource.error());
  })
}

As shown in the code above, the loader function takes two parameters

the request value: here the value of the fruitId signal
the value of the signal property of the abortController object used to cancel an http request.

So if the value of the fruitId signal changes during an httpRequest retrieving the details of a fruit, the request will be canceled to launch a new request.

Finally, Angular has also thought of the possibility of coupling this new api with RxJs, allowing us to benefit from the power of Rx operators.

Interporability is achieved using the rxResource function, which is defined in exactly the same way as the resource function.
The only difference will be the return type of the loader property, which will return an observable


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

@Component()
export class FruitComponent {
  fruitId = input.required<string>();
  fruitRessource = rxResource({
    request: this.fruitId
    loader: request => {
      return this.httpClient.get<any>(`https://myFruit.com/${request}`)
    }
  });

  fruitRessourceEffect(() => {
    console.log("Status: ", this.todoResource.status());
    console.log("Value: ", this.todoResource.value());
    console.log("Error: ", this.todoResource.error());
  })
}

Here it's not necessary to have the abortSignal, the cancelling of the previous request when the value of the signal fruitId change is implicit in the function rxResource and the behaviour will be the same as the switchMap operator.

@let: New feature compiler in Angular 18.1

Nicolas Frizzarin — Wed, 17 Jul 2024 09:19:30 +0000

Introduction

With the arrival of Angular 18.1, this version introduces an exciting new feature to the compiler: the ability to declare one or more template variables.
How is this feature used, and what are the different use cases?

This article aims to answer.

The compiler's latest feature: @let

With the latest versions of Angular, the team has introduced new functionality into the compiler, and this functionality translates into the @-syntax.

This is how the new control flow syntax came into being

and, more recently, @let

As a general rule, the easiest way to create a template variable was to use the

the *ngIf structural directive with the keyword as keyword

or using the new control flow syntax

@if with the keyword as

<!-- older control flow syntax -->
<div *ngIf="user$ |async as user">
  {{ user.name }}
</div>

<!-- new control flow syntax -->
@if(user$ |async; as user){
  <div>{{ user.name }}</div>
}

This handy feature allowed us to store the result of the async pipe in a variable for use later in the template.

However, this syntax raises a few questions. Here, the condition checks whether the return of the async pipe is true, and therefore whether the return value is different from any value considered false in javascript.

This condition will work really well if the return is an object or an array.

but if the return is a number and particularly the number 0

@if(((numbers$ |async) !=== undefined || (numbers$ |async) !=== null) ; as myNumber){
  <div>{{ myNumber }}</div>
}

This is where @let comes in.

@let doesn't check a condition, it just allows you to declare a local template variable in a simple way

so the code example above becomes much simpler and more elegant to write

@let myNumber = (numbers$ | async) ?? 0;
<div>{{ myNumber }}</div>

This way the myNumber variable will always be displayed.

The different ways of using @let

One of the most classic scenarios with variable declaration is to store the result of a complex expression.

It has always been inadvisable to use a function in a condition. The use of a function in a condition had an impact on performance in the sense that at the slightest mouse movement, or change in the template, the function was re-evaluated.

@let, as described above, does not evaluate, but simply declares a local variable. This variable will be reevaluated only if one of its dependencies changes. So calling a function is not a bad idea for expressions such as complex expression.

<ul>
  @for(user of users(); track user.id) {
    @let isAdmin = checkIfAdmin(user);
   <li>User is admin: {{ isAdmin }}</li>
  }
</ul>

Use the @let with signals

@let is compatible with signals, and is used as follows

@let userColor = user().preferences?.colors?.primaryColor || 'white';
<span>user favorite color is {{ userColor }}</span>

@let and javascript expression

As you can see, @let can be used to evaluate any kind of javascript expression, apart from, for example, the instantiation of a class

In this way, arithmetic operators are interpreted and several variables can be declared on several different lines or just on one line.

<div>  
    @for (score of scores(); track $index) {
        @let total = total + score, max = calcMax(score);
        <h1>final score: {{ total }}</h1>
    }
</div>

Other cool things that @let brings

As described above, the behaviour of @let is very similar to the behaviour of let in javascript, which has the following benefits

the scope works like the let scope in javascript
better typing interference in the template
an error is raised if a variable (let) is used before being declared

What'new in Angular 18

Nicolas Frizzarin — Tue, 28 May 2024 08:10:07 +0000

Introduction

Wednesday May 22, 2024, the Angular core team releases a new version of Angular: version 18.

This version not only stabilizes the latest APIs, but also introduces a number of new features designed to simplify use of the framework and improve the developer experience.

What are these new features? Read on to find out.

New Control flow syntax is now stable

When the latest version of Angular was released, a new way of managing the flow of a view was introduced. As a reminder, this new control flow is directly integrated into the Angular template compiler, making the following structural directives optional:

ngIf
ngFor
ngSwitch / ngSwitchCase

<!-- old way -->
<div *ngIf="user">{{ user.name }}</div>

<!-- new way -->
@if(user) {
  <div>{{ user.name }}</div>
}

This new API is now stable, and we recommend using this new syntax.

If you'd like to migrate your application to this new control flow, a schematics is available.

ng g @angular/core:control-flow

Also, the new @for syntax, which replaces the ngFor directive, obliges us to use the track option to optimize the rendering of our lists and avoid their total recreation during a change.

Two new warnings have been added in development mode:

a warning if the tracking key is duplicated. This warning is raised if the chosen key value is not unique in your collection.
a warning if the tracking key is the entire item and the choice of this key results in the destruction and recreation of the entire list. This warning will appear if the operation is considered too costly (but the bar is low).

Defer syntax is now stable

The @defer syntax, also introduced in the latest version of Angular, lets you define a block to be lazyloaded when a condition is met. Of course, any third-party directive, pipe or library used in this block will also be lazyloaded.

Here's an example of its use


@defer(when user.name === 'Angular') {
  <app-angular-details />
}@placeholder {
  <div>displayed until user.name is not equal to Angular</div>
}@loading(after: 100ms; minimum 1s) {
  <app-loader />
}@error {
  <app-error />
}

As a reminder,

the @placeholder block will be displayed as long as the @defer block condition is not met
the @loading block will be displayed when the browser downloads the content of the @defer block; in our case, the block loading will be displayed if the download takes more than 100ms, and will be displayed for a minimum duration of 1 second.
the @error block will be displayed if an error occurs while downloading the @defer block

What will happen to Zone js

Angular 18 introduces a new way of triggering a detection change. Previously, and not surprisingly, the detection change was handled entirely by Zone Js. Now, the detection change is triggered directly by the framework itself.

To make this feasible, a new change detection scheduler has been added to the framework (ChangeDetectionScheduler) and this scheduler will be used internally to raise a change detection. This new scheduler is no longer based on Zone Js and is used by default with Angular version 18.

This new scheduler will raise a detection change if

a template or host listener event is triggered
a view is attached or deleted
an async pipe receives a new value
the markForCheck function is called
the value of a signal changes etc.

Small culture moment: this detection change is due to the call to the ApplicationRef.tick function internally.

As I mentioned above, since version 18 Angular has been based on this new scheduler, so when you migrate your application, nothing should break in the sense that Angular will potentially be notified of a detection change by Zone Js and/or this new scheduler.

However, to return to the pre-Angular 18 behavior, you can use the provideZoneChangeDetection function with the ignoreChangesOutsideZone setter option set to true.

bootstrapApplication(AppComponent, {
  providers: [
    provideZoneChangeDetection({ ignoreChangesOutsideZone: true })
  ]
});

Also, if you wish to rely only on the new scheduler without depending on Zone Js, you can use the provideExperimentalZonelessChangeDetection function.

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

By implementing the provideExperimentalZonelessChangeDetection function, Angular is no longer dependent on Zone Js, which makes it possible to

remove the Zone js dependency if none of the project's other dependencies depend on it
remove zone js from polifills in angular.json file

Deprecation of HttpClientModule

Since version 14 of Angular and the arrival of standalone components, modules have become optional in Angular, and now it's time to see the first module deprecated: I've named the HttpClientModule

This module was in charge of registering the HttpClient singleton for your entire application, as well as registering interceptors.

This module can easily be replaced by the provideHttpClient function, with options to support XSRF and JSONP.

This function has a twin sister for testing: provideHttpClientTesting

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

As usual, the Angular team has provided schematics to help you migrate your application.

When issuing the ng update @angular/core @angular /cli command, a request will be made to migrate the HttpClientModule if used in the application

ng-content fallback

ng-content is an important feature in Angular, especially when designing generic components.

This tag allows you to project your own content. However, this feature had one major flaw. You couldn't give it a default content.

Since version 18, this is no longer the case. You can have content inside the tag that will be displayed if no content is provided by the developer.

Let's take a button component as an example

<button>
  <ng-content select=".icon">
   <i aria-hidden="true" class="material-icons">send</i>
  </ng-content>
  <ng-content></ng-content>
</button>

The icon send will be displayed if no element with the icon class is provided when using the button component

Form Events: a way to group the event of the form

It's a request that was made by the community a long time ago: to have an api to group together the events that can happen in a form; and when I say events, I mean the following events

pristine
touched
status change
reset
submit

Version 18 of Angular exposes a new event property from the AbstractControl class (allowing this property to be inherited by FormControl, FormGroup and FormArray), which returns an observable

@Component()
export class AppComponent {
  login = new FormControl<string | null>(null);

  constructor() {
   this.login.events.subscribe(event => {
    if (event instanceof TouchedChangeEvent) {
        console.log(event.touched);
      } else if (event instanceof PristineChangeEvent) {
        console.log(event.pristine);
      } else if (event instanceof StatusChangeEvent) {
        console.log(event.status);
      } else if (event instanceof ValueChangeEvent) {
        console.log(event.value);
      } else if (event instanceof FormResetEvent) {
        console.log('Reset');
      } else if (event instanceof FormSubmitEvent) {
        console.log('Submit');
      }
   })
  }
}

Routing: redirect as a function

Before the latest version of Angular, when you wanted to redirect to another path, you used the redirectTo property. This property took as its value only a character string

const routes: Routes = [
  { path: '', redirectTo: 'home', pathMath: 'full' },
  { path: 'home', component: HomeComponent }
];

It is now possible to pass a function with this property. This function takes ActivatedRouteSnapshot as a parameter, allowing you to retrieve queryParams or params from the url.
Another interesting point is that this function is called in an injection context, making it possible to inject services.

const routes: Routes = [
  { path: '', redirectTo: (data: ActivatedRouteSnapshot) => {
    const queryParams = data.queryParams
    if(querParams.get('mode') === 'legacy') {
      const urlTree = router.parseUrl('/home-legacy');
      urlTree.queryParams = queryParams;
      return urlTree;
    }
    return '/home';
  }, pathMath: 'full' },
  { path: 'home', component: HomeComponent },
  { path: 'home-legacy', component: HomeLegacyComponent }
];

Server Side Rendering: two new awesome feature

Angular 18 introduces two important and much-awaited new server-side rendering features

event replay
internationalization

Replay events

When we create a server-side rendering application, the application is sent back to the browser in html format, displaying a static page that then becomes dynamic thanks to the hydration phenomenon. During this hydration phase, no response to an interaction can be sent, so user interaction is lost until hydration is complete.

Angular is able to record user interactions during this hydration phase and replay them once the application is fully loaded and interactive.

To unlock this feature, still in developer preview, you can use the ServerSideFeature withReplayEvents function.

providers: [
  provideClientHydration(withReplayEvents())
]

Internationalization

With the release of Angular 16, Angular has changed the way it hydrates a page. Destructive hydration has given way to progressive hydration. However, an important feature was missing at the time: internationalization support. Angular skipped the elements marked i18n.

With this new version, this is no longer the case. Please note that this feature is still in development preview and can be activated using the withI18nSupport function.

providers: [
  provideClientHydration(withI18nSupport())
]

Internationalization

Angular recommends using the INTL native javascript API for all matters concerning the internationalization of an Angular application.

With this recommendation, the function helpers exposed by the @angular/common package have become deprecated. As a result, functions such as getLocaleDateFormat, for example, are no longer recommended.

A new builder package and deprecation

Up until now, and since the arrival of vite in Angular, the builder used to build the Angular application was in the package: @angular-devkit/build-angular

This package contained Vite, Webpack and Esbuild. A package that's far too heavy for applications that in future will use only Vite and Esbuild.

With this potential future in mind, a new package containing only Vite and Esbuild was created under the name @angular/build

When migrating to Angular 18, an optional schematic can be run if the application does not rely on webpack (e.g. no Karma-based unit testing). This schematic will modify the angular.json file to use the new package and update the package.json by adding the new package and deleting the old one.

Importantly, the old package can continue to be used, as it provides an alias to the new package.

Angular supports Less Sass Css and PostCss out of the box, by adding the necessary dependencies in your project's node_modules.

However, with the arrival of the new @angular/build package, Less and PostCss become optional and must be explicit in the package.json as dev dependencies.

When you migrate to Angular 18, these dependencies will be added automatically if you wish to use the new package.

No more donwleveling async/await

Zone js does not work with the Javascript feature async/await.
In order not to restrict the developer from using this feature, Angular's CLI transforms code using async/await into a "regular" Promise.

This transformation is called downleveling, just as it transforms Es2017 code into Es2015 code.

With the arrival of applications no longer based on Zone Js, even if this remains experimental for the moment, Angular will no longer downlevel if ZoneJs is no longer declared in polyfills.
The application build will therefore be a little faster and a little lighter.

An new alias: ng dev

From now on, when the ng dev command is run, the application will be launched in development mode.

In reality, the ng dev command is an alias for the ng serve command.

This alias has been created to align with the Vite ecosystem, particularly the npm run dev command.

Future

Once again, the Angular team has delivered a version full of new features that will undoubtedly greatly enhance the developer experience and show us that Angular's future looks bright.

What can we expect in the future?

Undoubtedly continued improvements in performance and developer experience.

We'll also see the introduction of signal-based forms, signal-based components and, very soon, the ability to declare template variables using the @let block.

Be ready for input signals in Angular

Nicolas Frizzarin — Wed, 10 Jan 2024 08:34:36 +0000

Introduction

With the release of Angular 17, the signals have become stable.

As a reminder, a signal is a wrapper around a value that can notify interested consumers when that value changes. Signals can contain any value, from simple primitives to complex data structures.

At present, the core team has only delivered the basic signals api. But its long-term goal is to go much further, and achieve signal change detection.

The next step is to have input and output based on signals. And this functionality should appear very soon this month with version 17.1.

How can we prepare for this functionality to facilitate the migration of our current Input and Output?

A litte reminder

Before getting straight to the heart of the matter, a quick reminder may be in order.

A signal is created using the signal function.

const name = signal<string | null>('DevTo');

This function returns a WritableSignal, enabling us to modify the value of our signal using the methods:

set
update

const count = signal(0);
count.set(10);
count.update(count => count + 1);

A signal can also be made readonly using the asReadonly function.

const count = signal(0);
const readonlyCount = count.asReadonly();

Why passing a signal as an input is a very bad idea ?

Working with signals in a real application can sometimes become very complicated, especially with components that take inputs.

As a reminder, modifying change detection in OnPush mode with signals improves performance, especially page refresh speed.

When a signal is used in the template of an OnPush component, Angular automatically adds it as a reactive dependency of the component, and each time this signal is modified, Angular will automatically mark the component as dirty, which will ensure that the component is refreshed the next time the change detection is run.

Now let's imagine two components with a parent-child relationship


@Component({
  selector: 'app-father',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  imports: [AppChildComponent],
  template: `<app-child [name]="name" />`
})
export class AppFatherComponent {
  name = signal('DevTo');
}


@Component({
  selector: 'app-child',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  template: `{{ name() }}`
})
export class AppFatherComponent {
  @Input({ required: true }) name !: WritableSignal<string>
}

Passing a signal as input to a child component have several problems:

unidirectional binding is lost
you force the parent to use signals
you lose the granularity of the detection change

Unidirectional binding and granularity of the detection change

When we pass a signal as input, we don't pass the value of the signal but actually its reference.

It therefore becomes normal that if the signal is modified in the child, the parent is also impacted, so a detection change cycle will have to be lifted in both the parent and the child.

An Angular application is nothing more than a tree of components, so by passing signals as input, no matter whether the component is OnPush or not, each modification of the signals in the child components will automatically trigger a change of detections in the parent, thus losing the added value of the OnPush mode.

What's more, by passing a signal as input, the logic of data centralization is totally lost, as any descendant of a parent component can modify the variable, and in the event of a bug we end up with a spaghetti node that's very complex to debug.

Force the parent to use signals

One of the workarounds used to avoid the above problems would be to switch the signals to readonly mode.

Apart from being unsightly and an anti-pattern, this would force the parent component to use signals. In other words, all inputs passed to child components must be signals.

Which makes no sense, as the parent component should be able to pass simple variables to its children.
What's more, when input signals arrive, all the code will have to be refactored.

Input as a setter for the win

In Angular, inputs can be setters. This will help you to create signal-based inputs.

This technique will avoid the problems analyzed above, but there may well be a few more boilerplates while we wait for release 17.1.

The idea is to transform all our Inputs into an aliased Input setter and create the signal associated with this input.

Let's take the example above


@Component({
  selector: 'app-father',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  imports: [AppChildComponent],
  template: `<app-child [name]="name" />`
})
export class AppFatherComponent {
  name = signal('DevTo');
}


@Component({
  selector: 'app-child',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  template: `{{ name() }}`
})
export class AppFatherComponent {
  @Input({ required: true, alias: 'name' }) set _name(name: string) {
    this.name.set(name);
  }
  name = signal<string>('');
}

With this method, the parent component is totally flexible on the type of variable passed to child components, unidirectional binding is respected and migration to signal inputs is simplified.

In fact, with version 17.1, all you need to do is remove the input setter and replace the signal function with the input function

Inputs Signal

Input signals are declared using the input function

This function not only creates readonly signals, but also ensures that the metadata passed to the input annotation is not lost.

const name = input<string>(''); // input with default value
const name = input<string>(); // input with no default value
const name = input.required<string>() // input mandatory
const name = input<string>('', { alias: 'lastname' }); // with alias
const isLoading = input<string | boolean; boolean>('', { transform: booleanAttribute });

If we go back to our previous example, the code would be as follows:


@Component({
  selector: 'app-father',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  imports: [AppChildComponent],
  template: `<app-child [name]="name" />`
})
export class AppFatherComponent {
  name = signal('DevTo');
}


@Component({
  selector: 'app-child',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  template: `{{ name() }}`
})
export class AppFatherComponent {
  name = input.required<string>();
}

What will happen in the future ?

Based on this shema, reactivity and change of detection within Angular will take place around signals.

In a few months' time, we hope to be able to do without ZoneJs with OnPush components that use signals, as well as creating components based signals like this

@Component({
  selector: 'app-father',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  signals: true,
  imports: [AppChildComponent],
  template: `<app-child [name]="name" />`
})
export class AppFatherComponent {
  name = signal('DevTo');
}

What's new in Angular 17

Nicolas Frizzarin — Thu, 16 Nov 2023 08:00:10 +0000

Introduction

Angular version 17 was released on November 8, 2023, and this application sounds like an hour of rebirth for the framework, which dates back to September 2016.

First and foremost, while we're talking about rebirths, we're not talking about a complete rewrite of the framework. We're talking about adding major functionalities that use the latest browser features and make the framework even more powerful.

The questions that remain are: How is this release a major turning point for Angular? What makes this release so exceptional?

A new Branding

After a few days where the Angular logo had disappeared, replaced by a question mark on social networks such as X to name but the most famous, on Monday November 6, the Angular team announced a new Logo but also a brand new documentation site available here.

This brand-new site (still under construction in terms of APIs) brings many improvements, such as:

the ability to experiment with features in a sandbox
new tutorials with the option of creating them in a sandbox
a brand-new organization by theme (component, form, accessibility, best practices, etc.).

Don't hesitate to give it a try, and report any questions or errors you come across.

The @Component annotation

The @Component anotation has been improved. Since the beginning of Angular, it has been mandatory to pass a style array or an array of relative stylesheet paths to bind style to our components.

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {}

In general, a view is linked to a style sheet.

a new property is introduced: styleUrl
the styles property takes as its value a string or an array of strings

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrl: './app.component.css'
})
export class AppComponent {}

The new Application builder

Angular has always had different builders to build our applications. There are two main types of Angular application:

client-side rendering: the entire application is built client-side. In other words, the application is represented in DOM (Document Object Model) format. Navigation, data fetching and templating are managed client-side instead of server-side.
server side rendering: the application is rendered in HTML format, each page of the application is rendered in HTML format in response to navigation, and then this page is rehydrated to make it dynamic.

Depending on the type of application, the builder was different.
Angular used the builder:

@angular-devkit/build-angular:browser to build a client-side rendering application
@nguniversal/builders:ssr-dev-server to build a server-side rendering application.

With the arrival of Angular 16, a new experimental builder has appeared:
@angular-devkit/build-angular:browser-esbuild. This builder made it possible to use vite for the dev-server and esbuild for the build, and offered outstanding performance:

87% gain on an application build
82% gain on a dev-server of the application

However, the builder for server rendering had not changed.
With the arrival of Angular 17, a brand-new "generic" builder has appeared. This builder allows you to build both a client-side rendering application and a server-side rendering application.
A round of applause for the builder:
@angular-devkit/build-angular:application

For existing applications using the builder: @angular-devkit/build-angular:browser-esbuild, migration to the new builder is relatively straightforward.

For server-side rendering applications, migration is a little more complex due to the number of properties to be changed.

The new Angular Code Flow

The release of Angular 17 also sees the arrival of a new, more powerful flow code.
In previous versions, we used structural directives ngIf, ngSwitch, ngFor to manage the structure of our page.
Structural directives are very powerful, thanks to the mycrosyntax of which they are composed. Unfortunately, this mycrosyntax has its limits, and so a new flow code was created.

What does this code flow look like?

@Component({
  standalone: true,
  selector: 'app-root',
  template: `
    @if(name === 'SFEIR'){
      <ul>
         @for(entity of entities; track entity.id) {
           <li>{{ entity.name }}</li>
         }@empty {
           No data
         }
      </ul>

    }@else {
      Name not correct
    }
  `
})
export class AppComponent {
  name = 'SFEIR';
  entities = [{ name: 'Luxembourg', id: 'LU' }];
}

As the code shows, there's no need to import the ngIf and ngFor directives. This new code flow is build-in to Angular and will enable simpler integration of components based on Angular signals.

Structural directives are not deprecated and there are no plans to make them deprecated.
In future, only the ngIf, ngFor and ngSwitch directives are likely to be deprecated.

If you want to automatically migrate your components to the new code flow, this schematic will be your best friend

ng g @angular/core:control-flow

Warning: This new flow code is very recent, so you may encounter some formatting problems. (prettier 3.1 now supports this code flow)

IDEs:

VsCode with Angular Language Service plugins already supports syntax highlighting
Webstorm EAP also supports syntax highlighting. Unfortunately, template checking is not yet supported, but will be shortly.

The most waited feature: defer

Probably one of the most important features of this release. The ability to lazyload our components easily.

Of course, we could do this before. Thanks to EsModules and the *ngComponentOutlet structural directive, it was possible to lazyload our components. However, this technique remains a source of error, in the sense that the developer has to think about the whole loading process (loading, error, etc.) and is limited in scope (complicated prefetching, etc.). In short, the developer experience wasn't there.

With Angular 17, defer comes to the rescue, making it easy to lazyload our components by taking into account all the stages of lazyloading.

@Component({
  selector: 'app-root',
  template: `
    <button type="button" #loadButton>Click Me</button>
    @defer(on interaction(loadButton)) {
      <app-lazy-component />
    }@placeholder {
      showed until the chunk file not begin to load
    }@loading {
      showed during the loading of the chunk
    }@error {
      showed if an error happen during loading
    }
  `
})
export class AppComponent {}

There are many other options for defer, placeholder, loading. To get the most out of this feature, I recommend Tomas Trajan's fabulous article here.

Like all good things, you mustn't abuse it. Depending on your needs, defer should be applied in certain ways. As a general rule, defer will depend mainly on your network and the size of the component to be lazyloaded. Last but not least, this feature will be invaluable for optimizing Core Web Vitals' LCP and CLS metrics.

A little word about Signals

Signal was released as a developer preview with Angular 16. With Angular 17, Signal is stable and can be used.
Combined with the ChangeDetection.OnPush option, you'll operate a very precise reactivity, allowing you to refresh only the component whose signal has been modified.

The mutate method on signals is no longer available.

Effects are still in developer preview.

Angular Devtools

Angular Devtools has also been given a very nice little feature 😄 it's now possible to view the injection tree. Very useful for debugging your application when you have circular dependencies, or when a token isn't resolved correctly.

Conclusion

Angular 17 really does bring a lot of new features, and it's in this sense that we're talking about an Angular reborn. Angular 17, like all previous releases, brings no breaking changes, so it's very easy to migrate an application from Angular 16 to Angular 17.

You don't have to use all these new features; they're available for developers to try out.

Angular: How to test functional guards, resolver and intercpetors

Nicolas Frizzarin — Wed, 16 Aug 2023 08:00:48 +0000

Introduction

Since version 14 of Angular, the inject function can be used outside the injection context, making it easier to compose screens and transform gards, resolvers and interceptors into simple functions.

However, testing a service in the form of classes is much more straightforward than testing a function in which the inject function is used.

This article looks at testing of guards, resolvers and interceptors as functions.

Injector level

To understand how to properly test our guards, etc. as functions, it's important to understand how injection works and how the value of a service is retrieved.

In Angular, there are different types of injector, or to be more precise, different levels of injector:

Element Injector: This is the injector at the component level for exemple.

@Component({
  template: '',
  providers: [UserService]
})
export class UserComponent {}

module injector: This is the injector specific to the module.

@NgModule({
  declarations: [UserComponent],
  providers: [UserService]
})
export class UserModule {}

Environment Injector: Now Angular introduced a new class called EnvironmentInjector. Thanks to that we are able to make an injection wherever we want. They expect this functionality to be very useful for designing ergonomic APIs.
There is something we need to not forget. EnvironmentInjector is completely independent from Component tree. It’s a module injector, so it can’t inject anything that is not in module or router.
Root Injector: This is the top level of injector. Provider register in the root injector is accessible everywhere in the application

@Injectable({ provideIn: 'root'})
export class UserService {}

When a service is called in a component, Angular will attempt to resolve the value of that service by performing injector bubbling as follows

If the service is not found in any injector, Angular will raise an error specifying that it has failed to resolve the value of the requested service.

Test your functional guard, resolver, interceptors

What's difficult to test in guards written as functions is not the function itself, but the inject function used within it.

Example:

export function UserDetailsResolver(
route: ActivatedRouteSnapshot): Observable<User> {
  const userService = inject(UserService);
  return userService.getUserDetails(route.paramMap.get('id'))
}

If we want to be able to test our function correctly, we'll need to be able to call it in an injection context (and therefore implicitly create an environment injector).

In the application context, to carry out this type of process, the function to use is the runInInjectionContext function.

runInInjectionContext(injector, () => {});

This function takes the following parameters

the injector in which the value of the service you wish to resolve with the inject function is located
the function to run in the injector context

Typically, this is exactly the function you'd use to mock the injection of the UserService service.

However, our context is a little different in that it's the test context and not the application context.

Once again, Angular has thought of everything, and this same function can be found in tests using the TestBed class.

If you wish to use the runInjectionContext function, you must create an injection context.

const MOCK_USER_SERVICE = {
  getUserDetails: jest.fn(),
};

const MOCK_ROUTE = {
  paramMap: new Map(['id', 123]),
};

describe('UserDetailsResolver', () => {
  let service: UserService;

  beforeEach(waitForAsync(() => {
    TestBed.configureTestingModule({
      providers: [{ provide: UserService, useValue: MOCK_USER_SERVICE }]
    });

    service = TestBed.inject(UserService);
  }));

  test('should create an instance of UserService', () => {
    expect(service).toBeInstanceOf(Userservice);
  });
});

Once the injection context is set, simply call the guard function in the injection context.

test('should return the details of the user', fakeAsync(() => {
  MOCK_USER_SERVICE.getUserDetails.mockResolvedValue(of({ name: 'Nicolas' }));

  let user: User | null = null;

  const resolver: Observable<User> = TestBed.runInInjectionContext(() => {
    return UserDetailsResolver(MOCK_ROUTE);
  });

  resolver.subscribe(response => (user = response));
  tick();

expect(MOCK_USER_SERVICE.getUserDetails).toHaveBeenCalledTimes(1);
expect(MOCK_USER_SERVICE.getUserDetails).toHaveBeenCalledWith(123);
expect(user).toEqual({ name: 'Nicolas' })
});

The return type of the runInjectionContext function corresponds to the return type of the function called in the injection context.

 runInInjectionContext<T>(fn: () => T): T

In our case, the return type of the UserDetailsResolver function is an Observable.

To summarize, the test file corresponding to the UserDetailsResolver function is as follows:

const MOCK_USER_SERVICE = {
  getUserDetails: jest.fn(),
};

const MOCK_ROUTE = {
  paramMap: new Map(['id', 123]),
};

describe('UserDetailsResolver', () => {
  let service: UserService;

  beforeEach(waitForAsync(() => {
    TestBed.configureTestingModule({
      providers: [{ provide: UserService, useValue: MOCK_USER_SERVICE }]
    });

    service = TestBed.inject(UserService);
  }));

  test('should create an instance of UserService', () => {
    expect(service).toBeInstanceOf(Userservice);
  });
  test('should return the details of the user', fakeAsync(() => {
  MOCK_USER_SERVICE.getUserDetails.mockResolvedValue(of({ name: 'Nicolas' }));

  let user: User | null = null;

  const resolver: Observable<User> = TestBed.runInInjectionContext(() => {
    return UserDetailsResolver(MOCK_ROUTE);
  });

  resolver.subscribe(response => (user = response));
  tick();
expect(MOCK_USER_SERVICE.getUserDetails).toHaveBeenCalledTimes(1);
expect(MOCK_USER_SERVICE.getUserDetails).toHaveBeenCalledWith(123);
  expect(user).toEqual({ name: 'Nicolas' })
  });
});

In this article, the example corresponds to a resolver written as a function.
Interceptors and guards written as functions use exactly the same concepts as the resolver shown as an example in this article. The method used to test them will therefore be the same as that used to test the example resolver.

Angular: Transform your inputs at will and simply

Nicolas Frizzarin — Wed, 24 May 2023 08:25:48 +0000

Introduction

Since the beginning of Angular, parent-child communication is done using @Input() @Output() annotations.
@Input() is a powerful annotation that allows to pass data from a parent component to a child component.
One of the wishes of the community was to be able to transform the data passed in Input in an easy way.

...And soon this wish will become a reality. The purpose of this article is to describe a feature that will arrive very soon and to give you some examples of use.

Context

Let's imagine that we want to transform an input that takes a string as parameter into a boolean.
This transformation would allow us to write

<app-expand expanded />
<app-expand expanded="true" />
<app-expand [expanded]="true" />

To be able to write our calls to our children's components in this way, several ways are available to us:

the getter and setter method
create its own annotation
the transform property of the metatada of the @Input() annotation (not yet released)

Getter and setter

@Component({ selector: 'app-expand' })
export class ExpandComponent {
  #expand = false;
  @Input() set expanded(value: string | boolean) {
   this.#expand = value !== null && 
    `${value}` !== 'false';
  }
  get expanded() {
   return this.#expand;
  }
}

The getter/setter method is a common pattern in our Angular components.

In the previous piece of code, when the developer sets the input expanded, the setter code is executed and the transformation is performed.
In this transformation I don't check if the passed value is undefined to allow the following HTML writing.

<app-expand expanded />

This solution could be sufficient but has a very big problem.
In general a component has several inputs, if each input requires a transformation, the component may grow for very little added value.

A nicer and more durable solution in the future would be to create your own decorator.

Create your own property decorator

In javascript a decorator is a simple function. In the case of a property decorator, it must be placed before the property and is described by a function taking two parameters:

target
key

The key actually represents the name of the property
The target represents the constructor function of the class for a static member, or the prototype of the class for an instance member.

A decorator transforming a string value into a boolean could be the following.

type SafeAny = any;

function toBoolean(value: string | boolean): boolean {
  return value !== null && `${value}` !== 'false';
};

function InputBoolean(): (target: SafeAny,name: string) => void {
  return function(target: SafeAny, name: string) {
    let value = target[name];
      Reflect.defineProperty(target, name, {
      set(next: string) {
        value = toBoolean(next);
      },
      get() {
        return value;
      },
      enumerable: true,
      configurable: true,
    })
  }
}

This decorator allows us to centralize the transformation logic and can be used as follows in the component:

@Component({ selector: 'app-expand' })
export class ExpandComponent {
  @Input() @InputBoolean() expanded = false;
}

Why not using @InputBoolean alone without @Input? AOT compiler needs @Input to be visible.

This method of creating a decorator is elegant and allows to centralize the logic without having unnecessary boilerplate in the components.

Nevertheless, decorators are still an experimental notion and the concept is not necessarily easy to understand at first.

That's why Angular now allows us to use the simple transform property in the metadata of the Input decorator to perform simple transformations.

A new way to transform

Since Angular 16, the @Input decorator takes metadata as a parameter. This recent novelty has been integrated in Angular to make an input required.

Soon these metadata can also take a transformation function.


function toBoolean(value: string | boolean): boolean {
  return value !== null && `${value}` !== 'false';
};

@Component({ selector: 'app-expand' })
export class ExpandComponent {
  @Input({ transform: toBoolean }) expanded = false;
}

very easy isn't it ? The transformation is done with a simple function which increases the developer experience considerably.

Obviously the Angular team does not stop. Transforming a string into a boolean or a string into a number are quite common. In this sense Angular will provide us with helpers functions to avoid recoding this logic.

import { booleanAttribute, numberAttribute } from '@angular/core';

What's new in Angular 16

Nicolas Frizzarin — Wed, 19 Apr 2023 08:45:46 +0000

Since the release of Angular 14, it is undeniable that each version brings a lot of new features, and Angular 16 will not be the exception.

For a while now we've been hearing about the integration of the Signals pattern in Angular, but Angular 16 brings much more than this novelty.

What are they? How to implement them?

Everything you want to know is here!

Signals

The Signal pattern is in place since the beginning in the Solid Js library and is based on the push/pull pattern.

As the name suggests, pull allows you to retrieve the value and push allows you to set a new one or to mutate it.

Anyway a signal always has a value and the retrieval of this value is always done synchronously.

In version 16 of Angular, the pattern base API will be integrated and will allow to get more performance in the way Angular handles change detection.

The question is why?

At the start of an Angular application, the framework overrides some of the browser's low-level APIs like the addEventListner function.

This override is done using the Zone JS library. Zone is a library that Angular uses under the hood to trigger a change detection by listening to

DOM events like click, mouseover...
HTTP requests
setTimeout, setInterval functions

So when something changes in your application, a change detection is performed and your page is refreshed.

Like any application created with a client side rendering framework, your application is materialized by a component tree.

In Angular, each component is associated with a change detector. So it becomes logical that if something changes in one of the child components, the whole tree is re-evaluated without even taking into account the dependencies of each component. We call this dirty checking.

Even if your application's change detection is in OnPush mode, the change detection cycle will go through the entire tree, unlike the default mode, OnPush components with no change dependencies will not be re-evaluated.

Therefore it is clear that the change of detection in Angular is not optimal, and it is in order to solve this problem that the integration of Signal will help.
With Signal, the granularity of the change detection level is done at the level of the signal variable. Thus a change detection will be done at the component level only when the signal changes without the need to traverse the whole tree and without the need of Zone JS. In the future, Zone Js could be optional.

Creating a signal in Angular is easy, just call the signal function with an initial value.

const counter = signal(0) // create a signal with initial value to 0;

console.log(this.counter()) // display 0

The signal function returns a WritableSignal that allows us to mutate or set a new value to our signal.

/**
Set function let to set a signal's value with a new value. Usefull if you need to change the data structure when the new value is not dependent of the old one.

Notify all dependents.
**/
set(value: T): void;

/**
Update function let to update the signal's value if the update depends on the precedent value.
In other words this function help if you want to update the value of the signals in a immutable way.

Notify all dependents.
**/
update(updateFn: (value: T) => T): void;

/**
Mutate function let to update the signal's value by mutating it in place.
In other words this function is useful for making internal change to the signal's value without changing its internal identity.

Notify all dependents.
**/
 mutate(mutatorFn: (value: T) => void): void;

/**
Return a readonly signal.
**/
asReadonly(): Signal<T>;

Computed

The calculated signals allow to create derived signals from other dependency signals.

const person = signal<{ firstname: string; lastname: string}>({ firstname: 'John', lastname: 'Doe'})

// Automatically updates when person() change;
const presentation = computed(() => ${person().firstname}${person().lastname}`;

A calculated signal is only re-evaluated if one of the dependent signals has changed

Computed can be a replacement of the famous Pipe.

Effect

The effects make it possible to carry out operations of side effects which read the value of zero or more signals, and is automatically scheduled to be re-run whenever any of those signals changes.

The Api is designed as follows:

function effect(
  effectFn: (onCleanup: (fn: () => void) => void) => void,
  options?: CreateEffectOptions
): EffectRef;

A concrete example can be the following

query = signal('');
users = signal([]);
effect(async (onCleanup) => {
  const controller = new AbortController();
  const response = await fetch('/users?query=' + query())
  users.set(await response.json());
  onCleanup(() => controller.abort())
})

Signals are a primitive reactive system in Angular. This means that they can be used in the component but also outside, for example in services.

Automatic route params mapping

Let's imagine a routing like this:

export const routes: Routes = [
 { path: 'search:/id',
   component: SearchComponent,
   resolve: { searchDetails: searchResolverFn }
 }
]

Before Angular 16, it was mandatory to inject the ActivatedRoute service to retrieve the url parameter but also the query parameters or the data associated to this url.

@Component({...})
export class SearchComponent {
  readonly #activateRoute = inject(ActivatedRoute);
  readonly id$ = this.#activatedRoute.paramMap(map(params => params.get('id');
  readonly data$ = this.#activatedRoute.data.(map(({ searchDetails }) => searchDetails)
}

With Angular 16 it will no longer be necessary to inject the ActivatedRoute service to retrieve the various route parameters because these can be directly binded to component inputs.

To activate this functionality, for an application that uses the module system, the option to activate is in the RouterModule options.

RouterModule.forRoot(routes, { bindComponentInputs: true })

For a standalone application, this is a function to call.

provideRoutes(routes, withComponentInputBinding());

Once the functionality is activated, the component is very simplified.

@Component({...})
export class SearchComponent {
  @Input() id!: string;
  @Input() searchDetails!: SearchDetails
}

Required Input

A much-awaited feature for the community was the ability to make certain inputs required.

Until now, there have been several workaround used to achieve this:

raise an error in the NgOnInit Lifecycle if the variable was not defined
modify the selector of our component to include the different inputs that were mandatory.

These two solutions had their advantages but also their disadvantages.

From version 16, making an input required will be a simple configuration object to be passed to the metadata of the input annotation.

@Input({ required: true }) name!: string;

New DestroyRef injector

Angular v16 has introduced a new provider called DestroyRef, which allows for registering destroy callbacks for a specific lifecycle scope. This feature is applicable to components, directives, pipes, embedded views, and instances of EnvironmentInjector.

This usage is quite simple.

@Component({...})
export class AppComponent {
  constructor() {
    inject(DestroyRef).onDestroy(() => {
      // Writte your cleanup logic
    })
  }
}

With this new provider, Angular allows us to share some classic cleaning logic such as the unusubscription of our observables.

export function destroyed() {
  const replaySubject = new replaySubject(1);

  inject(DestroyRef).onDestroy(() => {
    replaySubject.next(true);
    replaySubject.complete();
  });

  return <T>() => takeUntil<T>(replaySubject.asObservable());
}

@Component({...})
export class AppComponent {
  readonly #untilDestroyed = untilDestroyed();

  ngOnInit() {
    interval(1000)
      .pipe(this.#untilDestroyed())
      .subscribe(console.log);
  }
}

Vite as Dev Server

With the arrival of Angular 14 has been introduced the possibility to use a new Javascript Bundler: EsBuild

This new Bundler has the ability to be very fast and could reduce the build time by about 40%. The main problem is that this new feature and performance gain could only be used for a build and not during development (dev server).

In the next release of Angular, Esbuild can also be used during development thanks to Vite.

To activate this feature in the angular.json file update the builder like this:

"architect": {
 "build": {
  "builder": "@angular-devkit/build-angular:browser-esbuild",
     "options": { ... }

Attention this functionality is still experimental.

Non Destructive hydration

Angular allows you to create server side rendering applications with the help of Angular Universal.

The problem was that in general we could find ourselves creating applications that were not very efficient, mainly due to the hydration.
Until now hydration was destructive. That is to say that the whole page was destroyed and then completely rebuilt and rendered once the browser had recovered the Javascript and executed it.

The good news is that the apis have been rewritten to allow partial hydration. That is to say that once the html is loaded and the DOM is done, the whole structure will be traversed to attach the different event listener and recreate the state of the application to make the application reactive but without rendering it a new time.

Conclusion

The version 16 of Angular brings without any doubt some nice new features. Some of them are still experimental like signals or vite like dev server.

Anyway these new features will undoubtedly change the way we code our Angular applications by making them less boilerplate, even more optimized and by opening the door to the integration of new technologies like vitest or playwright in a simpler way.

The version 16 of Angular is not yet released some api described in this article may still change. Nevertheless this gives you an idea of what you can expect from the next release of Angular.

Make your design compatible with foldable device

Nicolas Frizzarin — Thu, 16 Feb 2023 14:42:57 +0000

Introduction

The way to think about the design of an application has never been simple.
How to correctly represent the information to the user? How to make the design pleasant and easy to use? How to adapt the interface to different sizes? are recurrent questions to ask when creating a user interface.

Over the years, technology has continued to progress, and the Desktop First design approach has been quickly replaced by a Mobile First approach.

In September 2020 Samsung released the very first foldable device: the Galaxy Fold. This release of a brand new type of screen once again upsets the design approach we had until then. Mobile First approach is not enough anymore, developers and designers will have to take into account a new type of screen.

The era of responsive design has evolved again.

So how to make our application responsive to this type of screen? How to take into account the different foldable screen layouts?

This article aims to answer these questions and give you the necessary information to create responsive design on foldable device.

Warning: the features described in this article are still experimental, may change in the future and are only available behind the flag: Experimental Web Platform features of chrome.

Posture of foldable device

There are several possible postures with foldable devices. These postures depend mainly on the angle of inclination.

Some examples to better understand:

an angle of 0 corresponds to a closed device
an angle of 140 corresponds to a laptop or book shaped device
an angle of 185 corresponds to a fully open device

The javascript and css API's must therefore take all these variations but also future scenarios.
It's not to be neglected that tomorrow a device can be foldable on the horizontal axis and at the same time on the vertical axis.

Viewport segments

By default, if we don't take into account the possibility of having a device with two or more screens, the design of our application may be "broken".
But what does broken mean? Well, it can be broken like the site you are reading this article on.

This image illustrates very well the fact of having a broken design. This emulation was done on a duo surface. The fold of this device hides some words, letters etc.

To solve this problem and tell to the browser where to placed the elements, a new media query is available: viewport-segments
This media query is declined in two ways:

horizontal-viewport-segments
vertical-viewport-segments

Why two varieties? Well, simply because your device can be oriented in two different ways:

portrait
landscape

If the device is oriented in landscape mode, this naturally means that the device have 1 or more screens on the horizontal axis. The media query to use will be the one associated with the horizontal axis.

@media(horizontal-viewports-segments /**number of screen**/){}

If the device is oriented in portrait mode, as opposed to landscape mode, the device have 1 or more screens on the vertical axis. The media query to use will be the one associated to the vertical axis.

@media(vertical-viewports-segments /**number of screen**/){}

An example in image will be more telling.

In the case of a duo surface, if the device is oriented in landscape mode, the media query will be written as follows:

@media(horizontal-viewport-segments 2) {}

Conversely, if the duo surface is oriented in portrait mode, then the media query will be written in this way:

@media(vertical-viewport-segments 2) {}

In itself the media query viewport-segments does not help to design the application. This media is used to identify the number of screens on which the application will be displayed.

To be able to correctly place the different design elements of our application around the "fold", six new environment variables have been created.

Environments variable

Environment variables in CSS allow you to factor awkward device intrusions into your styles.

Let's take the example of iphones from version X. All these phones have a notch which can break the design of your application.
To place correctly the elements around this notch, environment variables have been created. This is the case for example of the environment variable safe-area-inset-top.

In the case of foldables devices 6 new environment variables appear:

viewport-segment-width
viewport-segment-height
viewport-segment-top
viewport-segment-right
viewport-segment-bottom
viewport-segment-left

These keywords are to be used in the env() function. The css environment variables behave like custom properties, which means that an additional value can be passed to the env function as a callback value in case the environment variable does not exist.

The environment variables are mainly based on the viewport. It is therefore necessary to add a meta tag in the main HTML page.

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">

To use a foldable device environment variable, the syntax is as follows:

env(viewport-segment-width x y, /** fallback value **/)

x is the index of the screen on the horizontal axis and y is the index of the screen on the vertical axis.

For example, if we want to retrieve the size of the second screen on the horizontal axis, the syntax will be the following

width: env(viewport-segment-width 1 0)

A diagram is always more representative than a long speech

With these environmental variables, a multitude of design possibilities are available to us.

We could for example put on a screen a fixed image and on another one a long scrollable text.

Let's code it :)

<!DOCTYPE html>
<html lang="en">

  <head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="index.css">
    <title>Document</title>
  </head>

  <body>
    <main>
      <aside>
        <img alt="foldable device image" src="./foldable_screen.jpeg" />
      </aside>
      <article>
        Long scrollable text ...
      </article>
  </body>
</html>

html {
  height: 100%;
  width: 100%;
  margin: 0;
  padding: 0;
  overflow: hidden;
}

body {
  margin: 0;
  padding: 0;
}

main {
  display: flex;
  height: 100%;
  width: 100%;
}

@media (horizontal-viewport-segments: 2) and (vertical-viewport-segments: 1) {
  aside img  {
    position: absolute;
    height: 100%;
    width: env(viewport-segment-width 0 0);
    top: env(viewport-segment-top 0 0);
  }
  main article {
    position: absolute;
    box-sizing: border-box;
    padding-left: 1rem;
    height: 100%;
    overflow: auto;
    left: env(viewport-segment-left 1 0);
  }
}

The two lines

width: env(viewport-segment-width 0 0)
top: env(viewport-segment-top 0 0) allow you to specify the position of the image and its size. In our case I want to place the image on the whole first screen.

The line left: env(viewport-segment-left 1 0) allow to place the text on the whole second screen. For visual aesthetics, the padding-left property allows to shift the text from the fold.

The result is the following:

Reacting to resize or posture change events

Sometimes we may want to realize some Javascript logic depending on the different posture of the device, or want to react to the resize.

For this javascipt allows us to easily retrieve the number of screen of the device

window.addEventListener(() => {
 console.log(window.visualViewport.segments);
/**
If no segments this seems that the foldable device is closed.
If one or more segements window.visualViewport.segments is an array
**/
})

Want to play with these amazing API's

First activate in the chrome flags

Experimental JavaScript
Experimental Web Platform features
Device Posture API

In the chrome devtools console, go to the settings section then go in the experiments panel and activate the option Emulation: Support dual screen mode

You are ready to go, now its possible to select suface duo or galexy fold device when you emulate a mobile device ;)

Conclusion

Are foldable screens the next generation of mobile? It's still way too early to tell; so it's very important for a web developer to keep an open mind and code the design of his application so that it is adaptable to whatever the future may bring. This is what responsive design offers.

The responsive design offers you a set of practical techniques but also an open mind that will allow you to adapt your applications for the web of tomorrow.

Forem: Nicolas Frizzarin

Angular Signals Form: Validation and Logic

Introduction

Just a reminder

Adding Field Logic

Let's have some logic

The validate function

The error function

Composition built-in

Conclusion

Signals Form: Introduction

Introduction and Disclaimer

Mindset of Signal Forms

A tree of Field

Field Instance

Binding the field to UI elements

Conclusion

The Next Generation of Dynamic Component

Préambule

Introduction

NgComponentOutlet: Declarative way to dynamic component creation

The update of createComponent function

Conclusion

The next improvement in Angular reactivity

Introduction

Process of resetting one signal relative to another

The LinkedSignal function to the rescue.

The new Resource Api

@let: New feature compiler in Angular 18.1

Introduction

The compiler's latest feature: @let

The different ways of using @let

Use the @let with signals

@let and javascript expression

Other cool things that @let brings

What'new in Angular 18

Introduction

New Control flow syntax is now stable

Defer syntax is now stable

What will happen to Zone js

Deprecation of HttpClientModule

ng-content fallback

Form Events: a way to group the event of the form

Routing: redirect as a function

Server Side Rendering: two new awesome feature

Replay events

Internationalization

Internationalization

A new builder package and deprecation

No more donwleveling async/await

An new alias: ng dev

Future

Be ready for input signals in Angular

Introduction

A litte reminder

Why passing a signal as an input is a very bad idea ?

Unidirectional binding and granularity of the detection change

Force the parent to use signals

Input as a setter for the win

Inputs Signal

What will happen in the future ?

What's new in Angular 17

Introduction

A new Branding

The @Component annotation

The new Application builder

The new Angular Code Flow

The most waited feature: defer

A little word about Signals

Angular Devtools

Conclusion

Angular: How to test functional guards, resolver and intercpetors

Introduction

Injector level

Test your functional guard, resolver, interceptors

Angular: Transform your inputs at will and simply

Introduction

Context

Getter and setter

Create your own property decorator

The `validate` function

The `error` function