DEV Community: Jarosław Żołnowski

What's New in Angular v19?

Jarosław Żołnowski — Mon, 30 Dec 2024 12:19:22 +0000

Angular v19 is here, and it’s packed with powerful features and enhancements to make building high-performance web apps even easier. With this release, developers can look forward to improvements that enhance developer experience, boost app performance, and simplify APIs to make development faster and more efficient. Let’s explore what Angular v19 brings to the table.

Keeping Things in Sync with `linkedSignal`

One of the standout features in Angular v19 is the introduction of linkedSignals. This new reactive primitive ensures multiple signals stay in sync, making it perfect for maintaining derived states that depend on other signals.

Here's a quick example: say you have a list of users and want to keep the selected user highlighted even when the list changes. With linkedSignal, you can write code that automatically adjusts the selection behind the scenes, keeping things clean and organized.

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

export class UserSelectionComponent {
  protected readonly availableUsers = signal<{ id: number; name: string }[]>([
    { id: 1, name: 'User1' },
    { id: 2, name: 'User2' },
    { id: 3, name: 'User3' },
  ]);

  protected selectedUserId = linkedSignal({
    source: this.availableUsers,
    computation: (users, previous) => {
      if (previous?.value && users.some(user => user.id === previous.value)) {
        return previous.value;
      }
      return null;
    },
  });
}

In this example, linkedSignal recalculates the selected user ID whenever the list of available users changes, reducing complexity in state management.

Streamlined Data Fetching with the `resource` API

Fetching data just got easier with the new resource API. It simplifies async data handling by combining loaders, request tracking, and reactivity. This means less code for you and cleaner components that focus on what matters.

Here’s how you can use resource to fetch and manage user profile data:

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

const userId = signal('user_1');

protected userDetails = resource({
  request: this.userId,
  loader: async ({ request: userId, abortSignal }) => {
    const response = await fetch(`https://api.example.com/users/${userId}`, { signal: abortSignal });
    return await response.json() as UserDetails;
  },
});

userDetails.value; // Access user details
userDetails.isLoading; // Check loading state
userDetails.error; // Handle errors

protected updateUser(name: string): void {
  this.userDetails.update((user) => (user ? { ...user, name } : undefined));
}

protected reloadProfile(): void {
  this.userDetails.reload();
}

Think of it like having a personal data assistant. You tell it what data you need, and it handles the whole process, letting you know when it's loading, if there are any errors, and of course, providing the data itself.

Faster Rendering with Incremental Hydration

Incremental Hydration is a game-changer for server-side rendered (SSR) applications. Instead of hydrating the entire app at once, Angular now hydrates UI sections only when needed, reducing the initial JavaScript payload and processing time.

To enable this, you just need to tweak your app's configuration a bit:

import { provideClientHydration, withIncrementalHydration, ApplicationConfig } from '@angular/platform-browser';

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(withIncrementalHydration()),
  ],
};

Now you can control exactly which parts get hydrated using hydration triggers with the @defer directive:

@defer (hydrate on hover) {
  <app-hydrated-content></app-hydrated-content>
}

In this case, the component will only load when hovered. This enables fine-grained hydration of components, ensuring better performance and resource usage.

Flexible Render Modes with `ServerRoute`

Ever wanted to choose how different parts of your app render? Angular v19 introduces ServerRoute interface, giving you the power to decide whether a route should be rendered on the server, pre-rendered in the background, or handled by the client.

For example, you might want your login page to be server-side rendered for security reasons, while your dashboard could be client-side rendered for a more interactive experience:

export const serverRouteConfig: ServerRoute[] = [
  { path: '/login', mode: RenderMode.Server },
  { path: '/dashboard', mode: RenderMode.Client },
  { path: '/**', mode: RenderMode.Prerender },
];

One cool thing about ServerRoute is that it lets you dynamically resolve route parameters during pre-rendering. This means you can use your Angular services to fetch data and customize the content before it's even sent to the browser.

import { ServerRoute } from '@angular/platform-server';
import { inject } from '@angular/core';

export const serverRoutes: ServerRoute = [
  {
    path: '/users/:id',
    mode: 'prerender',
    async getPrerenderPaths() {
      const userService = inject(UserService);
      const userIds = await userService.getUserIds();
      return userIds.map(id => ({ id }));
    },
  },
];

The getPrerenderPaths function executes in an injection context, allowing to use Angular services to fetch and resolve user id dynamically.

Instant Feedback with Enhanced HMR

Angular v19 takes Hot Module Replacement (HMR) to the next level. Before, if you tweaked some CSS or changed your template, the whole app would have to rebuild and refresh in the browser. It worked, sure, but this process often interrupted the developer’s flow and reset the application state, like if you were filling out a form and suddenly...everything's gone.. With the enhanced HMR in Angular v19, these interruptions are a thing of the past.

Now, those annoying interruptions are history! With the new and improved HMR in v19, when you change your component's styles or template and hit save, Angular is smart enough to just compile the parts you changed. It then sends those updates to the browser and patches the running app without a full page refresh. This means you see your changes instantly.

Imagine you're working on a product page and need to tweak the style of a button while maintaining the current application state. With HMR, we can change the button’s styles:

.button-primary {
  background-color: #007bff; // Updated color 
}

And...see changes instantly without a full page reload or losing form input, scroll position, or other dynamic states.

The best part? Hot module replacement for styles is enabled by default in v19, so you get it right out of the box.

Enhanced Security with Automatic Content Security Policy

Security is a big deal, and Angular v19 is making it easier to keep your apps safe with a new feature called AutoCSP. This is currently in developer preview, so it's still being refined, but it's a really cool step forward. AutoCSP automatically generates a hash-based Content Security Policy (CSP).

Basically, a CSP acts as a security layer, specifying which resources a browser is allowed to load and execute. Each script in your app gets a unique "fingerprint" (a unique hash). The browser will only run a script if its fingerprint is on the CSP's "approved" list. This is a super effective way to stop attackers from injecting malicious scripts because they can't create the correct fingerprint for their sneaky code.

To enable the AutoCSP feature, we need to update the angular.json configuration file:

{
  "projects": {
    "my-angular-app": {
      "architect": {
        "build": {
          "options": {
            "security": {
              "autoCSP": true
            }
          }
        }
      }
    }
  }
}

Once you've done this, Angular takes care of the rest. During the build process, it automatically generates the CSP with the correct fingerprints for all your inline scripts in index.html.

Standalone Components as the Default

Angular v19 makes a big push towards simpler components. Remember those NgModules? Well, in many cases, you won't need them anymore! Standalone components are now the default way to create components. And for those who want to fully embrace the standalone way, there's a strict mode you can enable in your tsconfig.json file:

{
  "angularCompilerOptions": {
    "strictStandalone": true
  }
}

This ensures everything in your app is using the modern standalone approach, leading to a cleaner and more consistent project structure and lets you take full advantage of the latest Angular features.

Improved Theming with Angular Material

With the release of Angular v19, the Angular Material and CDK teams have taken a significant step forward by improving the theming API. It's now way easier to create and customize themes, building on the already awesome Material 3 framework. The new API not only streamlines theming but also provides developers with tools to make component-specific customizations more efficient and expressive. Say goodbye to repetitive code and hello to streamlined theming:

Making Themes Easier with mat.theme

In the past, creating a custom theme in Material required defining themes for each component separately. It worked, but it was often a lot of repetitive code. Now, with v19, there's a new mat.theme mixin that lets you define your entire theme – colors, fonts, spacing – in one place.

In earlier versions of Angular Material, creating a custom theme required defining themes for individual components using separate mixins. This approach, while powerful, often led to repetitive and verbose code. Angular v19 introduces the mat.theme mixin, which allows developers to define custom themes using a single, unified declaration.

Here’s an example:

@use '@angular/material' as mat;

@include mat.theme(
  $color-palette,
  $typography-config,
  $density-config
);

This single line of code sets up your entire theme - the definition of color palettes, typography, and density. The resulting theme is applied globally, reducing boilerplate and making theme management easier.

More Ways to Customize Material 3

Angular Material v19 also gives you more flexibility with colors and fonts. You can now create multiple themes for different parts of your app and even switch between them on the fly:

@use '@angular/material' as mat;

$dark-theme: mat.define-theme((
  color: (
    primary: mat.$cyan-palette,
    secondary: mat.$amber-palette,
    theme-type: dark
  ),
  typography: mat.define-typography((font-family: 'Georgia, serif')),
  density: 1
));

body.dark-mode {
  @include mat.theme($dark-theme);
}

Component-Specific Overrides

One of the coolest additions (at least from my perspective) is the ability to make targeted customizations for individual components using the new overrides API. This allows developers to tweak specific design tokens for components without altering the global theme.

Let's say you want to change the background and divider color of a mat-sidenav component:

@include mat.sidenav-overrides((
  'content-background-color': lightblue,
  'container-divider-color': darkgray,
));

This lets you tweak specific components while still keeping a consistent overall look and feel.

Enhanced Drag & Drop with Mixed Orientation

Angular's CDK now supports drag-and-drop in two dimensions, making it even more powerful for building interactive user interfaces. This opens the door for creating things like Kanban boards, grid layouts, or even creative layout editors, without the need for third-party libraries.

Support for Tab Reordering

Angular v19 introduces support for tab reordering, enabling users to rearrange tabs dynamically. This feature enhances the user experience for applications with complex tab-based interfaces.

New Time Picker Component

Another addition is the brand new Time Picker Component, which simplifies time selection in forms and input fields. The component is highly customizable, integrates seamlessly with Angular forms, and supports various formats.

Wrapping It Up

Angular v19 is a big step forward, giving developers powerful tools to build apps faster and more secured. From reactive features to security improvements and simplified standalone defaults, Angular v19 is a release worth checking out. With support for advanced theming, dynamic prerendering, and productivity-enhancing tools like HMR, Angular continues to set the standard for front-end frameworks. So go ahead and start exploring the possibilities!

Say Goodbye to Long Relative Paths with tsconfig Aliases

Jarosław Żołnowski — Sun, 24 Nov 2024 10:48:28 +0000

Let’s be real - working with long relative paths can be a pain. Who hasn’t had to deal with something like this?

import { AuthService } from '../../../services/auth.service';

It’s messy, hard to read, and even harder to manage when your app grows. But here’s the good news: there’s a way to ditch those long paths and keep your code clean and readable. Enter tsconfig aliases! 🎉

What Are Aliases, and Why Should You Care?

With tsconfig aliases, you can replace those clunky relative paths with short, clean ones that look like below:

import { AuthService } from '@services/auth.service';

No more counting ../ or getting lost in nested directories. Aliases make your imports:

Readable: Short paths are easier to read and understand.
Maintainable: Move files around without breaking half your imports.
Scalable: As your project grows, your import statements stay clean.

Setting Up Aliases in Angular

Adding aliases is quick and easy.

Step 1: Update `tsconfig.json`

In your tsconfig.json, go to compilerOptions and set a baseUrl to point to your src directory. Then, add a paths section to define your aliases:

{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@users/*": ["app/users/*"],
      "@products/*": ["app/products/*"]
    }
  }
}

In this setup:

@auth/* maps to src/app/auth/*.
@users/* maps to src/app/users/*.
@products/* maps to src/app/products/*.

Step 2: Update Your Imports

Now, instead of this:

import { AuthService } from '../../../auth/auth.service';

You can use this:

import { AuthService } from '@services/auth.service';

Much cleaner, right?

Step 3: Refactor Existing Imports

I know setting up tsconfig aliases is a big win, but refactoring all those existing imports can feel like a huge chore. That’s exactly why I built replace-imports-cli! 🚀

Let a Tool Do the Heavy Lifting - `replace-imports-cli`

This little tool does the hard work for you. It scans your project, finds all those long relative import paths, and replaces them with the clean aliases you’ve defined in your tsconfig.json. No more manual fixes. No more guesswork!

Just run the tool, and it takes care of the rest. In seconds, your imports go from messy to clean and professional.

Want to give it a try? Head over to the GitHub repo for all the details:

👉 replace-imports-cli on GitHub

By combining tsconfig aliases with this CLI tool, you’ll never have to deal with messy relative paths again. Cleaner imports, faster refactoring, and more time to focus on what really matters! 😊

Bonus: Cleaner Lazy Loading

You can even use aliases for e.g. lazy loading Angular modules:

const routes: Routes = [  
  {  
    path: 'users',  
    loadChildren: () => import('@users/user.routes').then(r => r.userRoutes)
  }  
];

This makes your routes more readable and keeps things consistent.

Why This Matters

Switching to tsconfig aliases isn’t just about making your code look nicer (though that’s a big plus!). It also:

Saves time when refactoring - Moving files doesn’t mean endless fixes to import paths.
Makes onboarding new team members easier—they’ll instantly understand where imports are coming from.
Makes it easier to trace where entities are used, helping you identify and prevent potential circular dependency issues.
Helps your project scale without creating a tangled web of relative paths.

Works in Any TypeScript Project

Aliases aren’t limited to any framework - they work anywhere you’re using TypeScript. From React, Angular, Vue to Node, NestJS etc., you can enjoy clean, readable imports across all your projects.

Ready to Clean Things Up?

Take a few minutes to set up aliases in your Angular app, and you’ll never want to go back to those long relative paths. Trust me, your future self will thank you. 🙌

Level Up Your App's Speed with `NgOptimizedImage`

Jarosław Żołnowski — Sun, 10 Nov 2024 21:51:09 +0000

If you've worked on a web app, you know that images can be a big deal for both design and performance. While they make pages look great, they can also slow everything down. That’s where Angular’s NgOptimizedImage directive comes in. It’s a handy tool for optimizing images, so they load faster without losing quality. Let’s dive into how this directive can make your Angular app snappier and improve the user experience.

Why Optimize Images Anyway?

We all want our apps to look good, but images come with a cost—longer load times. Optimizing images can dramatically improve performance metrics, especially the Largest Contentful Paint (LCP), which measures how fast the largest piece of content appears on the screen. This is huge for user experience and SEO, and Angular’s NgOptimizedImage directive makes it easy to get it right without manual tweaks.

Key Features of `NgOptimizedImage`

1. Responsive Images with `srcSet` and `sizes`

The srcSet and sizes attributes allow the browser to load the right image size for each device, which is especially helpful for performance. The great thing about Angular’s NgOptimizedImage directive is that it generates the srcSet for you, so you don’t need to do it manually.

Example:

<img
  ngSrc="angular.jpg"
  width="200"
  height="200"
  sizes="80vw"
/>

Here, sizes="80vw" sets the image to 80% of the viewport width. Angular will handle the rest, creating a srcSet with various resolutions so that each device gets the best fit. This saves time and ensures a smooth load no matter the screen size.

2. Customizing Image Breakpoints

If you’re working with specific screen sizes, Angular lets you customize breakpoints by setting an IMAGE_CONFIG token. This way, you can pick just the breakpoints that match your app’s design.

Example:

providers: [{
  provide: IMAGE_CONFIG,
  useValue: {
    breakpoints: [384, 640, 750]
  }
}]

Now Angular will only generate images for 384px, 640px, and 750px, which keeps your file sizes smaller and your app faster.

3. Prioritizing Key Images with `priority`

Ever noticed how long it can take to load a big image like a banner? The priority attribute tells Angular which images are critical for loading first. If you set priority, Angular preloads the image, making sure it appears quickly, improving that all-important LCP.

Example:

<img
  ngSrc="hero.jpg"
  width="1200"
  height="600"
  priority
/>

For server-side rendered apps, Angular even adds a <link rel="preload"> tag for these images, so they start loading right away. This is perfect for hero images or banners that you want users to see immediately.

4. Fill Mode for Flexible Layouts

Need an image to fill a container, like a background? fill mode has you covered. It lets an image scale to fit the container without needing fixed dimensions, which is perfect for layouts with unknown widths or heights.

Example:

<img ngSrc="background.jpg" fill />

Just make sure your container has position: relative, absolute, or fixed, so the image fills it properly. This feature is great for responsive layouts where you want images to adapt smoothly.

5. Lazy Loading for Off-Screen Images

Angular makes lazy loading effortless with loading="lazy", which defers loading images until they’re about to be visible. This reduces the initial page load and is awesome for things like image galleries.

Example:

<img
  ngSrc="thumbnail.jpg"
  width="200"
  height="200"
  loading="lazy"
/>

Just be cautious with images that are crucial to the layout, like a logo. For these, skip lazy loading to ensure they load right away.

6. Placeholders for a Better Loading Experience

Nothing kills user experience like a blank loading image. With placeholder, you can show a temporary low-res version or even a Base64-encoded preview while the main image loads. This provides a smoother experience as users see a preview of the image right away.

Example:

<img
  ngSrc="profile.jpg"
  width="200"
  height="200"
  placeholder
/>

If you use a CDN, you can generate low-res placeholders automatically. Just keep them small (under 4 KB) to avoid slowing down the load. Angular will even throw an error if the placeholder size is too big, which is a good reminder to keep things light.

CDN Integration for Faster Image Delivery

By using a Content Delivery Network (CDN) with NgOptimizedImage, you get faster load times because images are served from servers closer to your users. CDNs cache content across the globe, meaning shorter load times and less data travel, which makes a huge difference, especially for users far from your primary server.

CDNs also often compress images, ensuring the best quality at the smallest size, which boosts performance even further. When combined with NgOptimizedImage, CDNs can help you build a fast, responsive app that works well for users everywhere.

A Practical Example

Now, let's look at a real-world example to see how the NgOptimizedImage directive can make a big difference in performance. Imagine we’re building a gaming site that displays game cover images.

Here’s the initial setup with the standard src attribute:

<img
  width="1250"
  height="600"
  src="https://via.assets.so/game.png?id=12"
  alt="Assassin's Creed Game Cover Art"
/>

<div style="display: flex; gap: 25px; margin-top: 25px;">
  <img
    *ngFor="let image of list; trackBy: $index"
    src="https://via.assets.so/game.png?id=16"
    width="400"
    height="200"
    alt="Thumbnails Movie Gallery"
/>
</div>

When we analyze the page in Lighthouse, the First Contentful Paint (FCP) comes in at 1.4 seconds, while the Largest Contentful Paint (LCP) lags behind at 13.5 seconds—not ideal.

By making a few tweaks with NgOptimizedImage, we can get those numbers way down:

<img
  width="1250"
  height="600"
  src="game.png?id=12"
  ngSrcset="400w, 800w, 1200w"
  sizes="(max-width: 600px) 960px, 100vw"
  alt="Witcher II Game Cover Art"
  priority
/>

<div style="display: flex; gap: 25px; margin-top: 25px;">
  <img
    *ngFor="let image of list; trackBy: $index"
    width="400"
    height="200"
    [ngSrc]="game.png?id=16"
    ngSrcset="100w, 200w, 400w"
    sizes="(max-width: 600px) 200px, 400px"
    alt="Thumbnails Movie Gallery"
    priority
  />
</div>

To go the extra mile, we add a preconnect link for our image server in the <head>:

<link rel="preconnect" href="https://via.assets.so/">

And in our app configuration, we set up a custom image loader for our CDN (e.g., Imgix):

const appConfig: ApplicationConfig = {
  providers: [provideImgixLoader('https://via.assets.so/')],
};

With these small adjustments, we see a huge performance boost—FCP drops to just 0.2 seconds, and LCP is down to a quick 0.7 seconds! This is a perfect example of how NgOptimizedImage can make a real difference in your app’s speed and user experience.

Wrapping Up

Angular’s NgOptimizedImage is a fantastic tool for improving image handling and app performance. Whether you’re working with responsive images, lazy loading, or CDN integration, this directive makes it easy to get things right. With these optimizations, you’ll have a faster, smoother app that keeps users happy. Give NgOptimizedImage a try and see the difference in your next project!

Exploring Angular's Change Detection: In-Depth Analysis

Jarosław Żołnowski — Sun, 07 Jul 2024 22:18:19 +0000

Understanding Change Detection

Change detection in Angular is a key process that keeps the app's state and user interface in sync. It's how Angular makes sure our UI updates when the underlying data changes. Without it, any changes in your app wouldn't show up in the UI automatically, making the app inconsistent and unreliable. Change detection is important because it keeps the UI accurate, ensuring every user action, data fetch, or event is shown correctly, making the app responsive and user-friendly.

How Change Detection Works in Angular

The change detection process in Angular involves two main stages:

Marking the Component as Dirty: This initial stage occurs when an event that can alter the state of a component happens. For instance, a user clicks a button, which triggers Angular to mark the affected component as dirty. This marking indicates that the component requires a check-up for potential changes.
Refreshing the View: This is where zone.js comes into play. zone.js is a library that helps Angular track asynchronous operations like XHR requests, DOM events, and timers (e.g., setInterval, setTimeout). When an asynchronous event occurs, Angular captures it through the onMicrotaskEmpty Observable:

this._onMicrotaskEmptySubscription = this.zone.onMicrotaskEmpty.subscribe({
  next: () => {
    if (this.changeDetectionScheduler.runningTick) {
      return;
    }
    this.zone.run(() => {
      this.applicationRef.tick();
    });
  },
});

And traverse the view tree to detect and propagate any changes:

for (let {_lView, notifyErrorHandler} of this._views) {
  detectChangesInViewIfRequired(
    _lView,
    notifyErrorHandler,
    isFirstPass,
    this.zonelessEnabled,
  );
}

In Angular, a view refers to an instance of ViewRef. Think of ViewRef as a box that contains a bunch of important information about the component, such as the current state of inputs, the template, directives being used, and binding statuses. Each component has its own ViewRef box, making it easier for Angular to manage and update components during change detection.

The detectChangesInViewIfRequired method triggers the detectChangesInView, which defines the criteria for checking components, inspecting various flags associated with the view and its mode, to determine if any updates are necessary.

If the view needs refreshing, the refreshView method is called. This method executes the template function (which is a component template compiled into a regular JavaScript function) with the render flags and context to generate the component view and starts a chain reaction by triggering event detection for the view's child components through the detectChangesInChildComponents method.

So to perform change detection, Angular traverses the views' tree and executes template functions on each component.

Default Change Detection

In the beginning, most of us used Default change detection - it's like being in the middle of a bustling city – there's noise everywhere, distractions pulling your attention in every direction. This is how it was with Angular's default change detection. It keeps an eye on everything, even when nothing's happening. And sure, it works, but it's a bit overkill, causing performance hiccups, especially as your app grows.

This strategy is the default change detection mechanism, and it’s applied automatically unless we explicitly override it with an OnPush strategy. It relies on the CheckAlways flag which means that Angular will run change detection for all components whenever any event occurs.

let shouldRefreshView: boolean = !!(
  mode === ChangeDetectionMode.Global && flags & LViewFlags.CheckAlways
);

So if this flag is set, then it calls the mentioned refreshView method (shouldRefreshView flag is set to true),

if (shouldRefreshView) {
  refreshView(tView, lView, tView.template, lView[CONTEXT]);
}

which refreshes not just the current view but also all its child views, if there are any. This ensures everything stays consistent, but it can be inefficient for larger apps because it might do more checks than needed.

So, it's kind of like a domino effect, making sure the entire component tree gets updated, whatever happens.

We have the ability to control this one way or another. We can explicitly detach and reattach the view from the change detection tree using detach() and reattach() methods respectively.

@Component({
 selector: 'detached', template: `Detached Component`
})
export class DetachedComponent {
 constructor(private cdr: ChangeDetectorRef) {
   cdr.detach();
 }
}

If we detach the view from the change detection, Angular will skip it, regardles of any changes chappend.

OnPush Change Detection Strategy

For better performance, Angular offers the OnPush change detection strategy. This strategy tells Angular to skip change detection for the component unless one of its inputs changes, we mark component to check using markForCheck method or an event occurs, for example a XHR request handled by an async pipe.

By focusing on what's changed, rather than checking everything all the time, OnPush makes apps faster and more efficient, reduces unnecessary updates, improves performance, and prevents potential disasters.

Using OnPush helps optimize performance by reducing the number of times change detection runs, especially in large and complex applications.

So, how does it work? I mentioned that OnPush change detection gets triggered when we do things like setting a new Input value in a child component.

Now, let's get back to the Angular source code, and verify the part that runs when we set a new Input value.

So, when the setInput method is called, it confirms that the Input value actually has been changed,

if (
  this.previousInputValues.has(name) &&
  Object.is(this.previousInputValues.get(name), value)
) {
  return;
}

marking the component view as Dirty in the markViewDirty method, which basically tells Angular,

"Hey, this child component's view needs updating, so take a look next time you check for changes."

The same idea applies when, for example, we are using an Async pipe.

It subscribes to observables, which updates the latest value by calling the markForCheck function,

private _updateLatestValue(async: any, value: Object): void {
  if (async === this._obj) {
    this._latestValue = value;
    if (this.markForCheckOnValueUpdate) {
      this._ref?.markForCheck();
    }
  }
}

which, in turn, triggers the markViewDirty method.

markForCheck is also used in a few other scenarios. For example if we want to initiate the change detection manually, we handle the DOM event, or attaching, detaching a view. And in all these scenarios at some point we call the markViewDirty method.

while (lView) {
  lView[FLAGS] |= dirtyBitsToUse;
  const parent = getLViewParent(lView);

  if (isRootView(lView) && !parent) {
    return lView;
  }

  lView = parent!;
}

This method is like a domino effect – it starts with the specified view and moves up the family tree, by checking if there’s a parent,

if (isRootView(lView) && !parent)

marking each view along the path as Dirty, meaning they all need checking.

const dirtyBitsToUse = isRefreshingViews() ? LViewFlags.Dirty : LViewFlags.RefreshView | LViewFlags.Dirty;

while (lView) {
 lView[FLAGS] |= dirtyBitsToUse;
 …
}

And when it's time to do the actual checking, Angular looks at those views marked as dirty.

shouldRefreshView ||= !!(
  flags & LViewFlags.Dirty &&
  mode === ChangeDetectionMode.Global &&
  !isInCheckNoChangesPass
);

If a component's view is marked as Dirty, it means something in that component has changed, and it needs to be re-rendered. And we do that by calling the refreshView method.

When we click on the component, it triggers a change detection in the component itself and all its parent components, which is exactly what we should expect, because we marked all its ancestors as Dirty in the markViewDirty method.

Signals Era

Since version 16, Angular has been introducing Signals - a wrapper around a value that can notify interested consumers when that value changes. It can contain any value, from simple primitives to complex data structures, and we can read the value through a getter function, which allows Angular to track where the signal is used.

Now, the cool part is, Angular allows us to utilize this Signal power and combine it with the OnPush strategy to mark certain components for updates.

This little trick eliminates the need for unnecessary checks on components, whether they're parent or child elements.

Let's see what makes the signals work the way they do. Whenever we tweak a signal within a component's template, using methods like set() or update(), it's like setting off a little chain reaction.

First, Angular calls signalSetFn, which will send out a notification to the live consumer waiting in the view,

function signalValueChanged<T>(node: SignalNode<T>): void {
  …
  producerNotifyConsumers(node);
  …
}

making it go, "Hey, I'm dirty!"

for (const consumer of node.liveConsumerNode) {
  if (!consumer.dirty) {
    consumerMarkDirty(consumer);
  }
}

Then, it marks all its ancestors, right up to the root, with a flag called HasChildViewsToRefresh, indicating

"Hey, I've got some child views here that need to be refreshed."

while (parent !== null) {
  if (parent[FLAGS] & LViewFlags.HasChildViewsToRefresh) {
    break;
  }

  parent[FLAGS] |= LViewFlags.HasChildViewsToRefresh;
  if (!viewAttachedToChangeDetector(parent)) {
    break;
  }
  parent = getLViewParent(parent);
}

If we take a look closer, we'll see that this method is pretty similar to the markViewDirty method. The difference is, instead of marking all parent views with the Dirty flag, we mark them with the HasChildViewToRefresh flag.

Now, as you already know, the change detection mechanism consists of two parts and the subsequent part traverses the tree of views. So let's back into our detectChangesInView method that evaluates whether a view requires updating.

Now, here's the clever part - when a view is marked with this HasChildViewsToRefresh flag, there's no need to re-render it. Angular skips right ahead to checking out the child component view if there's any.

else if (flags & LViewFlags.HasChildViewsToRefresh) {
  detectChangesInEmbeddedViews(lView, ChangeDetectionMode.Targeted);
  const components = tView.components;
  if (components !== null) {
    detectChangesInChildComponents(lView, components, ChangeDetectionMode.Targeted);
  }
}

This smart shortcut helps Angular avoid wasting time on unnecessary stuff, ensuring smooth and efficient operation!

When we use e.g. the setInterval function to update the signal value in Component D, only the components directly touched by the signal change actually get refreshed.

OnPush within Signals is like a sniper shot for detecting changes. It allows us to specify which components should be re-rendered when certain signals change. This means that instead of refreshing the entire component tree or a single branch when using OnPush, we only re-render the components directly affected by the signal change.

Wrap up

Default change detection relies on the CheckAlways flag, triggering updates for the entire view tree, whatever happens. This keeps everything consistent but can be overkill, causing unnecessary performance hits as the app grows.

OnPush change detection is a powerful optimization technique in Angular. It ensures that components are only re-rendered when their inputs change, when events occur within the component or when we manually trigger change detection using the markForCheck method. It's important to note that when we use OnPush, the change detection refreshes not only the component itself but also all its parent components in the component tree.

OnPush within Signals is a more targeted approach to change detection. It allows us to specify which components should be re-rendered when certain signals change. This means that instead of refreshing the entire component tree or a single branch when using OnPush, we only re-render the components directly affected by the signal change.

DEV Community: Jarosław Żołnowski

What's New in Angular v19?

Keeping Things in Sync with linkedSignal

Streamlined Data Fetching with the resource API

Faster Rendering with Incremental Hydration

Flexible Render Modes with ServerRoute

Instant Feedback with Enhanced HMR

Enhanced Security with Automatic Content Security Policy

Standalone Components as the Default

Improved Theming with Angular Material

Making Themes Easier with mat.theme

More Ways to Customize Material 3

Component-Specific Overrides

Enhanced Drag & Drop with Mixed Orientation

Support for Tab Reordering

New Time Picker Component

Wrapping It Up

Say Goodbye to Long Relative Paths with tsconfig Aliases

What Are Aliases, and Why Should You Care?

Setting Up Aliases in Angular

Step 1: Update tsconfig.json

Step 2: Update Your Imports

Step 3: Refactor Existing Imports

Let a Tool Do the Heavy Lifting - replace-imports-cli

Bonus: Cleaner Lazy Loading

Why This Matters

Works in Any TypeScript Project

Ready to Clean Things Up?

Level Up Your App's Speed with `NgOptimizedImage`

Why Optimize Images Anyway?

Key Features of NgOptimizedImage

1. Responsive Images with srcSet and sizes

2. Customizing Image Breakpoints

3. Prioritizing Key Images with priority

4. Fill Mode for Flexible Layouts

5. Lazy Loading for Off-Screen Images

6. Placeholders for a Better Loading Experience

CDN Integration for Faster Image Delivery

A Practical Example

Wrapping Up

Exploring Angular's Change Detection: In-Depth Analysis

Understanding Change Detection

How Change Detection Works in Angular

Default Change Detection

OnPush Change Detection Strategy

Signals Era

Wrap up

Keeping Things in Sync with `linkedSignal`

Streamlined Data Fetching with the `resource` API

Flexible Render Modes with `ServerRoute`

Step 1: Update `tsconfig.json`

Let a Tool Do the Heavy Lifting - `replace-imports-cli`

Key Features of `NgOptimizedImage`

1. Responsive Images with `srcSet` and `sizes`

3. Prioritizing Key Images with `priority`