Telerik Blogs | Web | Angular

Moving to Angular Zoneless

2026-10-21T19:54:21Z

Instead of change detection after every asynchronous task, Zoneless Angular applications use Signals to detect relevant state changes. Here’s how to set that up greenfield and what to watch for as you migrate to Zoneless.

If you have worked with Angular, you have probably seen components react and update the UI after a click, timer or HTTP request without calling detectChanges(). Angular has provided this convenience for years, so you usually do not need to think about what makes it work.

ZoneJS and Angular’s NgZone make this possible, and we can make reactive apps easy, but NgZone makes Angular check more than necessary. As your app grows, you may start asking a simple question: can Angular update only the views that really changed?

Modern Angular gives you that option with Zoneless change detection. Signals and other Angular APIs can tell Angular when a view needs an update. This lets you build applications without depending on NgZone to watch every asynchronous task.

Today, let’s build together a small product dashboard with Angular 22 and Progress Kendo UI for Angular. First, we will learn how the old model works. Then we will use Signals and httpResource to build a Zoneless dashboard. Finally, we will review common problems that can appear during a Zoneless migration.

Let’s start with what made the old model work: NgZone and ZoneJS.

What Are NgZone and ZoneJS?

When we talk about NgZone, it’s a service that connects Angular to the ZoneJS library. ZoneJS patches many browser APIs, including timers, events and promises. When one of these operations finishes, Angular can use that notification to schedule change detection.

Think of ZoneJS as a central alarm. It does not know which component changed. As a result, Angular may check a large part of the component tree after the alarm rings. This is easy to use because developers do not always need to tell Angular that state changed.

For example, this code changes a normal property from a timer:

export class NotificationComponent {
  badgeCount = 0;

  ngOnInit(): void {
    setInterval(() => {
      this.badgeCount++;
    }, 3000);
  }
}

With ZoneJS, the timer can trigger Angular change detection, and the badge updated property can appear in the template even though the component did not explicitly notify Angular. That convenience has a cost, especially in larger applications:

Angular can perform checks that do not produce a visible change.
ZoneJS injects runtime code into the application.
Stack traces can include framework scheduling details that make debugging painful.

The performance cost depends on the application. Zoneless does not promise that every application will become faster. It makes change detection more explicit and can reduce unnecessary work when the application exposes its state clearly.

We have seen why Angular used NgZone and what ZoneJS added. Now, let’s look at how Angular knows that a Zoneless view needs an update.

How Does Zoneless Change Detection Work?

Zoneless Angular does not need NgZone to watch browser tasks. Instead, Angular schedules change detection when one of its APIs sends a notification. Examples include a signal read by a template, a bound event listener, a component input and ChangeDetectorRef.markForCheck(). Signals are the most common option. They store state and tell Angular which views use it.

The difference is simple. ZoneJS can trigger a broad check after a timer, event or promise, but Zoneless Angular reacts to an Angular notification and updates the views connected to that state. Not every value must become a signal(). However, values used by a template must change through a mechanism that Angular can observe.

That is the idea we will use in the dashboard: a user event changes a signal, the resource loads new data and the template updates.

Build a Zoneless Product Dashboard

Let’s build a small product dashboard with a category filter and a Kendo UI for Angular Grid. Keeping the example small makes it easier to follow the change detection path.

Step 1: Create the Angular Project

Create the project with Angular CLI. Run this command in a terminal:

npx @angular/cli@22 new zoneless-kendo-dashboard --standalone --style=scss --ssr=false
cd zoneless-kendo-dashboard

The first command creates an Angular 22 project. It includes standalone components and SCSS, and it disables server-side rendering. The second command moves into the project folder. You should now have files such as src/app/app.ts, src/app/app.html, andsrc/app/app.scss`.

Start the new application to check that the project works before continuing:

ng serve

Open http://localhost:4200 in your browser. You should see the default Angular application. Stop the server with Ctrl+C before continuing.

New Angular projects use the defaults for that Angular version. Before using the next step in an existing project, check its Angular version and the generated app.config.ts.

Next, check the change detection configuration Angular generated.

Zoneless in Angular 22

In this example, you are using Angular 22, which uses zoneless change detection by default. The generated app.config.ts does not need a provideZonelessChangeDetection() call. The project also does not include zone.js as a dependency.

import { ApplicationConfig, provideBrowserGlobalErrorListeners } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';

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

We add provideHttpClient() because this dashboard will use httpResource to call the Fake Store API. provideHttpClient() is an HTTP provider, not a Zoneless provider, but if your application does not make HTTP requests, you can leave it out.

What About Older Angular Versions?

This section is only for older versions like Angular 20, because not every project uses the latest Angular version. Angular 20 and later support opting into Zoneless with provideZonelessChangeDetection(). New projects created with Angular 21 and later use Zoneless by default, but existing applications still need a migration review.

For an Angular 20 application that still uses ZoneJS, add the provider in app.config.ts, then review the project configuration. If you use an older Angular version, check its version-specific migration guide because the provider and setup can be different:

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

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

After checking the application, tests and third-party libraries, remove zone.js and zone.js/testing from angular.json or the polyfills configuration. Only then remove the package:

npm uninstall zone.js

Now you know how to set up Zoneless for the old version; now let’s continue with our project in Angular 22 and add Kendo UI!

Step 2: Install Kendo UI Components

Now that the Angular project is ready, add the UI components that users will use. Kendo UI will provide the category selector and product grid, so install the packages from the project folder:

npm install @progress/kendo-angular-grid @progress/kendo-angular-dropdowns
npm install @progress/kendo-theme-default @angular/animations @angular/localize

Check Kendo UI for Angular compatibility documentation when choosing package versions. Kendo UI components require Angular’s animation and localization runtimes, so install @angular/animations and @angular/localize as part of the setup.

Because Kendo UI uses Angular localization internally, add the localize runtime as a build polyfill in angular.json:

{
  "polyfills": [
    "@angular/localize/init"
  ]
}

Then load the Kendo UI theme in src/styles.scss:

@import '@progress/kendo-theme-default/dist/all.css';

Kendo UI gives you ready-to-use components such as the Angular DropDownList and Grid. Before you use all their features, review the Angular bundle budget. The application can compile successfully even when its bundle exceeds the default budget, so update angular.json after measuring the result:

{
  "type": "initial",
  "maximumWarning": "5MB",
  "maximumError": "6MB"
}

This change gives the Kendo UI Grid and DropDownList enough space within the bundle budget. Do not increase the budget in production without first measuring the bundle. Review imports, themes and lazy loading as the application grows. In this project, the generated bundle is about 4.4 MB, so the default 500kB warning and 1MB error limits are too low for these components.

The project is ready for the dashboard UI. Next, connect the product request to a signal so a category change can load new data.

Step 3: Fetch Products with httpResource

The UI dependencies are in place, but the grid still needs data. Use httpResource to connect the HTTP request to Angular’s reactive APIs. If the signal read by the request function changes, the resource starts a new request and exposes loading, error and value state.

Create src/app/product.service.ts. Run this command from the project folder to generate the file:

ng generate service product

Replace the generated service with this code:

import { httpResource } from '@angular/common/http';
import { Service, signal } from '@angular/core';

export interface Product {
  id: number;
  title: string;
  price: number;
  category: string;
  description: string;
}

@Service()
export class ProductService {
  readonly selectedCategory = signal('all');

  readonly productsResource = httpResource<Product[]>(() => {
    const category = this.selectedCategory();

    return category === 'all'
      ? 'https://fakestoreapi.com/products'
      : `https://fakestoreapi.com/products/category/${encodeURIComponent(category)}`;
  });
}

The service does not inject HttpClient because httpResource handles the request. The signal is read inside the resource function, so changing the selected category changes the resource URL. This example uses @Service() because it is a root-level service that uses inject().

The service now owns the reactive product request. That gives the component one clear source for its server state.

Step 4: Connect Kendo UI Components with Signals

The service is ready. Now we connect the Kendo UI DropDownList (category filter) and Grid (product list) to the signals from ProductService. The template reads signals directly—[value]="selectedCategory()" and [data]="products()"—so when a signal changes, Kendo UI updates without NgZone.

The Kendo UI Grid gives you virtual scrolling, sorting, filtering and column resizing out of the box, all reactive to signal changes. The DropDownList handles keyboard navigation, filtering and accessibility without extra code.

Think of it like a direct wire: the signal is the switch, the Kendo UI component is the light. When you flip the switch, the light turns on. No central alarm (ZoneJS) needed.

The current Angular CLI creates src/app/app.ts, src/app/app.html, and src/app/app.scss. Update these files separately. This matches the structure the CLI generates and shows where each part of the component belongs.

import {
  Component,
  computed,
  effect,
  inject,
} from '@angular/core';
import { DropDownListModule } from '@progress/kendo-angular-dropdowns';
import { GridModule } from '@progress/kendo-angular-grid';
import { ProductService } from './product.service';

@Component({
  selector: 'app-root',
  imports: [DropDownListModule, GridModule],
  templateUrl: './app.html',
  styleUrl: './app.scss',
})
export class App {
  private readonly productService = inject(ProductService);

  readonly categories = [
    'all',
    'electronics',
    'jewelery',
    "men's clothing",
    "women's clothing",
  ];

  readonly selectedCategory = this.productService.selectedCategory;
  readonly productsResource = this.productService.productsResource;
  readonly products = computed(() => this.productsResource.value() ?? []);

  constructor() {
    effect(() => {
      document.title = `Products - ${this.selectedCategory()}`;
    });
  }

  onCategoryChange(category: string): void {
    this.productService.selectedCategory.set(category);
  }
}

Now replace the content of src/app/app.html with the dashboard template:

<main class="container">
  <header>
    <h1>Angular Zoneless Product Dashboardh1>
    <p>Signals, httpResource, and Kendo UI working together.p>
  header>

  <section class="controls" aria-labelledby="filter-title">
    <h2 id="filter-title">Filter productsh2>
    <kendo-dropdownlist
      aria-label="Filter by category"
      [data]="categories"
      [value]="selectedCategory()"
      (valueChange)="onCategoryChange($event)"
    >kendo-dropdownlist>
  section>

  <p class="category-summary">
    Available categories:
    @for (category of categories; track category) {
      <span>{{ category }}span>
    }
  p>

  @if (productsResource.isLoading()) {
    <p class="status">Loading products...p>
  } @else if (productsResource.error()) {
    <p class="status error" role="alert">
      The products could not be loaded. Try again later.
    p>
  } @else {
    <kendo-grid [data]="products()" [height]="400">
      <kendo-grid-column field="id" title="ID" [width]="70" />
      <kendo-grid-column field="title" title="Product" />
      <kendo-grid-column field="category" title="Category" [width]="160" />
      <kendo-grid-column field="price" title="Price" format="{0:c}" [width]="120" />
    kendo-grid>
}
}

Let’s take a look at the HTML code. The DropDownList reads selectedCategory() with [value]. The Grid reads products() with [data]. And the (valueChange) event writes back to the signal. That is the whole loop. Read the signal, update UI, write signal, done!

The effect() syncs the category to the browser title. A side effect outside the template, but still driven by a signal.

Next, replace the content of src/app/app.scss with the dashboard styles:

.container {
  max-width: 900px;
  margin: 2rem auto;
  padding: 0 1rem;
  font-family: system-ui, sans-serif;
}

header {
  border-bottom: 2px solid #d9e2ec;
  margin-bottom: 2rem;
  padding-bottom: 1rem;
}

.controls {
  align-items: center;
  display: flex;
  gap: 1rem;
  margin-bottom: 1rem;
}

.category-summary span {
  margin-right: 0.75rem;
}

.status {
  padding: 2rem;
  text-align: center;
}

.error {
  color: #a61b1b;
}

The @if block reacts to resource state, while @for renders the category summary. The key point is that the template reads Signals. When selectedCategory changes, the resource and the affected view receive Angular notifications without relying on NgZone.

Run the application by running the following command:

ng serve

Open http://localhost:4200. You should first see the loading message, followed by the product grid. Select all in the dropdown and confirm that the loading message appears again before the filtered products are displayed.

Done!! Our flow is working from the signal to the resource and then to the template. But my next question is: how do we test this flow without leaving an HTTP request pending?

Test Zoneless Components

In a Zoneless test, you need to wait for Angular’s scheduled work and control asynchronous dependencies. A pending HTTP request is not stable work, so flush it through HttpTestingController. This lets you test the same signal-to-view path without depending on the real API.

Here is a focused Vitest test for the initial product request in src/app/app.spec.ts. The test uses provideHttpClientTesting() to control the request.

The Zoneless provider is included in TestBed to make the setup explicit, even though Angular 22 enables it by default in a new application:

The following snippet copy and replace the app.spec.ts file:

import { provideHttpClient } from '@angular/common/http';
import {
  HttpTestingController,
  provideHttpClientTesting,
} from '@angular/common/http/testing';
import { provideZonelessChangeDetection } from '@angular/core';
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { provideAnimationsAsync } from '@angular/platform-browser/animations/async';
import { App } from './app';

describe('App in a zoneless application', () => {
  let fixture: ComponentFixture<App>;
  let httpTesting: HttpTestingController;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [App],
      providers: [
        provideZonelessChangeDetection(),
                provideAnimationsAsync(),
        provideHttpClient(),
        provideHttpClientTesting(),
      ],
    }).compileComponents();

    fixture = TestBed.createComponent(App);
    httpTesting = TestBed.inject(HttpTestingController);
    fixture.detectChanges();
  });

  afterEach(() => {
    httpTesting.verify();
  });

  it('renders products after the HTTP request settles', async () => {
    const request = httpTesting.expectOne(
      'https://fakestoreapi.com/products',
    );

    request.flush([
      {
        id: 1,
        title: 'Test product',
        price: 10,
        category: 'electronics',
        description: 'A product for the test',
      },
    ]);

    await fixture.whenStable();

    expect(fixture.nativeElement.textContent).toContain('Test product');
  });

  it('loads products when the category changes', async () => {
    const initialRequest = httpTesting.expectOne(
      'https://fakestoreapi.com/products',
    );
    initialRequest.flush([]);
    await fixture.whenStable();

    fixture.componentInstance.onCategoryChange("men's clothing");
    fixture.detectChanges();

    const request = httpTesting.expectOne(
      "https://fakestoreapi.com/products/category/men's%20clothing",
    );

    request.flush([
      {
        id: 2,
        title: 'Test clothing product',
        price: 20,
        category: "men's clothing",
        description: 'A clothing product for the test',
      },
    ]);

    await fixture.whenStable();

    expect(fixture.nativeElement.textContent).toContain('Test clothing product');
  });
});

What does this code do? Well,
fixture.detectChanges() starts the initial render and request. flush() completes the controlled request. And whenStable() waits for Angular to finish the resulting render work. In other words, call whenStable() after you resolve the HTTP request instead of leaving it pending.

To run our test, use npm run test:

Yeah!! Our test now covers the initial request and a category change. So we have our app with Zoneless and testing, but this was a greenfield. Let me share with you the common migration problems I have encountered most often.

Common Migration Issues

Before we finish, let me share some of the most common problems I have found while migrating real Angular applications to Zoneless. This is not a complete list of every possible problem. These are the cases I’ve seen in real projects, and they are a good place to start when you review your own application.

These examples cover different migration boundaries. The practical fix depends on where the state enters the application.

A Timer Changes State But the UI Does Not Update

A normal property changed by setInterval() does not notify Angular in a Zoneless application. Use a signal for state read by the template, and clean up the timer when the component is destroyed:

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

@Component({
  selector: 'app-notification',
  template: '{{ badgeCount() }}',
})
export class NotificationComponent {
  readonly badgeCount = signal(0);
  private readonly destroyRef = inject(DestroyRef);

  constructor() {
    const timer = setInterval(() => {
      this.badgeCount.update((count) => count + 1);
    }, 3000);

    this.destroyRef.onDestroy(() => clearInterval(timer));
  }
}

For RxJS streams, use takeUntilDestroyed() when a manual subscription must be tied to the component lifecycle.

The timer example is the simplest case: template state needs an Angular notification.

A Manual RxJS Subscription Leaves a Stale View

An Observable emission does not automatically make a normal component property reactive. Prefer toSignal() when the value belongs in a template:

import { Component, Service, inject } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';
import { interval, map } from 'rxjs';

@Service()
export class WeatherService {
  readonly temperature$ = interval(5000).pipe(map(() => 72));
}

@Component({
  selector: 'app-weather',
  template: '{{ temperature() }} F
',
})
export class WeatherComponent {
  private readonly weatherService = inject(WeatherService);

  readonly temperature = toSignal(this.weatherService.temperature$, {
    initialValue: 72,
  });
}

toSignal() subscribes to the Observable, exposes the latest value as a signal, and connects the value to the component lifecycle. If you need a manual subscription to perform an action in code, use takeUntilDestroyed() and update a signal inside the callback.

This keeps the stream connected to the template without calling manual change detection. It is a useful pattern when an existing application already uses RxJS.

Maps, charts, editors and older wrappers may emit callbacks outside Angular’s reactive model. First, check whether the package has a current Angular integration. If it does not, isolate the integration and update a signal at the boundary:

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

@Component({
  selector: 'app-map',
  template: 'Selected location: {{ selectedLocation() }}
',
})
export class MapComponent {
  readonly selectedLocation = signal('');

  onMapSelectionChanged(selection: string): void {
    this.selectedLocation.set(selection);
  }
}

Because the template reads selectedLocation(), updating the signal already notifies Angular in a Zoneless application. If an external callback updates ordinary component state instead, use markForCheck() at that boundary. I use detectChanges() only for a narrow integration boundary, because it runs change detection immediately and should not become the default solution throughout the application.

These are the boundaries I have encountered most often. They are not the only cases, but they are a useful starting point for a Zoneless migration.

A Practical Migration Path

When moving an existing application from ZoneJS to Zoneless, first check the Angular version and read the migration guide for that version. This shows whether the application needs provideZonelessChangeDetection() explicitly. Before removing anything, search the project for NgZone, zone.js, zone.js/testing and code that depends on onStable or onMicrotaskEmpty.

Next, follow the state that each feature exposes to its template. Please pay special attention to values changed by timers, external callbacks and manual subscriptions. If a normal property is doing that work, move it to signal(), computed(), toSignal() or another Angular notification mechanism. Also check third-party libraries such as maps, charts, dialogs, date pickers and editors, because their callbacks may need an explicit integration boundary.

Keep the migration small enough to test as you go. Once the application and its dependencies no longer rely on ZoneJS, remove it from the project configuration and uninstall the package. Finally, measure the result with the browser performance tools. Do not assume that Zoneless alone will improve every metric.

Recap

The main idea is this: Zoneless applications do not depend on NgZone and ZoneJS to schedule change detection after every asynchronous task. Instead, the application exposes template state through Signals and other Angular APIs that can tell Angular when relevant state changes.

In my experience, an incremental migration is the most practical approach. Move one feature, test it, inspect its integrations and then continue to the next feature. This makes the application’s real change detection dependencies easier to see without turning the whole migration into one large debugging session.

Now it is your turn to try the same model with a small piece of client-side state.

Open Challenge

Add a search input to the dashboard. Keep the query in a signal(), and use computed() to show the matching products. Leave the category request as it is, so the resource manages server state while Signals manage local UI state.

Happy coding!

Feel free to read extra docs to have a full overview. :)

And remember, Kendo UI for Angular, one of the best Angular libraries comes with a free 30-day trial. So go on:

Try Now

Using Kendo UI with Svelte

2026-10-12T16:13:00Z

Even though there isn’t a native Svelte Kendo UI library, you can still use one of the Kendo UI component libraries with Svelte.

Progress Kendo UI does not have a Svelte version by default. It specializes in Angular, Vue, React and jQuery. However, that does not mean you Svelte fans out there are out of luck! JavaScript is just JavaScript, and there are work arounds to meet different needs.

TL;DR

You can use Kendo UI for jQuery in any JavaScript framework, or you can use Astro to mix components from multiple frameworks (React, Vue, Angular). The jQuery version is not perfect for server-side rendering, but it can work in pure Svelte, while Astro can work wonders with any framework component.

✔️ Svelte with Kendo UI for jQuery

Svelte allows you to import any JS you want. It is just JavaScript.

Create a New SvelteKit Project

npx sv create my-app

Install Tailwind and any other SvelteKit options you need.

Install Packages

npm i @progress/kendo-theme-meridian @progress/kendo-ui @progress/kendo-data-query @progress/kendo-date-math @progress/kendo-licensing @progress/kendo-popup-common jquery

with types:

npm install -D @types/jquery @types/node

Activate Kendo UI

npx kendo-ui-license activate

Get your key ready and follow any other activation instructions.

Create a jQuery Declaration File

Put it in lib/types/kendo-ui-module.d.ts or wherever makes sense.

/// 

declare module '@progress/kendo-ui' {
export {};
}

declare module '@progress/kendo-ui/kendo.all.js' {
export {};
}

declare global {
interface Window {
jQuery: JQueryStatic;
$: JQueryStatic;
}
}

export {};

jQuery types do not work as expected on the client without it.

Dynamically Import jQuery on the Browser

export async function loadKendoUi() {
// @ts-expect-error Kendo UI exposes this runtime entry but ships global-only typings.
await import('@progress/kendo-ui/kendo.all.js');
}

This allows you to load Kendo UI dynamically. Kendo UI for jQuery cannot run on the server, as it needs window objects, etc.

Handle CSS

@import 'tailwindcss';
@import '@progress/kendo-theme-meridian/dist/meridian-main.css';

Make sure your global layout.css or app.css file contains tailwind and the correct Progress theme CSS.

Load a Grid Element





{#if isGridLoading}

{:else}

{/if}

We load Kendo UI in onMount so that it won’t have problems loading on the server.
We use a $state signal to show a loading skeleton.
jQuery and kendoGrid are dynamically loaded, and then the products are added to the grid.

Create a Loader

Since the component takes a second to load, we want to show a loading skeleton in the interim. Notice we use kendo style classes to match our grid.


















ProductName






Unit Price






Units In Stock






Discontinued












{#each skeletonRows as row (row)}

{/each}










Loading product




0.00




000




False

We could equally have used a spinner.

✔️ Kendo UI in Astro

Using Astro is by far the best approach. You are not building in Svelte, but you can use any other framework with Astro, and have everything else built with Svelte.

Install Astro

Create a new Astro project.

npm create astro@latest

Don’t forget to add Tailwind.

Choose Your Kendo UI Framework

Install the Svelte Astro Plugin:

Svelte

Install the proper Astro plugin:

React
Vue
Angular (unofficial)

For this demo, I chose Vue and I copied all the Kendo UI for Vue grid components in Astro.

Install Dependencies

npm i @progress/kendo-data-query @progress/kendo-drawing @progress/kendo-licensing @progress/kendo-svg-icons @progress/kendo-theme-default @progress/kendo-vue-animation @progress/kendo-vue-buttons @progress/kendo-vue-charts @progress/kendo-vue-data-tools @progress/kendo-vue-dateinputs @progress/kendo-vue-dropdowns @progress/kendo-vue-grid @progress/kendo-vue-excel-export @progress/kendo-vue-inputs @progress/kendo-vue-intl @progress/kendo-vue-pdf @progress/kendo-vue-popup @progress/kendo-vue-treeview

Configure CSS

@import "tailwindcss";
@import '@progress/kendo-theme-default/dist/all.css';

Put in styles/global.css.

Activate Your Kendo UI License

npx kendo-ui-license activate

You can also use more than one or all of them with Astro! (Progress offers a DevCraft bundle, if you code in more than one framework.)

Create Svelte Component

We want to mix our components, so we create a Svelte Component that can accept any other component as a child.

<script lang="ts">
  let { children } = $props();

  let count = $state(0);
</script>

<section
  class="mx-auto mt-5 w-full max-w-4xl rounded-3xl border border-pink-200 bg-linear-to-br from-pink-50 via-yellow-50 to-sky-50 p-6 shadow-[0_20px_60px_rgba(244,114,182,0.18)] ring-1 ring-white/70 sm:p-8"
>
  <div class="mb-5 flex items-center justify-between gap-3">
    <div class="flex items-center gap-3">
      <div
        class="flex h-12 w-12 items-center justify-center rounded-2xl bg-linear-to-br from-pink-500 to-rose-400 text-2xl shadow-lg shadow-pink-200/60"
      >
        ⭐
      </div>

      <div>
        <p
          class="text-xs font-semibold uppercase tracking-[0.32em] text-pink-500"
        >
          For kids
        </p>
        <h2 class="text-2xl font-bold text-slate-800 sm:text-3xl">
          Fun learning card
        </h2>
      </div>
    </div>

    <button
      type="button"
      class="inline-flex items-center gap-2 rounded-full bg-sky-500 px-4 py-2 text-sm font-semibold text-white shadow-md shadow-sky-200 transition hover:-translate-y-0.5 hover:bg-sky-600 active:translate-y-0"
      onclick={() => (count += 1)}
      aria-label="Increase counter"
    >
      Count <span class="min-w-5 text-center">{count}</span>
    </button>
  </div>

  <div
    class="rounded-2xl bg-white/80 p-4 shadow-inner shadow-white/60 ring-1 ring-pink-100 sm:p-6"
  >
    {@render children?.()}
  </div>

  <div class="mt-5 flex items-center justify-between text-sm text-slate-500">
    <span>Made for bright ideas and happy moments.</span>
    <span
      class="rounded-full bg-yellow-200 px-3 py-1 font-medium text-yellow-900"
      >New</span
    >
  </div>
</section>

This component has a simple button counter that uses Runes.

Create our Grid Component

<script setup>
import { ref, computed } from 'vue';
import Grid from './grid/Grid.vue';
import {
    load,
    LocalizationProvider,
    IntlProvider,
    loadMessages,
} from '@progress/kendo-vue-intl';

import { enComponentMessages, enCustomMessages } from './grid/en-US';
import { esComponentMessages, esCustomMessages } from './grid/es';
import { frComponentMessages, frCustomMessages } from './grid/fr';

import likelySubtags from 'cldr-core/supplemental/likelySubtags.json';
import currencyData from 'cldr-core/supplemental/currencyData.json';
import weekData from 'cldr-core/supplemental/weekData.json';

import numbers from 'cldr-numbers-full/main/es/numbers.json';
import caGregorian from 'cldr-dates-full/main/es/ca-gregorian.json';
import dateFields from 'cldr-dates-full/main/es/dateFields.json';
import timeZoneNames from 'cldr-dates-full/main/es/timeZoneNames.json';
import esNumbers from 'cldr-numbers-full/main/es/numbers.json';
import esCurrencies from 'cldr-numbers-full/main/es/currencies.json';

import frNumbers from 'cldr-numbers-full/main/fr/numbers.json';
import frCaGregorian from 'cldr-dates-full/main/fr/ca-gregorian.json';
import frDateFields from 'cldr-dates-full/main/fr/dateFields.json';
import frTimeZoneNames from 'cldr-dates-full/main/fr/timeZoneNames.json';
import frCurrencies from 'cldr-numbers-full/main/fr/currencies.json';

load(
    likelySubtags,
    currencyData,
    weekData,
    numbers,
    caGregorian,
    dateFields,
    timeZoneNames,
    esNumbers,
    esCurrencies,
    frNumbers,
    frCaGregorian,
    frDateFields,
    frTimeZoneNames,
    frCurrencies
);

loadMessages(enCustomMessages, 'English');
loadMessages(enComponentMessages, 'English');
loadMessages(esCustomMessages, 'Spanish');
loadMessages(esComponentMessages, 'Spanish');
loadMessages(frCustomMessages, 'French');
loadMessages(frComponentMessages, 'French');

const localizationLanguage = ref('English');
const locale = computed(() => {
    if (localizationLanguage.value === 'Spanish') return 'es';
    if (localizationLanguage.value === 'French') return 'fr';
    return 'en';
});

const onLocalizationLanguageChange = (e) => {
    localizationLanguage.value = e;
};
</script>

<template>
  <div>
    <LocalizationProvider :language="localizationLanguage">
      <IntlProvider :locale="locale">
        <Grid @localizationLanguageChange="onLocalizationLanguageChange" />
      </IntlProvider>
    </LocalizationProvider>
  </div>
</template>

The Grid component is broken up in several files and is copied directly from the Grid Demo.

Load Vue with Svelte

We create our Astro page under pages/index.astro.

---
import Panel from "../components/Panel.svelte";
import Grid from "../components/kendo-grid.vue";
import "../styles/global.css";
---

<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <link rel="icon" href="/favicon.ico" />
    <meta name="viewport" content="width=device-width" />
    <meta name="generator" content={Astro.generator} />
    <title>Astro</title>
  </head>
  <body>
    <Panel client:load>
      <Grid client:load />
    </Panel>
  </body>
</html>

Notice we are importing both a .svelte and a .vue component in the same file!
We use client:load to show that the component is dynamic.
Grid is a child of Panel.

And we have Kendo UI for Vue and a Svelte Component in one!

Resources

Try Kendo UI

All the Progress Kendo UI component libraries come with a free 30-day trial so you can explore them yourself.

Try Now

Ready with WebMCP: Building Agent-Ready Apps with Telerik and Kendo UI

2026-10-06T16:55:06Z

WebMCP has great potential to help make our apps super compatible with agents. Let’s learn more about this proposed standard and see how to start using a preview tool in Telerik and Kendo UI.

When I started working with AI agents, they were mostly good for writing code or running tasks on my local machine. But today, they do much more. AI agents can now open a browser, navigate webpages and interact with online applications just like we do.

The way agents interact with webpages today can be slow and fragile. Many browser agents act like a human looking at a screen, first taking screenshots, reading text from images or scanning thousands of lines of raw HTML, next trying to guess which button to click or which input to use.

What happens when an agent tries to interact with a data grid? Features like virtual scrolling, custom templates and dropdown menus make the HTML very complex. Rows disappear as you scroll. CSS classes change. When this happens, the agent gets lost.

What if our web applications could give AI agents a clear, direct API right inside the browser?

This is where Web Model Context Protocol (WebMCP) can help! We’re going to learn what WebMCP is and how Progress Telerik and Kendo UI libraries bring this proposed standard to your apps.

We will start with our existing NBA Players Scout Dashboard built with Angular and Kendo UI for Angular and see why an AI agent might struggle with it. Then we will make it agent-ready in just a few minutes using @progress/kendo-angular-webmcp.

Important note: WebMCP is still a proposed web standard that only works behind dev feature flags in certain browsers. This post and its demo should be treated as a preview.

Let’s make it work in a real project, but first let’s understand what WebMCP is.

What Is WebMCP?

You might already know Anthropic’s Model Context Protocol (MCP). MCP is an open standard. It connects AI assistants to external databases, files and developer tools. It usually runs on a server or a local machine.

WebMCP takes that idea and brings it directly inside your web browser.

Proposed by the W3C Web Machine Learning Community Group, WebMCP adds a new browser API: navigator.modelContext.

Think of WebMCP as an API menu for your webpage. Instead of asking an AI agent to read complex HTML elements, WebMCP lets your application register JavaScript functions as structured tools. Each tool has a clear name, a description and typed parameters.

When an AI agent visits your page, it does not need to guess how your UI works. It reads the list of tools, understands the parameters and runs the action directly.

But how do we actually create these tools without spending hours writing JSON schemas? That’s where Progress Telerik and Kendo UI steps in.

For a deeper understanding of WebMCP, check out the post: AI Crash Course: WebMCP.

Using Telerik and Kendo UI AI Tools for WebMCP

Creating custom tools by hand takes a lot of time. You have to write code and sync it with your UI state. This is where a component library like Kendo UI for Angular helps. And now, with native preview WebMCP support through the @progress/kendo-angular-webmcp, Kendo UI components are ready for AI agents immediately.

You do not need to write custom JSON schemas for sorting or filtering. You just add a directive to your component:

<kendo-grid [kendoWebMcp]="{ dataName: 'players' }">
  
kendo-grid>

When you add the kendoWebMcp directive to a component like the Kendo UI Grid:

The directive checks active features, such as [sortable]="true" or [filterable]="true".
It registers tools into the browser context, such as players-sort-column or players-filter.
When an AI agent calls one of these tools, the directive calls the internal Grid methods. Angular reacts, updates the state and refreshes the view.

To test these tools, Progress provides the Telerik & Kendo UI WebMCP Browser Extension. It gives you a chat panel right in your browser. Before we write any code, we need to make sure our browser can actually understand these new WebMCP commands.

Progress also offers preview React WebMCP tools and Blazor WebMCP tools. Progress WebMCP integration tools are preview features because WebMCP is still a proposed web standard that only works in limited situations. In a quickly evolving ecosystem, support may also be limited.

Preparing Your Browser

Because WebMCP is a newly proposed web standard, we need two quick setup steps before we start:

1. Enable the Browser Flag

WebMCP currently runs behind a flag in Chromium browsers (Google Chrome or Microsoft Edge).

Open your browser and go to: chrome://flags/#enable-webmcp-testing
Set the flag to Enabled.
Click Relaunch at the bottom of the window.

2. Install and Configure the Telerik WebMCP Extension

Install the Telerik & Kendo UI WebMCP Extension from the Chrome Web Store.

The extension acts as a bridge between the browser and an LLM (Large Language Model) to interpret natural language commands. You need to configure it with an API key from an AI provider (such as Anthropic, Google Gemini or OpenAI).
Open the extension settings (the gear icon), choose your preferred provider and paste your API key.
(Recommended): In the same settings menu under “Behavior,” turn on Auto-approve tool calls. This makes the chat experience much smoother because the AI won’t ask for permission every time it wants to update the Grid.

Once configured, you can open the chat panel, select your desired model and start typing prompts!

Warning: WebMCP and this extension are currently experimental. If you get an API error, just switch to Anthropic or OpenAI in the settings.

Now your browser is fully ready! With the environment configured, we are ready to dive into the code and see this in action.

The Starting Point: Our Existing NBA Scout Dashboard

In the real world, we rarely build applications from scratch just to support AI agents. Usually, we already have production applications.

Let’s look at our existing application: an NBA Scout Dashboard. Basketball scouts use it to review player statistics.

Follow: The complete source code is available on GitHub. You can clone the starter branch to follow this tutorial step by step, or switch to the main branch to see the final code.

To follow along, open your terminal and clone the starter branch of the repository:

git clone -b starter https://github.com/danywalls/webmcp-kendo-angular.git
cd webmcp-kendo-angular
npm install

The data model in src/app/player.model.ts looks like this:

export interface Player {
  id: number;
  name: string;
  team: string;
  conference: 'East' | 'West';
  position: 'PG' | 'SG' | 'SF' | 'PF' | 'C';
  ppg: number;
  rpg: number;
  apg: number;
  status: 'Active' | 'Day-to-Day' | 'Injured';
}

export const NBA_PLAYERS: Player[] = [
  { id: 1, name: 'Luka Doncic', team: 'Mavericks', conference: 'West', position: 'PG', ppg: 33.9, rpg: 9.2, apg: 9.8, status: 'Active' },
  // ... more players
];

The component in src/app/app.ts is a modern standalone Angular component using KENDO_GRID:

import { Component, signal } from '@angular/core';
import { KENDO_GRID } from '@progress/kendo-angular-grid';
import { Player, NBA_PLAYERS } from './player.model';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [KENDO_GRID],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  players = signal<Player[]>(NBA_PLAYERS);
}

And here is the template in src/app/app.html:

<main class="dashboard-container">
  <header class="dashboard-header">
    <h1>NBA Scout Intelligence Dashboardh1>
    <p>Powered by Angular and Kendo UIp>
  header>

  <section class="grid-wrapper">
    <kendo-grid
      [kendoGridBinding]="players()"
      [sortable]="true"
      [filterable]="true"
    >
      <kendo-grid-column field="name" title="Player Name" [width]="200">kendo-grid-column>
      <kendo-grid-column field="team" title="Team" [width]="130">kendo-grid-column>
      <kendo-grid-column field="conference" title="Conf" [width]="90">kendo-grid-column>
      <kendo-grid-column field="position" title="Pos" [width]="90">kendo-grid-column>
      <kendo-grid-column field="ppg" title="PPG" filter="numeric" [width]="100">kendo-grid-column>
      <kendo-grid-column field="rpg" title="RPG" filter="numeric" [width]="100">kendo-grid-column>
      <kendo-grid-column field="apg" title="APG" filter="numeric" [width]="100">kendo-grid-column>
      <kendo-grid-column field="status" title="Status" [width]="130">
        <ng-template kendoGridCellTemplate let-dataItem>
          <span [class]="'badge badge-' + dataItem.status.toLowerCase().replace(' ', '-')">
            {{ dataItem.status }}
          span>
        ng-template>
      kendo-grid-column>
    kendo-grid>
  section>
main>

Start the application by running this command:

npm start

Testing the App as a Human User

If you open http://localhost:4200 in your browser right now, you’ll see a fully functional grid. Click the column headers to sort the data, or open the filter menus to find specific players. For us humans, the dashboard works perfectly and is ready to use. But what happens when an AI agent tries to do the exact same thing? Let’s find out.

The Problem: How an AI Agent Sees Our App Today

Now, open the Telerik & Kendo UI WebMCP Extension in your browser toolbar and click the Tools tab.

You will see: No tools available.

Because we did not register any tools, the AI agent has no direct way to interact with the grid. If you ask the agent to “Show me point guards with more than 25 PPG”, it has to guess the HTML structure. If the grid layout changes, the agent fails.

What problem does this solve for us as developers? We want our existing application to tell the agent exactly what it can do, without rewriting all our code.

So, how do we bridge this gap and give the AI the exact tools it needs? Let’s make this app agent-ready in just three simple steps.

Making the Existing Application Agent-Ready

So far, we have tested our dashboard and seen the problem. Now, let’s fix it in three simple steps.

Install @progress/kendo-angular-webmcp

Stop your development server and run this command:

npm install @progress/kendo-angular-webmcp

This installs the Kendo UI WebMCP package.

Step 2: Import KENDO_WEBMCP in the Component

Open src/app/app.ts. Import KENDO_WEBMCP and add it to the imports array:

// Update src/app/app.ts
import { Component, signal } from '@angular/core';
import { KENDO_GRID } from '@progress/kendo-angular-grid';
import { KENDO_WEBMCP } from '@progress/kendo-angular-webmcp';
import { Player, NBA_PLAYERS } from './player.model';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [KENDO_GRID, KENDO_WEBMCP],
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  players = signal<Player[]>(NBA_PLAYERS);
}

Add the kendoWebMcp Directive to the Grid

Open src/app/app.html. Update the tag to include [kendoWebMcp]:


<kendo-grid
  [kendoGridBinding]="players()"
  [sortable]="true"
  [filterable]="true"
  [kendoWebMcp]="{ dataName: 'players' }"
>

What Just Happened Here?

With just [kendoWebMcp]="{ dataName: 'players' }", Kendo UI checks your grid features. Because [sortable]="true" and [filterable]="true" are on, it automatically creates a list of tools like:

players-sort-column: Lets the agent sort any column.
players-filter: Lets the agent filter columns (e.g., greater than, equal to).
players-highlight: Lets the agent visually highlight specific rows.

Notice what we did not do. We did not write complex JSON schemas. We did not change our Angular signals. It just works. Now that our grid is exposing these tools natively, it is time to put the AI agent to the test.

Interacting with the AI Agent

Let’s see the result. Start your application again (npm start).

Verifying the Tools

URL: http://localhost:4200
Action: Refresh the page. Open the Telerik WebMCP Extension and check the Tools tab.
Expected Result: You see players-sort-column, players-filter and players-highlight listed.

Let’s test a prompt with a multi-condition filtering. In the extension chat, type:

“Show me all Western Conference PG averaging more than 25 points per game.”

Instead of clicking menus, the AI calls the players-filter tool using this JSON:

{
  "filters": [
    { "field": "conference", "operator": "eq", "value": "West" },
    { "field": "position", "operator": "eq", "value": "PG" },
    { "field": "ppg", "operator": "gt", "value": 25 }
  ]
}

The Kendo UI Grid applies the filter immediately! Luka Doncic, Shai Gilgeous-Alexander and Stephen Curry remain visible.

Next, clear the filter and try sorting and highlighting this two-step prompt:

“Clear the filter, sort players by PPG descending, and highlight any player who is currently injured.”

The agent calls two tools automatically:

players-sort-column with { field: "ppg", dir: "desc" }.
players-highlight matching rows where status == "Injured".

Joel Embiid and Jimmy Butler are highlighted. There is no guessing HTML structure. It is fast and reliable.

Play with it and see how the AI manipulates the UI like magic!

But what does this mean for us architecturally?

This update to WebMCP brings a few key points to improve our app’s interactions with agents:

Instead of an agent taking heavy screenshots or a scraping agent reading massive HTML blocks, WebMCP only uses small JSON payloads. This saves money, time and tokens!
WebMCP helps provide stable interactions. UI designs and CSS classes can change often, so if an agent relies on HTML tags like .k-grid-table > tr, it will break. WebMCP creates a clear contract. You can change your CSS without breaking the AI agent.
The best part is the native Angular support, because Kendo UI for Angular components are created natively with Angular. When the AI agent calls a tool, Kendo UI updates the grid properly.

This all sounds great, but of course not everything in preview is perfect yet, and WebMCP brings some trade-offs to keep in mind:

Experimental specification: WebMCP is still an experimental draft. The API might change before becoming a final standard.
Browser setup required: Users currently need to enable a browser flag and install an extension. In the future, browsers will support this natively.
Client-side security: Tools run in the browser session. Always validate inputs and check permissions on your backend server.

Despite these early-stage trade-offs, the future of AI-driven web apps is incredibly and amazing.

Recap

WebMCP gives AI agents a more reliable way to interact with your web applications. In this guide, we explored what WebMCP is and why standard web apps are hard for AI agents to use.

Then, we solved this problem using @progress/kendo-angular-webmcp. With a simple directive, we made our app agent-ready and watched an AI agent sort, filter and highlight our data using natural language.

You can find the final code main branch of our GitHub repository.

Happy coding!

Remember, Telerik and Kendo UI components come with a free trial. So, go on and explore the ever-evolving AI-readiness of these well-known components for yourself.

Try Now

The 10 Best Angular UI Chart Libraries

2026-09-22T20:34:30Z

TL;DR Which Angular charts library is best? With the native build, 18+ styles of charts, accessibility and AI integrations, Kendo UI for Angular is hard to top.

It does not matter if you are building a static page, a dynamic dashboard, a landing page to show NBA results or an AI-powered application. The web needs charts. Data visualization is everywhere, and choosing the right chart library is a decision that affects every Angular project.

During these years, I have created charts with many libraries. I started with jQuery plugins, then moved to D3.js, Chart.js, Highcharts and many others. Each project brought a new challenge and a new library to learn. Some were easy to start with but hard to maintain. Others were powerful but difficult to integrate with Angular. Today, my go-to choice is Progress Kendo UI for Angular Charts because it solves most of the problems I found along the way.

Today, the options are better than ever. But the question remains the same: "Which chart library should I use?"

In this article, we are going to compare the 10 best Angular chart libraries available in 2026. For each one, I will share its strengths, its weaknesses and my honest recommendation. By the end, you will know exactly which library fits your next project.

The Scenario

Imagine you are building a financial dashboard for a fintech startup. The app needs real-time stock charts, interactive bar charts for monthly revenue, pie charts for portfolio distribution and heat maps for risk analysis. The deadline is in two weeks. Your team has three Angular developers and one designer who works in Figma.

In this situation, your chart library is not just about rendering bars and lines. It needs to integrate cleanly with Angular, support real-time data, look consistent with your brand and be easy to maintain over time. You also need your AI coding agents to understand the component API so they can help you build faster.

I have seen teams spend weeks trying to make a chart library work with Angular, only to switch to another one and start over. Making the right choice from the beginning saves you that pain.

Let’s look at the options.

1. Kendo UI for Angular Charts

The Kendo UI for Angular Charts are, in my experience, the most complete charting solution for Angular applications in 2026.

They are not just a wrapper around a JavaScript library. They are native Angular components built from the ground up for the framework. These charts use Angular’s template system, dependency injection and change detection natively. This means better performance and a developer experience that feels natural.

Why Kendo UI Charts Is the Best Choice IMO

What makes Kendo UI charts stand out is the combination of completeness and Angular-native design. You get 18+ chart types across four categories: Categorical (Line, Bar, OHLC/Candlestick), Circular (Pie, Donut), Freeform (Funnel) and Scatter (Bubble, Scatter Plot). Plus dedicated components like Sparkline, StockChart and Sankey, and many more. Every one of these is a first-class Angular component with full TypeScript support.

And each type of chart comes with a wide range of functionality and customization:

Dual configuration modes: You can configure charts using TypeScript objects (great for loading settings from an API) or Angular template components (great for IDE support and type checking). You can even mix both approaches in the same chart, using objects for global settings and components for series-specific configuration.
Real-time data support: The StockChart component handles live data feeds with smooth animations. If you are building financial dashboards or monitoring tools, this is critical.
Drilldown functionality: Explore data in a view hierarchy directly within your charts. Users can click to see details without leaving the component.
Panning and Zooming: Simple interactions allow users to explore data by moving across categories or zooming into specific ranges. You can enable or disable these features per chart.
Export options: Built-in export to PNG, PDF, SVG and the Kendo UI Drawing format for further processing. No extra libraries needed.
Rendering modes: Choose between SVG (vector, default) and Canvas (bitmap) depending on your performance needs. Switching is a single configuration option.
WCAG 2.2 AA accessibility: Full compliance with Section 508 and WAI-ARIA best practices. Tested against screen readers including JAWS and NVDA.
Context Menu integration: Right-click on data points to trigger custom actions. Works well with the Kendo UI ContextMenu component.
ThemeBuilder and Figma kits: Your designer creates the look in Figma, you apply it with ThemeBuilder. The new Meridian theme joins Bootstrap, Material and other popular options. No CSS customization problems.
WebMCP support (2026 Q2): Kendo UI for Angular components are now agent-ready out of the box. AI agents can interact with your charts by calling structured tools directly, triggering actions like filtering data or updating values through natural language. This is the future of UI development.
Agentic UI Generator: Build chart components and layouts using natural language prompts directly inside AI-powered IDEs like VS Code and Cursor. Get intelligent assistance powered by Kendo UI documentation and APIs.
Codemods CLI: Upgrade to the latest Kendo UI version faster with AI-assisted migration. The tool automates code transformations, shows changes with diff-style output and provides a detailed migration report.
Professional support: When your StockChart breaks at 2 AM before a demo, you have a team of engineers who built the component ready to help you. Not a forum post from 2019.

Pro tip: You can try Kendo UI for Angular Charts free for 30 days, no credit card required. The fastest way to prove to your team that this is the right choice is to build a small prototype and see how fast you can go.

But what if you prefer a simpler, open-source approach? That brings us to our next option.

2. Chart.js with ng2-charts

Chart.js with ng2-charts is the most popular lightweight option for Angular developers who need quick, simple charts without a difficult learning process.

The Good: Very easy to set up. You can have a bar chart running in minutes. The library is lightweight and performs well for simple use cases. It supports the most common chart types: bar, line, pie, doughnut, radar, scatter and bubble.
The Cons: Limited customization compared to enterprise libraries. The Angular wrapper (ng2-charts) is a community project, not an official Angular integration. When you need advanced features like real-time streaming, custom tooltips or complex animations, you will reach its limits quickly.
My Feedback: Chart.js is perfect for a quick prototype or a small internal tool. But for a production dashboard with real-time data and brand customization, you will need more than it can offer. The Kendo UI library gives you the same simplicity for basic charts but grows with enterprise needs without switching libraries.

If you want something more powerful than Chart.js but still open-source, keep reading.

3. Apache ECharts

Apache ECharts is one of the most powerful open-source charting libraries available. It offers advanced visualization capabilities and strong performance with large datasets.

The Good: 20+ built-in chart types with advanced components like heat maps, treemaps, Sankey diagrams and candlestick charts. It handles large datasets well and offers rich interactivity out of the box. The library is free under the Apache 2.0 license.
The Cons: The Angular integration requires wrappers like ngx-echarts, which are community-maintained. The API can feel overwhelming for developers coming from simpler libraries. The documentation is comprehensive but not always easy to navigate.
My Feedback: ECharts is a solid open-source choice, especially if budget is a concern. However, the Angular integration is not native. If you are building a production app where support and consistency matter, the Kendo UI library’s native Angular components and professional support make it a safer investment.

If your project has a lot of data and you need something more focused on dashboards, check out the next option.

4. Highcharts Angular

Highcharts is one of the most mature and well-known charting libraries in the market. It has been around since 2009 and offers an official Angular wrapper.

The Good: Excellent documentation and a polished API. Highcharts offers specialized modules for stock charts, maps and Gantt charts. The visual quality is high and the library handles accessibility well with WCAG compliance.
The Cons: Commercial license required for business use. The Angular wrapper is not a native Angular component, which means you lose some of Angular’s template features and type safety. Customization beyond the built-in options can be complex.
My Feedback: Highcharts is a solid library, but the licensing model and the wrapper-based Angular integration are limitations. The Kendo UI library offers a similar level of visual quality with native Angular components, a more flexible licensing model and the added benefit of ThemeBuilder for design consistency.

For teams that need a large chart collection with commercial support, the next option is worth considering.

5. FusionCharts Angular

FusionCharts is an enterprise-focused charting library with over 95 chart types, 1,400+ maps and 20+ dashboard components.

The Good: The variety of chart types is impressive, including specialized visualizations like funnel charts, gauges and Gantt charts. It handles medium to large datasets well and offers commercial support.
The Cons: Commercial license required. The Angular integration uses a wrapper approach. The API can feel heavy for simple use cases. The learning curve is steeper than simpler alternatives.
My Feedback: FusionCharts is powerful, but it can be too much for many projects. If you only need 5 or 6 chart types, you are paying for complexity you will never use. The Kendo UI library gives you a similar variety of chart types with a lighter API and native Angular integration.

If you want a modern, lightweight option with great interactivity, the next library might interest you.

6. ApexCharts Angular

ApexCharts is a modern, open-source charting library that focuses on beautiful, interactive charts with minimal configuration.

The Good: Clean, modern design out of the box. Built-in interactivity like zooming, panning and tooltips without extra configuration. The Angular wrapper (ng-apexcharts) is straightforward to use. Supports 20+ chart types.
The Cons: The Angular wrapper is community-maintained. Limited chart variety compared to enterprise libraries. No built-in maps or Gantt charts. The commercial license applies for business use.
My Feedback: ApexCharts is great for modern dashboards where visual appeal matters. However, the community Angular wrapper means you depend on external maintainers. If your project needs long-term stability and professional support, the Kendo UI library’s native Angular components are a more reliable choice.

For developers who want maximum flexibility and are willing to write more code, the next option is worth exploring.

7. D3.js with Angular

D3.js is the most powerful and flexible data visualization library available. It gives you complete control over every pixel of your charts.

The Good: Maximum flexibility. You can create any visualization you can imagine, from simple bar charts to complex custom interactive dashboards. The data-binding capabilities are unmatched.
The Cons: Difficult learning process. D3 is not a charting library, it is a visualization toolkit. Even simple charts require significant code. There is no Angular-specific integration, so you need to handle all the Angular-D3 setup yourself.
My Feedback: D3.js is incredible for custom visualizations that no other library can create. But for a business dashboard with standard chart types, it is too much work. You will spend weeks building what Kendo UI gives you in hours. Use D3 for the 5% of charts that need custom work, and use Kendo UI for the other 95%.

If your focus is on Angular-native solutions, the next option is worth a look.

8. ngx-charts

ngx-charts is a charting library built specifically for Angular, using D3.js internally.

The Good: Angular-native design. The library uses Angular components and supports features like animation and interactivity. It covers the most common chart types: bar, line, pie, area, polar and heat maps.
The Cons: The project has not been actively maintained in recent years. The chart variety is limited compared to enterprise libraries. Performance can decrease with large datasets.
My Feedback: ngx-charts was a good option when it was actively maintained, but the lack of recent updates is a concern for production apps. If you want Angular-native charts with active development and professional support, Kendo UI for Angular is the clear choice.

For teams already invested in the Syncfusion ecosystem, the next option might be familiar.

9. Syncfusion Angular Charts

Syncfusion offers a comprehensive suite of Angular components including a powerful charting library.

The Good: Wide variety of chart types. Good performance with large datasets. The components are well-integrated with other Syncfusion components.
The Cons: The API does not always feel like standard Angular, which makes it harder to learn. Customizing charts to match a specific Figma design can be challenging. The styling system can feel overwhelming.
My Feedback: Syncfusion charts are powerful, but the developer experience can feel heavy. If you want charts that integrate cleanly with Angular’s template system and offer ThemeBuilder for design consistency, the Kendo UI library provides a simpler experience for both developers and designers.

Finally, for developers who want a modern, modular approach, the last option is worth considering.

10. Plotly.js

Plotly.js is an open-source graphing library that supports over 20 chart types and offers an Angular wrapper.

The Good: Good for scientific and statistical visualizations. Supports 3D charts, which is rare among charting libraries. The library is open-source and well-documented.
The Cons: The Angular wrapper is not officially maintained by the Plotly team. The library can be heavy for simple use cases. The visual style is functional but not as polished as commercial alternatives.
My Feedback: Plotly.js is a good choice for scientific or research applications where 3D visualization is needed. For business dashboards and enterprise applications, the Kendo UI library offers a more polished look, better Angular integration and the consistency of a complete component suite.

Recap

Choosing the right Angular chart library in 2026 is about matching your project’s needs with the right tool. If you are building a serious Angular application in 2026, Kendo UI for Angular Charts is the strongest choice.

You get production-ready native Angular components, 18+ chart types, real-time data, drilldown functionality, of course WCAG 2.2 AA accessibility, ThemeBuilder integration and AI-ready tools through WebMCP and the Agentic UI Generator. All backed by professional support from the team that built the software (so you never feel alone).

The best chart library is the one that lets you focus on your data, not on fighting with the tool. Kendo UI for Angular gives you that freedom.

Do You Want to Try It?

The Kendo UI for Angular Charts, plus 120 other components are all available to try free for 30 days.

Download Free Trial

Angular State Management: From Local Signals to NgRx SignalStore

2026-09-16T20:28:49Z

Last time, we looked at which state management method to choose for your Angular app. This time, we’ll explore this in a real app so you can see why different solutions work better for different cases.

It doesn’t matter if you are working with Angular 4, 15, 20 or the latest version 22. Every time I start a new project, I face the same big question: “Where should I put this data?”

I learned this through many challenges. Often you start small and think a few variables are enough. But the app grows fast, and suddenly you are struggling with too many inputs, outputs and “prop drilling.” Based on my experience, state management is about setting the rules for how data flows in your app.

Whether it is a tiny prototype or a large enterprise dashboard, the choices you make today will make your life easier when requirements change later. The tools have evolved, from complex RxJS streams to the simplicity of Signals, but the goal is the same: keeping your UI and data in sync without making it too difficult.

Think of this as a carpenter’s workshop. Different jobs need different tools. We explored this decision in detail in our guide: Decision Guide for Angular State Management: Signals, Services, SignalStore or NgRx.

Today, we are going to learn how to build a real accounting dashboard using the modern patterns of Angular 22 with UI components from the Progress Kendo UI for Angular library. We will start simple and add complexity only when the logic needs it. By the end, you will have a clear plan to decide what goes where, so you can build apps that stay clean as they grow.

Let’s make this work in a real project.

Follow along: All the code for this dashboard is available on GitHub. Feel free to clone it and experiment while you read!

Setting Up the Project

First, let’s create our accounting dashboard app. Open your terminal and run:

ng new accounting-dashboard --standalone --style=scss

Add the libraries we will use across the article. Since Kendo UI components need internationalization and animations, we will also include those packages:

npm install @progress/kendo-angular-grid @progress/kendo-angular-dropdowns @progress/kendo-angular-dateinputs @progress/kendo-angular-buttons @progress/kendo-angular-inputs @progress/kendo-theme-default
npm install @ngrx/signals @ngrx/store @ngrx/effects @ngrx/entity @ngrx/operators @ngrx/signals/events
npm install @angular/localize @angular/animations

Import the Kendo UI theme in src/styles.scss:

@import "@progress/kendo-theme-default/dist/all.css";

Configuring Polyfills

Kendo UI relies on Angular’s localization. Open your angular.json and add @angular/localize/init to the polyfills array of your project:

"polyfills": ["@angular/localize/init"],

Now we have a project ready to go. Each section below builds on the same accounting theme: journal entries, chart of accounts and financial periods.

Project Structure

Here is the folder layout we will build. Create each file as we go through the sections:

src/
  app/
    journal-list/
      journal-list.component.ts
    journal-entry/
      journal-entry.component.ts
    ledger-view/
      ledger-view.component.ts
    account.service.ts
    journal.store.ts
    ledger.state.ts
    period.actions.ts
    period.effects.ts
    app.component.ts
    app.config.ts

We need to configure the app to support HTTP, animations, and modern features. In Angular 22, provideHttpClient() uses the Fetch API by default. Update app.config.ts:

import { ApplicationConfig } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';
import { provideAnimations } from '@angular/platform-browser/animations';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(),
    provideAnimations()
  ]
};

The app.component.ts connects all pieces. We will update it as we add each section:

import { Component } from '@angular/core';
import { JournalListComponent } from './journal-list/journal-list.component';
import { JournalEntryComponent } from './journal-entry/journal-entry.component';
import { LedgerViewComponent } from './ledger-view/ledger-view.component';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [JournalListComponent, JournalEntryComponent, LedgerViewComponent],
  template: `
    Accounting Dashboard
    
      
      
      
    
  `
})
export class AppComponent {
  title = 'Accounting Dashboard';
}

So far we created the project. Now let’s understand what we are solving.

What Problem Does State Management Solve?

Think of your app as a whiteboard. Many components write and read data on it. Without clear rules, one part of the app might delete data that another part needs. Or, two parts might try to change the exact same data at the same time. Using state management is simply the set of rules for who can read, who can write and how everyone stays updated.

As we talked about in our previous Decision Guide for Angular State Management, an app has different types of state. Some state is very simple and only belongs to one component, like a search box. Other state is global and shared across the whole app, like opening or closing a financial month in our accounting app.

Because these types of data are so different, we cannot manage them all the same way. We need to pick the right tool for each job.

Let’s start with the simplest one.

Local State with Signals

The first rule of Angular state management: start with the simplest solution.

What problem does this solve for us? When data only lives in one component, why add a complex library?

In Angular 22, OnPush is the default way components check for changes. This means components only update when a signal changes or a new input arrives. This makes signal() a great choice for local state: it is fast, simple and updates only the parts of the app that changed.

In our accounting dashboard, imagine a list with a search filter. The search text belongs to this component alone. No other component needs it.

Note: To keep this guide practical and visual, we will include some sample data in our examples. This allows you to see the Kendo UI components in action immediately without needing a backend server.

import { Component, signal, computed } from '@angular/core';
import { CurrencyPipe } from '@angular/common';
import { KENDO_TEXTBOX } from '@progress/kendo-angular-inputs';

interface JournalEntry {
  id: number;
  date: string;
  description: string;
  total: number;
}

@Component({
  selector: 'app-journal-list',
  standalone: true,
  imports: [CurrencyPipe, KENDO_TEXTBOX],
  template: `
    

    Showing {{ filteredCount() }} of {{ entries().length }} entries

    @for (entry of filteredEntries(); track entry.id) {
      
        {{ entry.date }} - {{ entry.description }}: {{ entry.total | currency }}
      
    } @empty {
      No entries found.
    }
  `
})
export class JournalListComponent {
  readonly entries = signal<JournalEntry[]>([
    { id: 1, date: '2026-07-01', description: 'Monthly Subscription Sale', total: 150.00 },
    { id: 2, date: '2026-07-02', description: 'Office Supplies', total: 45.50 },
    { id: 3, date: '2026-07-05', description: 'Consulting Service', total: 1200.00 }
  ]);
  readonly searchTerm = signal('');

  readonly filteredEntries = computed(() =>
    this.entries().filter(e =>
      e.description.toLowerCase().includes(this.searchTerm().toLowerCase())
    )
  );
  readonly filteredCount = computed(() => this.filteredEntries().length);
}

Notice the @for control flow syntax and the @empty block. No *ngFor here—this is modern Angular.

Also notice: no imports from NgRx, no actions, no reducers. Just two signal() calls and a computed(). That is it.

The comes from Kendo UI and gives us a styled input with zero CSS work.

Tip: If you want to avoid filtering on every keystroke, Angular 22 offers a new (experimental) debounced() function. It creates a debounced version of a signal that you can consume in your computed() logic.

When to use this approach: State that only one component and its children need. Examples: search filters, toggle visibility, form input values, selected tab index.

So far we have local state, but what happens when two unrelated components need the same data? Let’s move to shared state.

Shared State with Services

When many components need the same data, a service with Signals is the right tool.

You could pass data through inputs and outputs. But that gets difficult when components are in different parts of the app.

Angular 22 introduces the @Service decorator. It is a new, shorter way to create services that are available everywhere in your app. It makes it easy to use the inject() function, which keeps our code clean and reactive. This is a great but often forgotten pattern in Angular. Seriously.

import { Service, computed, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';

export interface Account {
  code: string;
  name: string;
  type: 'asset' | 'liability' | 'equity' | 'revenue' | 'expense';
}

@Service()
export class AccountService {
  private readonly _accountsRes = httpResource<Account[]>(() => '/api/accounts');
  private readonly _localAccounts = signal<Account[]>([
    { code: '101', name: 'Cash', type: 'asset' },
    { code: '102', name: 'Accounts Receivable', type: 'asset' },
    { code: '401', name: 'Sales Revenue', type: 'revenue' },
    { code: '501', name: 'Operating Expenses', type: 'expense' }
  ]);
  private readonly _selectedCode = signal<string | null>(null);

  readonly accounts = computed(() => [
    ...(this._accountsRes.value() ?? []),
    ...this._localAccounts()
  ]);
  readonly isLoading = this._accountsRes.isLoading;
  readonly selectedCode = this._selectedCode.asReadonly();

  readonly selectedAccount = computed(() =>
    this.accounts().find(a => a.code === this._selectedCode())
  );

  readonly revenueAccounts = computed(() =>
    this.accounts().filter(a => a.type === 'revenue')
  );

  selectAccount(code: string) {
    this._selectedCode.set(code);
  }

  addAccount(account: Account) {
    this._localAccounts.update(list => [...list, account]);
  }
}

Now any component can inject AccountService and get the same data. The journal entry form uses a Kendo UI DropDownList to select accounts:

import { Component, inject } from '@angular/core';
import { KENDO_DROPDOWNLIST } from '@progress/kendo-angular-dropdowns';
import { AccountService } from '../account.service';

@Component({
  selector: 'app-journal-entry',
  standalone: true,
  imports: [KENDO_DROPDOWNLIST],
  template: `
    New Journal Entry

    Revenue Account:
    
    

    @if (selectedAccount(); as acct) {
      Selected: {{ acct.name }} - {{ acct.type }}
    }
  `
})
export class JournalEntryComponent {
  private readonly accountService = inject(AccountService);

  readonly revenueAccounts = this.accountService.revenueAccounts;
  readonly selectedAccount = this.accountService.selectedAccount;

  onSelectAccount(code: string) {
    if (code) {
      this.accountService.selectAccount(code);
    }
  }
}

The handles the UI: search within the dropdown, keyboard navigation, disabled state. We get this for free.

Tip: For heavy services that are only needed occasionally (like generating a PDF report), use injectAsync(). It allows you to lazy-load the service instance only when it is actually called, reducing your initial bundle size.

When to use this approach: State shared by 2 to 10 components within the same feature. Examples: chart of accounts, user preferences for a module, selected filters shared between list and detail views.

When to escalate: You need strict conventions, computed state with complex rules or DevTools for debugging. That is SignalStore territory.

Signals or BehaviorSubject?

I often ask myself: should I use signal() or BehaviorSubject?

In the Decision Guide for Angular State Management post, I compared both options. My advice is simple. For new code, Signals are the best choice. They are very easy to read, and they work perfectly with Angular. I only use RxJS (BehaviorSubject) for complex tasks. For example, I use it to delay a search (debounce) or to stop a web request. For normal data, I just use Signals.

So far, we have shared data using a simple service. Now, let’s add some rules and structure.

NgRx SignalStore

SignalStore gives you structure without all the extra code of classic NgRx. It is the recommended state management solution for Angular apps (NgRx team, v19+).

A simple service works well for basic state. But as your feature grows, you want rules: computed values, loading states and a consistent way to change data. Without these, team members might name methods differently or change data in confusing ways.

Think of SignalStore as the middle ground between a simple service and a complex Redux store.

In our accounting app, journal entries have rules: debits and credits must balance. A JournalStore can check this automatically with computed values.

import { signalStore, withState, withComputed, withMethods, patchState, withHooks } from '@ngrx/signals';
import { computed, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { tapResponse } from '@ngrx/operators';
import { pipe, switchMap, tap } from 'rxjs';

export interface JournalLine {
  accountCode: string;
  debit: number;
  credit: number;
}

export interface JournalEntry {
  id: number;
  date: string;
  description: string;
  lines: JournalLine[];
}

type JournalState = {
  entries: JournalEntry[];
  isLoading: boolean;
};

const initialState: JournalState = {
  entries: [
    {
      id: 1,
      date: '2026-07-01',
      description: 'Initial Opening Balance',
      lines: [
        { accountCode: '101', debit: 5000, credit: 0 },
        { accountCode: '301', debit: 0, credit: 5000 }
      ]
    },
    {
      id: 2,
      date: '2026-07-08',
      description: 'Service Revenue Recognition',
      lines: [
        { accountCode: '102', debit: 1200, credit: 0 },
        { accountCode: '401', debit: 0, credit: 1200 }
      ]
    }
  ],
  isLoading: false
};

function totalDebits(entries: JournalEntry[]): number {
  return entries.reduce((sum, e) =>
    sum + e.lines.reduce((s, l) => s + l.debit, 0), 0
  );
}

function totalCredits(entries: JournalEntry[]): number {
  return entries.reduce((sum, e) =>
    sum + e.lines.reduce((s, l) => s + l.credit, 0), 0
  );
}

export const JournalStore = signalStore(
  { providedIn: 'root' },

  withState(initialState),

  withComputed((store) => ({
    entryCount: computed(() => store.entries().length),
    totalDebits: computed(() => totalDebits(store.entries())),
    totalCredits: computed(() => totalCredits(store.entries())),
    isBalanced: computed(() => totalDebits(store.entries()) === totalCredits(store.entries())),
  })),

  withMethods((store, http = inject(HttpClient)) => ({
    loadEntries: rxMethod<void>(
      pipe(
        tap(() => patchState(store, { isLoading: true })),
        switchMap(() =>
          http.get<JournalEntry[]>('/api/journal-entries').pipe(
            tapResponse({
              next: (entries) => patchState(store, { entries, isLoading: false }),
              error: () => patchState(store, { isLoading: false }),
            })
          )
        )
      )
    ),

    addEntry(entry: JournalEntry) {
      patchState(store, { entries: [...store.entries(), entry] });
    },
  })),

  withHooks({
    onInit(store) {
      store.loadEntries();
    },
  })
);

Tip: For simple data loading, prefer async/await with patchState or Angular’s httpResource (v19+). Reserve rxMethod for complex reactive flows like cancellation or dependent requests and with httpResource, the loading state is managed automatically:

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

// in a component or service:
readonly entriesResource = httpResource<JournalEntry[]>(() => '/api/journal-entries');
readonly entries = computed(() => this.entriesResource.value() ?? []);
readonly isLoading = this.entriesResource.isLoading;

Now a component can use the store and display the results in a Kendo UI for Angular Grid:

import { Component, inject } from '@angular/core';
import { CurrencyPipe } from '@angular/common';
import { KENDO_GRID } from '@progress/kendo-angular-grid';
import { JournalStore, JournalLine } from '../journal.store';

@Component({
  selector: 'app-ledger-view',
  standalone: true,
  imports: [CurrencyPipe, KENDO_GRID],
  template: `
    General Ledger

    @if (store.isLoading()) {
      Loading entries...
    } @else {
      
        
        
        
        
        
          
            {{ getDebitTotal(dataItem.lines) | currency }}
          
        
        
          
            {{ getCreditTotal(dataItem.lines) | currency }}
          
        
      
    }

    @if (!store.isBalanced()) {
      
        Warning: Journal entries are not balanced!
      
    }
  `
})
export class LedgerViewComponent {
  readonly store = inject(JournalStore);

  getDebitTotal(lines: JournalLine[]) {
    return lines.reduce((s, l) => s + l.debit, 0);
  }

  getCreditTotal(lines: JournalLine[]) {
    return lines.reduce((s, l) => s + l.credit, 0);
  }
}

The gives us sorting, paging, and column resize out of the box. And the isBalanced() computed signal shows a warning instantly when numbers do not match.

Adding More SignalStore Features

SignalStore has more tools to help you write code faster without leaving the signal model.

withProps adds injected services or static properties to the store. In our case, we can inject the AccountService from the previous section:

import { withProps } from '@ngrx/signals';
import { AccountService } from './account.service';

export const JournalStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withComputed(/* ... */),
  withProps(() => ({
    accountService: inject(AccountService),
  })),
  withMethods(/* ... */)
);

withHooks provides onInit and onDestroy lifecycle hooks. As shown in our main example, this is the modern way to load data when the store is first used, keeping your components clean and free of lifecycle interfaces:

import { withHooks } from '@ngrx/signals';

export const JournalStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withComputed(/* ... */),
  withMethods((store) => ({
    loadEntries: rxMethod<void>(/* ... */),
  })),
  withHooks({
    onInit(store) {
      store.loadEntries();
    }
  })
);

Entity Management with @ngrx/signals/entities gives us withEntities(), setAllEntities, addEntity and more. For our accounts, this enables efficient lookups by code:

import { withEntities, setAllEntities, addEntity, entityConfig } from '@ngrx/signals/entities';
import { signalStore, type } from '@ngrx/signals';
import { Account } from './account.service';

const accountConfig = entityConfig({
  entity: type<Account>(),
  collection: 'accounts',
  selectId: (account) => account.code,
});

export const AccountStore = signalStore(
  { providedIn: 'root' },
  withEntities(accountConfig),
  withMethods((store) => ({
    loadAccounts(accounts: Account[]) {
      patchState(store, setAllEntities(accounts, accountConfig));
    },
    addAccount(account: Account) {
      patchState(store, addEntity(account, accountConfig));
    },
  }))
);

Events Plugin: Communication Between Stores

What happens when two stores need to talk to each other? For example, when you close a month, both the journal store and the ledger store need to stop allowing changes.

The Events Plugin (@ngrx/signals/events) solves this without making the stores depend on each other. Think of it as a communication system for your stores.

import { eventGroup } from '@ngrx/signals/events';

export const accountingEvents = eventGroup({
  source: 'Accounting',
  events: {
    entryPosted: (entryId: number, total: number) => ({ entryId, total }),
    periodClosed: (periodId: number) => ({ periodId }),
    periodReopened: (periodId: number) => ({ periodId }),
  },
});

Any store can react to these events using on and withReducer:

import { on, withReducer } from '@ngrx/signals/events';

export const JournalStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withReducer(
    on(accountingEvents.periodClosed, (state) => ({
      ...state,
      isReadOnly: true,
    })),
    on(accountingEvents.periodReopened, (state) => ({
      ...state,
      isReadOnly: false,
    })),
  )
);

This approach is great when multiple features need to stay updated without importing each other’s stores.

So far we covered SignalStore. Now let’s look at the classic NgRx Store and when it still makes sense.

Classic NgRx Store

The classic NgRx Store (actions, reducers, selectors, effects) is best for very complex data. SignalStore works for most features, but some situations need the full Redux pattern.

This approach is great when:

Many features share a large amount of connected data.
Your team needs Redux DevTools for advanced debugging.
You need a clear record of every state change.
Complex async workflows involve multiple services.

In our accounting app, managing monthly periods fits here. Opening and closing a month affects entries, the ledger and reports. Getting this wrong can cause data errors.

Entities with @ngrx/entity

For normalized data like the general ledger, @ngrx/entity provides createEntityAdapter with built-in CRUD:

import { createEntityAdapter, EntityState } from '@ngrx/entity';

export interface LedgerEntry {
  id: number;
  accountCode: string;
  debit: number;
  credit: number;
  periodId: number;
}

export const ledgerAdapter = createEntityAdapter<LedgerEntry>({
  selectId: (entry) => entry.id,
  sortComparer: (a, b) => a.id - b.id,
});

export interface LedgerState extends EntityState<LedgerEntry> {
  isLoading: boolean;
  selectedPeriodId: number | null;
}

export const initialState: LedgerState = ledgerAdapter.getInitialState({
  isLoading: false,
  selectedPeriodId: null,
});

The reducer uses adapter methods directly:

export const ledgerReducer = createReducer(
  initialState,
  on(LedgerActions.loadSuccess, (state, { entries }) =>
    ledgerAdapter.setAll(entries, { ...state, isLoading: false })
  ),
  on(LedgerActions.addEntry, (state, { entry }) =>
    ledgerAdapter.addOne(entry, state)
  ),
);

Actions and Effects for Period Management

For financial periods, each action is a named event with a clear meaning:

import { createActionGroup, props } from '@ngrx/store';

export const PeriodActions = createActionGroup({
  source: 'Financial Period',
  events: {
    'Open Period': props<{ periodId: number }>(),
    'Close Period': props<{ periodId: number }>(),
    'Period Closed': props<{ periodId: number; closedAt: string }>(),
    'Period Error': props<{ error: string }>(),
  },
});

Effects handle the async workflow:

import { createEffect, Actions, ofType } from '@ngrx/effects';
import { switchMap, map, catchError } from 'rxjs/operators';
import { of } from 'rxjs';

export const closePeriod$ = createEffect(
  (actions$ = inject(Actions), ledgerService = inject(LedgerService)) =>
    actions$.pipe(
      ofType(PeriodActions.closePeriod),
      switchMap(({ periodId }) =>
        ledgerService.closePeriod(periodId).pipe(
          map((closedAt) => PeriodActions.periodClosed({ periodId, closedAt })),
          catchError((err) => of(PeriodActions.periodError({ error: err.message })))
        )
      )
    ),
  { functional: true }
);

This is more code than SignalStore. And it should be. The benefit is having a clear history: every time a month is closed, it is recorded as an action with a timestamp. DevTools can show you exactly what happened.

Every tool has pros and cons. Classic NgRx is powerful but needs more code. Use it only for very complex features. For most other things, SignalStore is enough.

Now that we have seen all the options, how do you decide which one to use?

How to Choose the Right Approach

Now that we have seen all the options, how do you decide which one to use? As explained in the Decision Guide, there is no single answer for every case.

The best choice depends on how much you share your data and how complex it is.

Let’s apply those rules to our accounting app. The answer for each part is clear:

Search filter: Local Signals. Just a signal('') in the component.
Account list: Service with Signals. An AccountService shared between the form and the report.
Journal entries: SignalStore. A JournalStore to check balance rules.
Closing a month: Classic Store. Full Redux with actions, effects and DevTools.

A team building this app would use all four tools in the same project. This is completely fine. It is just about using the right tool for each job.

A great state management strategy is only complete if you can test it easily.

Testing Each Approach

Testing state management is simpler with Signals. Here is how each approach works:

Testing Local Signals

Signals are synchronous. Set a value, read it, assert:

it('filters entries by description', () => {
  const fixture = TestBed.createComponent(JournalListComponent);
  const component = fixture.componentInstance;
  component.entries.set([{ id: 1, date: '2026-01-01', description: 'Sale', total: 100 }]);
  component.searchTerm.set('sale');
  expect(component.filteredCount()).toBe(1);
});

Testing with Service with Signals

Test the service as an injectable:

it('adds an account to the chart of accounts', () => {
  const service = TestBed.inject(AccountService);
  service.addAccount({ code: '101', name: 'Cash', type: 'asset' });
  expect(service.accounts().length).toBe(1);
});

Testing with SignalStore

Inject the store like a service:

it('computes total debits correctly', () => {
  const store = TestBed.inject(JournalStore);
  store.addEntry({
    id: 1, date: '2026-01-01', description: 'Test', lines: [
      { accountCode: '101', debit: 100, credit: 0 },
      { accountCode: '401', debit: 0, credit: 100 },
    ]
  });
  expect(store.totalDebits()).toBe(100);
  expect(store.totalCredits()).toBe(100);
  expect(store.isBalanced()).toBeTrue();
});

Testing with Classic Store

Use provideMockStore and provideMockActions for isolated tests:

it('closes a period via reducer', () => {
  const result = periodReducer(initialState, PeriodActions.closePeriod({ periodId: 1 }));
  expect(result.periods.find(p => p.id === 1)?.status).toBe('closed');
});

The trend across all approaches is toward simpler tests. Signals let you assert synchronously without fakeAsync or async pipes.

With our testing strategy ready, here is a quick summary.

In modern Angular, I prefer to start simple and use local signals first. If things becomes complex, then I move data to a service only when I need to share it. Signals and services are now the standard choice for most of our data. I only pick complex libraries, like classic NgRx, for hard problems. For example, I use them if I need to track exactly how data changes over time.

But remember, state management is not about strict rules. It is simply about choosing the best tool for your project and your team.

Try Kendo UI for Angular

You can download a free 30-day trial to try out everythign we’ve explored in better detail.

Try Now

Open Challenge

Try these ideas to practice what we learned:

Add a Kendo UI Chart that shows the balance trend using computed() signals.
Use httpResource in the JournalStore to load data.

Try building one of these. You will see how each approach handles the task differently.

References

Decision Guide for Angular State Management: Signals, Services, SignalStore or NgRx?

2026-09-09T17:20:44Z

When and why should you use Signals, Services, SignalStore or NgRx to manage state in your Angular app?

This is the guide I wish I had before starting my first Angular project with state management.

Every developer needs to decide where data lives, how it changes and how different parts of the UI stay in sync. Get this wrong, and your app could become a mess of scattered data, broken UIs, and hours of debugging. Get it right, and your code stays clean, predictable and easy to change.

Most articles are outdated. They still push NgRx Store as the default answer or ignore Signals entirely. This guide is different. It covers the modern landscape: Signals, service stores, SignalStore and classic NgRx. It shows when each option makes sense and when to keep things simple.

We use examples from an accounting dashboard to make each concept concrete, so you can see how these patterns work in a real application.

Follow along: All the code for this dashboard is available on GitHub. Clone it and experiment while you read.

What Is State Management in Angular?

State management in practical terms means deciding how your app handles different types of data:

UI state – The search text a user types in a list. Only one component needs it.
Server state – Data fetched from an API, like a list of bank accounts.
Form state – User input before it is submitted.
Shared application state – Data many parts of the app need, like the current user or an open financial period.

Why does this matter more as Angular apps grow? More components will mean more async flows, more shared data and more chances for inconsistency. Without clear rules, one component might delete data another component needs, or two components might try to change the same data at once.

Consider concrete examples: authentication state controls what every component shows. Shopping cart state is shared across a product list, a cart view and a checkout form. Selected filters affect both a list and a detail view. Loading and error states need coordination across features. Each of these needs a different level of state management.

Why Angular State Management Feels Different Nowadays

Signals changed things by making reactivity part of Angular itself. Before Signals, you had to pick between BehaviorSubject in a service or use NgRx. Now you have signal(), computed() and effect() as built-in tools.

Modern Angular advice is less about libraries than before. In the past the answer was often “just use NgRx.” Now the community says: start simple and add complexity only when you need it. Most developers on Reddit and forums are practical. They use services with Signals or RxJS for shared state. They use NgRx only for large apps with complex async workflows.

This guide follows the current Angular and NgRx direction. Signals, service stores and SignalStore are the new normal.

The Tiered Approach to State Management

Think of state in three levels: local component state, shared feature state and global application state.

The best approach is to start small. Move to a bigger solution only when you need to share data or coordinate across components. Different parts of the same app can use different approaches.

Local Component State with Signals

When data lives in only one component, use signal(). Angular’s change detection works with Signals by default. Components only update when a signal changes or a new input arrives. This makes signal() a good fit for local state: fast, simple and direct.

In our accounting dashboard, a journal list with a search filter is a good example. The search text belongs to this component alone. The gives us a styled search input with no CSS work.

import { Component, signal, computed } from '@angular/core';
import { CurrencyPipe } from '@angular/common';
import { KENDO_TEXTBOX } from '@progress/kendo-angular-inputs';

interface JournalEntry {
  id: number;
  date: string;
  description: string;
  total: number;
}

@Component({
  selector: 'app-journal-list',
  standalone: true,
  imports: [CurrencyPipe, KENDO_TEXTBOX],
  template: `
    

    Showing {{ filteredCount() }} of {{ entries().length }} entries

    @for (entry of filteredEntries(); track entry.id) {
      
        {{ entry.date }} - {{ entry.description }}: {{ entry.total | currency }}
      
    } @empty {
      No entries found.
    }
  `
})
export class JournalListComponent {
  readonly entries = signal<JournalEntry[]>([
    { id: 1, date: '2026-07-01', description: 'Monthly Subscription Sale', total: 150.00 },
    { id: 2, date: '2026-07-02', description: 'Office Supplies', total: 45.50 },
    { id: 3, date: '2026-07-05', description: 'Consulting Service', total: 1200.00 }
  ]);
  readonly searchTerm = signal('');

  readonly filteredEntries = computed(() =>
    this.entries().filter(e =>
      e.description.toLowerCase().includes(this.searchTerm().toLowerCase())
    )
  );
  readonly filteredCount = computed(() => this.filteredEntries().length);
}

No NgRx imports, no actions, no reducers. Two signal() calls and a computed(). That is it.

Good for: Little code, easy to read, works with Angular change detection, fits local component state.

Not good for: When many unrelated components need the same data. A search filter in one component is fine. A list of accounts that the entry form and the ledger both need is not.

Shared Feature State with Services

When multiple components need the same data, use a service with Signals. This is the next step after local state.

The pattern is simple: the service keeps writable state in private fields. It exposes read-only Signals or Observables to the outside. Components call methods on the service instead of changing state directly. The @Service() decorator makes the service available app-wide and works with inject().

import { Service, computed, signal } from '@angular/core';
import { httpResource } from '@angular/common/http';

export interface Account {
  code: string;
  name: string;
  type: 'asset' | 'liability' | 'equity' | 'revenue' | 'expense';
}

@Service()
export class AccountService {
  private readonly _accountsRes = httpResource<Account[]>(() => '/api/accounts');
  private readonly _localAccounts = signal<Account[]>([
    { code: '101', name: 'Cash', type: 'asset' },
    { code: '102', name: 'Accounts Receivable', type: 'asset' },
    { code: '401', name: 'Sales Revenue', type: 'revenue' },
    { code: '501', name: 'Operating Expenses', type: 'expense' }
  ]);
  private readonly _selectedCode = signal<string | null>(null);

  readonly accounts = computed(() => [
    ...(this._accountsRes.value() ?? []),
    ...this._localAccounts()
  ]);
  readonly isLoading = this._accountsRes.isLoading;
  readonly selectedCode = this._selectedCode.asReadonly();

  readonly selectedAccount = computed(() =>
    this.accounts().find(a => a.code === this._selectedCode())
  );

  readonly revenueAccounts = computed(() =>
    this.accounts().filter(a => a.type === 'revenue')
  );

  selectAccount(code: string) {
    this._selectedCode.set(code);
  }

  addAccount(account: Account) {
    this._localAccounts.update(list => [...list, account]);
  }
}

Any component can inject AccountService and get the same data. The gives us search, keyboard navigation and disabled state with no extra code.

import { Component, inject } from '@angular/core';
import { KENDO_DROPDOWNLIST } from '@progress/kendo-angular-dropdowns';
import { AccountService } from '../account.service';

@Component({
  selector: 'app-journal-entry',
  standalone: true,
  imports: [KENDO_DROPDOWNLIST],
  template: `
    New Journal Entry

    Revenue Account:
    
    

    @if (selectedAccount(); as acct) {
      Selected: {{ acct.name }} - {{ acct.type }}
    }
  `
})
export class JournalEntryComponent {
  private readonly accountService = inject(AccountService);

  readonly revenueAccounts = this.accountService.revenueAccounts;
  readonly selectedAccount = this.accountService.selectedAccount;

  onSelectAccount(code: string) {
    if (code) {
      this.accountService.selectAccount(code);
    }
  }
}

Use this when: State is shared by 2 to 10 components in the same feature. Examples: chart of accounts, user settings for a module or filters shared between a list and a detail view.

Move up when: You need strict rules, computed state with complex logic or DevTools for debugging. That is when SignalStore helps.

Signals vs. BehaviorSubject for Service Stores

Which one should you use, signal() or BehaviorSubject?

Concern	`signal()`	`BehaviorSubject`
Read current value	`items()`	`items$.value`
Derived values	`computed()`	`pipe(map(...))`
Template syntax	`{{ items() }}`	`{{ items$ \| async }}`
Change detection	Automatic	Needs `OnPush` or `async` pipe
Async composition	Needs `rxMethod`	`switchMap`, `combineLatest`

Use RxJS when you need stream features like debounce, cancellation or WebSocket events. For most synchronous state, Signals are simpler.

For new code, Signals are the better default. They are simpler, synchronous and work well with Angular’s change detection.

NgRx SignalStore and SignalState

SignalStore gives you structure without the extra code of classic NgRx. It is the recommended state management for Angular apps (NgRx team, v19+).

A simple service works for basic state. But as your feature grows, you want computed values, loading states and a consistent way to update data. Without these, different team members might use different patterns.

SignalStore is between a service and a full Redux store. Think of it as a service with clear rules.

import { signalStore, withState, withComputed, withMethods, patchState, withHooks } from '@ngrx/signals';
import { computed, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { tapResponse } from '@ngrx/operators';
import { pipe, switchMap, tap } from 'rxjs';

interface JournalLine {
  accountCode: string;
  debit: number;
  credit: number;
}

interface JournalEntry {
  id: number;
  date: string;
  description: string;
  lines: JournalLine[];
}

type JournalState = {
  entries: JournalEntry[];
  isLoading: boolean;
};

const initialState: JournalState = {
  entries: [
    {
      id: 1,
      date: '2026-07-01',
      description: 'Initial Opening Balance',
      lines: [
        { accountCode: '101', debit: 5000, credit: 0 },
        { accountCode: '301', debit: 0, credit: 5000 }
      ]
    },
    {
      id: 2,
      date: '2026-07-08',
      description: 'Service Revenue Recognition',
      lines: [
        { accountCode: '102', debit: 1200, credit: 0 },
        { accountCode: '401', debit: 0, credit: 1200 }
      ]
    }
  ],
  isLoading: false
};

function totalDebits(entries: JournalEntry[]): number {
  return entries.reduce((sum, e) =>
    sum + e.lines.reduce((s, l) => s + l.debit, 0), 0);
}

function totalCredits(entries: JournalEntry[]): number {
  return entries.reduce((sum, e) =>
    sum + e.lines.reduce((s, l) => s + l.credit, 0), 0);
}

export const JournalStore = signalStore(
  { providedIn: 'root' },

  withState(initialState),

  withComputed((store) => ({
    entryCount: computed(() => store.entries().length),
    totalDebits: computed(() => totalDebits(store.entries())),
    totalCredits: computed(() => totalCredits(store.entries())),
    isBalanced: computed(() => totalDebits(store.entries()) === totalCredits(store.entries())),
  })),

  withMethods((store, http = inject(HttpClient)) => ({
    loadEntries: rxMethod<void>(
      pipe(
        tap(() => patchState(store, { isLoading: true })),
        switchMap(() =>
          http.get<JournalEntry[]>('/api/journal-entries').pipe(
            tapResponse({
              next: (entries) => patchState(store, { entries, isLoading: false }),
              error: () => patchState(store, { isLoading: false }),
            })
          )
        )
      )
    ),

    addEntry(entry: JournalEntry) {
      patchState(store, { entries: [...store.entries(), entry] });
    },
  })),

  withHooks({
    onInit(store) {
      store.loadEntries();
    },
  })
);

SignalState is the lighter option. It has state and computed values but no methods or hooks. Use it when you want signal-based state in a service without the full store structure.

SignalStore also supports entity management with withEntities() for CRUD operations and the Events Plugin for cross-store communication. These features make SignalStore a good fit for features that need structure but would be too complex with classic NgRx.

Classic NgRx Store

The classic NgRx Store (actions, reducers, selectors, effects) is best for very complex data. Use it when you need a clear history of changes and strict patterns, even if it means more code.

This approach is useful when:

Many features share a lot of connected data.
Your team needs Redux DevTools for debugging.
You need a record of every state change.
You have complex async workflows with multiple services.

In the accounting dashboard, managing monthly periods fits here. Opening and closing a month affects entries, the ledger and reports.

createActionGroup and props come from @ngrx/store:

import { createActionGroup, props } from '@ngrx/store';

export const PeriodActions = createActionGroup({
  source: 'Financial Period',
  events: {
    'Open Period': props<{ periodId: number }>(),
    'Close Period': props<{ periodId: number }>(),
    'Period Closed': props<{ periodId: number; closedAt: string }>(),
    'Period Error': props<{ error: string }>(),
  },
});

Effects handle the async workflow using createEffect, Actions and ofType:

import { createEffect, Actions, ofType } from '@ngrx/effects';
import { switchMap, map, catchError } from 'rxjs/operators';
import { of } from 'rxjs';

export const closePeriod$ = createEffect(
  (actions$ = inject(Actions), ledgerService = inject(LedgerService)) =>
    actions$.pipe(
      ofType(PeriodActions.closePeriod),
      switchMap(({ periodId }) =>
        ledgerService.closePeriod(periodId).pipe(
          map((closedAt) => PeriodActions.periodClosed({ periodId, closedAt })),
          catchError((err) => of(PeriodActions.periodError({ error: err.message })))
        )
      )
    ),
  { functional: true }
);

This is more code than SignalStore. The benefit is a clear history. Every time a month is closed, it is recorded as an action with a timestamp. Redux DevTools shows exactly what happened.

Use classic NgRx only for complex coordination problems. SignalStore is enough for most features. NgRx gives you predictability, devtools and clear data flow. But it has more code and a harder learning curve. NgRx is powerful, but that’s not always needed.

Other Libraries and Why They Rank Lower in Modern Guidance

Akita and NGXS still appear in older comparison articles. But Akita is now deprecated and should not be used for new projects. NGXS is still maintained but its community has not grown like NgRx, and it has less adoption in the Angular ecosystem.

For most projects today, the choice is between a Signal-based service, SignalStore and classic NgRx Store. These options have the widest community support, more shared knowledge and best alignment with Angular’s future direction.

How to Choose the Right State Strategy

There is no single answer that works for every case. Ask these questions:

Question	Best Fit
Does this data belong to one component only?	Local Signals
Is this data shared across 2-10 components?	Service with Signals
Do you want structure and rules but not full Redux?	SignalStore
Is this global data used across many features?	SignalStore or Classic Store
Do you need Redux DevTools and a clear history?	Classic Store
Is your data complex with many relationships?	Classic Store + @ngrx/entity

Apply this framework to real examples:

Local modal state – A dialog open/close flag. Use a signal(false) in the component.
Feature-level product filters – Filters shared between a product list and a detail view. Use a service with Signals.
Global auth and entity cache – User session and a cache of business data. Classic NgRx Store gives you the predictability and tooling this level needs.

Different parts of the same app can use different approaches. A dashboard might use local Signals for UI state, a service for feature state and classic NgRx for global coordination. This is not wrong. It is about using the right tool for each job.

State Management in Real Angular Architectures

The best state strategy depends on more than just data scope. The size of your architecture and how your team works together often matter more than library popularity.

Enterprise apps – Large teams benefit from the structure of SignalStore or classic NgRx. Consistent patterns make it easier for new team members to learn the codebase.
Design systems – Component libraries should not use global state. Use inputs, outputs and local Signals. Let the app that uses the library decide on shared state.
Admin dashboards –Many widgets sharing data makes service stores and SignalStore a good fit. Each widget can use local Signals for its own UI state while reading shared data from a store.
Micro-frontends and Nx-based architectures – Each micro-app should own its own state. Classic NgRx at the shell level handles cross-app coordination. SignalStore inside each micro-app keeps feature code clean.

Signals, RxJS and NgRx: How They Work Together

You do not have to choose only one. The modern Angular approach uses all three together.

Signals for local and view-model state. Use signals in components, computed for derived state and read-only signals from services. This covers most day-to-day state needs.
RxJS for async and event streams. HTTP requests, WebSocket connections, debounced input and complex stream transformations are still good use cases for RxJS. Use rxMethod to connect RxJS with SignalStore.
NgRx when you need structure or tooling. Classic NgRx Store and SignalStore give you conventions, DevTools and predictable data flow for the features that need them most.

These tools work together. A component can use a Signal for local state, read from a SignalStore for feature data and dispatch classic NgRx actions for global coordination. The choice is practical, not about following rules.

Key Takeaways and Next Steps

Start with the simplest solution that works. Use signal() for local data. Move to a service when you need to share data. Use libraries only when the logic gets complex.
Signals and services are the new default. Most data does not need a complex store.
Use classic NgRx only for complex problems. If you need a clear history of changes or DevTools, the extra code is worth it.
Mix different tools in the same app. Each part of the app can use the approach that fits best.

Modern Angular state management is about choosing what fits, not about following strict rules. The right answer depends on your project size, team and needs.

To learn more, check Angular Signals, the NgRx SignalStore guide, ComponentStore migration, RxJS and architecture guides for large Angular projects.

Create a Kendo UI for Angular Dinner Picker

2026-08-20T17:09:35Z

Sick of picking where to go for dinner? Build this little Angular app to help you choose!

Do you ever argue about where to eat? If you’re like me, you can’t think of places half the time, and you just wish someone would pick for you. Well, here you go!

TL;DR

This app will create a random dinner picker from JSON data in Angular using Progress Kendo UI. You can choose from Takeout or Dine-in.

Setup

Create a new Angular app:

ng new angular-dinner-picker

Get a Kendo UI License

Download the actual key, as you will need it later for deployment.

Install Kendo UI Licensing

npm i -S @progress/kendo-licensing

Then run:

npx kendo-ui-license activate

This will set up Kendo UI on your local machine for this project. Make sure you have a working license at this point, and to follow the correct setup.

Install Packages

ng add @progress/kendo-angular-buttons
ng add @progress/kendo-angular-dropdowns
ng add @progress/kendo-angular-layout

npm i -S npm install @angular/forms @progress/kendo-svg-icons @progress/kendo-theme-default

You may need to also install @angular/localize.

Install Tailwind

Make sure Angular is configured for Tailwind. Follow the Tailwind Guide.

Configure Styles

Make sure your styles are shown in styles.css correctly.

@import '@progress/kendo-theme-default/dist/default-main.css';
@import 'tailwindcss';

Picker Component

Generate a new picker component.

ng g c picker

Model

Create a model at picker.model.ts.

export type RestaurantMode = 'dine-in' | 'takeout';

export type Restaurant = {
  id: number;
  name: string;
  cuisine: string;
  mode: RestaurantMode;
};

export type RestaurantModeFilter = 'all' | RestaurantMode;

Data

You can declare your data in the restaurants.ts. You could obviously get more sophisticated and import data from a database if you like.

import { Restaurant } from "./picker.model";

export const restaurants: Restaurant[] = [
  {
    "id": 1,
    "name": "Monjunis",
    "cuisine": "Italian",
    "mode": "dine-in"
  },
  {
    "id": 2,
    "name": "Strawn's Eat Shop",
    "cuisine": "Southern Diner",
    "mode": "dine-in"
  },
  {
    "id": 3,
    "name": "Country Tavern",
    "cuisine": "BBQ",
    "mode": "dine-in"
  },
  
  ...
  
];

I used my city’s info so I can actually use the app! You can customize this and deploy it separately for different situations or cities!

Picker Class

Create the picker classes at picker.ts.

import { ChangeDetectionStrategy, Component } from '@angular/core';
import { FormsModule } from '@angular/forms';

import { ButtonsModule } from '@progress/kendo-angular-buttons';
import { DropDownsModule } from '@progress/kendo-angular-dropdowns';

import { restaurants } from './restaurants';
import { Restaurant, RestaurantModeFilter } from './picker.model';

type ModeOption = {
  label: string;
  value: RestaurantModeFilter;
};

@Component({
  selector: 'app-picker',
  standalone: true,
  imports: [
    FormsModule,
    ButtonsModule,
    DropDownsModule
  ],
  templateUrl: './picker.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class Picker {
  readonly restaurants = restaurants;

  readonly modeOptions: ModeOption[] = [
    {
      label: 'Any',
      value: 'all'
    },
    {
      label: 'Dine-in',
      value: 'dine-in'
    },
    {
      label: 'Takeout',
      value: 'takeout'
    }
  ];

  selectedMode: RestaurantModeFilter = 'all';
  selectedRestaurant: Restaurant | null = null;

  get filteredRestaurants(): Restaurant[] {
    if (this.selectedMode === 'all') {
      return this.restaurants;
    }

    return this.restaurants.filter((restaurant) => restaurant.mode === this.selectedMode);
  }

  pickRestaurant(): void {
    const choices = this.filteredRestaurants;

    if (choices.length === 0) {
      this.selectedRestaurant = null;
      return;
    }

    const pickableChoices =
      this.selectedRestaurant && choices.length > 1
        ? choices.filter((restaurant) => restaurant.id !== this.selectedRestaurant?.id)
        : choices;

    const index = Math.floor(Math.random() * pickableChoices.length);

    this.selectedRestaurant = pickableChoices[index];
  }
}

Pick the restaurant with pickResaturant() function choosing a random JSON entry from the filtered results.
We have any, dine-in and takeout.
We will use the filtered results in the html template from filteredResautrants().

Picker Template

<main
  class="grid min-h-screen place-items-center bg-[radial-gradient(circle_at_top,rgba(255,255,255,0.95),rgba(255,255,255,0)_28%),linear-gradient(180deg,#f7efe7_0%,#eef2f7_100%)] p-4 sm:p-6">
  <section
    class="w-full max-w-sm rounded-4xl border border-slate-300/40 bg-white/92 px-6 py-7 shadow-[0_24px_60px_rgba(15,23,42,0.12)] backdrop-blur-[14px] sm:px-8 sm:py-8">
    <header class="space-y-3 text-center">
      <h1 class="m-0 text-[2.05rem] font-semibold leading-[0.98] tracking-tight text-slate-800 sm:text-[2.3rem]">
        Restaurant Picker
      </h1>

      <p class="mx-auto max-w-64 text-[1rem] leading-7 text-slate-500">
        Pick where to eat without thinking about it.
      </p>
    </header>

    <div class="my-6 h-px bg-slate-200/80"></div>

    <div class="space-y-6">
      <div class="space-y-3 text-center">
        <label for="mode" class="block text-[1.15rem] font-semibold leading-tight text-slate-800">
          What kind?
        </label>

        <kendo-dropdownlist id="mode" class="w-full text-left" [data]="modeOptions" textField="label" valueField="value"
          [valuePrimitive]="true" [(ngModel)]="selectedMode" />
      </div>

      <button kendoButton class="min-h-14 w-full text-base font-semibold" themeColor="primary" size="large"
        rounded="large" [disabled]="filteredRestaurants.length === 0" (click)="pickRestaurant()">
        Pick Restaurant
      </button>

      @if (selectedRestaurant) {
      <section
        class="rounded-[1.75rem] border border-rose-200/80 bg-[linear-gradient(135deg,rgba(255,241,242,0.92),rgba(255,255,255,0.98))] px-6 py-6 shadow-[inset_0_1px_0_rgba(255,255,255,0.7)]"
        aria-live="polite">
        <div class="grid justify-items-center gap-4 text-center">
          <p class="m-0 text-[0.78rem] font-bold uppercase tracking-[0.2em] text-rose-700">Tonight's pick

          
            {{ selectedRestaurant.name }}
          

          
            
              {{ selectedRestaurant.cuisine }}
            

            
              {{ selectedRestaurant.mode === 'dine-in' ? 'Dine-in' : 'Takeout' }}
            
          
        
      
      } @else {
      
        @if (filteredRestaurants.length === 0) {
        No restaurants found for this option.
        } @else {
        Click the button to pick a restaurant.
        }
      
      }

      
        {{ filteredRestaurants.length }}
        restaurant{{ filteredRestaurants.length === 1 ? '' : 's' }} available
      </p>
    </div>
  </section>
</main>

Here’s what’s going on above:

When we run pickRestaurant(), the app displays the filtered items as a signal.
The kendo-dropdownlist component uses data field for options with label and value matching the drop down.
We just add kendoButton to our button component to get the look we want. We can use Tailwind with the look!

And it’s that simple!

Repo: GitHub
Demo: Vercel Serverless

You can try all of this yourself with the Kendo UI for Angular trial, free for 30 days.

Try Now

Biometric Authentication in Angular Using Auth0

2026-08-03T12:17:02Z

Learn to build an authentication system that supports passkeys using the Auth0 SDK within an Angular application.

Passkeys combine both possession and inherence factors (hardware and biometrics) in a single authentication method. Basically, passkeys are public key cryptographic credentials that conform to FIDO protocols that provide strong, phishing-resistant authentication unlike regular password-based systems. They also sync across your devices, so you can easily sign in from your phone, laptop or tablet.

Building an authentication system or updating an existing one to support passkeys takes a lot of time. As a developer, you need to understand complex specs and get everything right. Identity providers like Auth0 provide an easy-to-use suite of tools that allows you to build great authentication solutions that support the latest password-based to passwordless authentication methods without writing complicated code.

The goal of this article is to show how easy it is to build an authentication system that supports passkeys using the Auth0 SDK within an Angular application.

Prerequisites

To follow along with this guide, you need to be familiar with the Angular framework, have integrated or consumed RESTful APIs, and have a basic understanding of how authentication and authorization work.

Project Setup

Let’s create an Angular project by running the following command:

ng new ng-webauthn

Follow the prompts and accept all the defaults. This creates an Angular project in a folder called ng-webauthn.

We’ll install our dependencies after we set up Auth0. Open your terminal and start your application by running the following command:

npm run start

One key thing to notice here is that our application runs on localhost:4200 by default. We’ll need this information when configuring our application on the Auth0 dashboard.

Setting Up Auth0

Let’s now set up Auth0 and integrate it into our application.

Visit the Auth0 onboarding page to create an account. On the dashboard click on Applications > Create Application.

Since we’re integrating with Angular, we created a single-page application on the Auth0 dashboard with an arbitrary name: “test-app.” You can choose your preferred name.

Next, let’s click on the settings tab to configure our application.

As seen above, the Callback URLs and Logout URLs input fields accept a comma-separated list of candidate URLs that we can redirect the user to after they log in, sign up or sign out, respectively.

To understand why we need this, we need to understand the default recommended authentication method when using Auth0, hosted or universal login.

In the universal login flow, when a user wants to authenticate in an application (e.g., our Angular SPA), they are redirected to a page that is hosted and managed by Auth0 servers. This page is only accessible when a valid candidate redirect URL is provided. If authentication is successful, the user is redirected back to the Angular application.

Now, let’s install the dependencies we’ll need. From the root of your Angular project, open your terminal and run the following command:

npm install @auth0/auth0-angular@2.x

Next, let’s take some code from the Quick Start section to initialize our application. We’ll start by updating the contents of the app.config.ts file to look like this:

import { ApplicationConfig, provideZoneChangeDetection } from '@angular/core';
import { provideRouter } from '@angular/router';

import { routes } from './app.routes';
import { provideAuth0 } from '@auth0/auth0-angular';

export const appConfig: ApplicationConfig = {
  providers: [provideZoneChangeDetection({ eventCoalescing: true }), provideRouter(routes), provideAuth0({
    domain: "YOUR-DOMAIN",
    clientId: "YOUR-CLIENT-ID",
  }),]
};

The provideAuth0 function accepts an object representing the configuration for our Auth0 application, which includes our domain and client ID.

Our domain is a unique URL created for us by Auth0 when we created an account. The clientID is a unique identifier for the application. We can get these credentials in the Settings tab, as shown below.

The provideAuth0 function internally exposes a service called AuthService, which will be available globally to all the other components in our application tree.

Next, update your app.component.ts file to look like this:

import { CommonModule } from '@angular/common';
import { Component, inject } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-root',
  template: `
    @if (auth.isLoading$ | async) {
      Loading...
    } @else {
      @if ((auth.isAuthenticated$ | async) && (auth.user$ | async); as user) {
        
          Profile
          @if (user.picture) {
            
          }
          
            Name
            {{ user.name || user.nickname || '--' }}
            Email
            {{ user.email || '--' }}
            @if (user.email_verified !== undefined) {
              Email verified
              {{ user.email_verified ? 'Yes' : 'No' }}
            }
            @if (user.sub) {
              User ID
              {{ user.sub }}
            }
          
          
        
      } @else {
        @if (auth.error$ | async; as error) {
          Error: {{ error.message }}
        }
        
        
      }
    }
  `,
  styles: [],
  providers: [],
  imports: [CommonModule],
})
export class AppComponent {
  auth = inject(AuthService);
}

To simplify our application, we won’t be using any routes. All the code we need will be contained in the root app component.

We start by injecting the AuthService. We also imported the CommonModule to use the async pipe, since most of the properties of AuthService are observables.

In the template, we render different pieces of UI based on the authentication state:

When loading, we display a loading message.
When the user is authenticated, we display the user’s details with a button to log out.
If there is an error from the authentication flow, we display it on the screen.
Otherwise, the user is presented with two buttons to sign up or log in.

Notice that when we trigger loginWithRedirect and logout, we additionally pass a redirect_url with a valid value as defined in the Callback URLs input field earlier when we configured our Auth0 app.

To see the running application, open your terminal and run the following command:

npm run start

Adding Support for Passkeys

In our current application, we can sign up and log in with email and password and use SSO, but passkeys are not yet supported. Thankfully, with Auth0 and its zero-code configuration, we no longer need to change any code to support passkeys. We just need to make a few tweaks in our dashboard to get it working.

Head over to the Database Connections section and choose the database connection associated with the app.

A database connection is an abstracted term in Auth0. It represents the storage layer (database) that stores all user credentials and the configuration options for how we want to identify and authenticate users. By default, a database connection is automatically created when we create an Auth0 account.

In the Authentication Methods tab, click on Passkeys and enable passkeys.

Passkey support may not be enabled immediately. Instead, you may be presented with a popup showing a checklist of tasks you need to fulfill to make it work, as shown below.

In our case, the only pending item is to enable identifier-first login flow. If you are wondering what this means, Auth0 has a concept called Authentication Profiles, which allow us to configure the universal login page’s flow when a user wants to authenticate.

In Authentication > Authentication Profile, proceed to enable identifier-first login and click Save, as shown below.

In the identifier-first authentication profile, during sign-up or login, the user is first prompted for their identifier (typically their email). Then, based on the authentication methods supported by the identifier, a decision is made whether the user needs to provide a password or proceed to use or create a passkey.

As of the time of writing, identifier-first authentication is the typical way we authenticate when signing in with Google or on Apple’s App Store Connect, just to name a few examples. We typically provide our email first, and then the system decides whether we need to provide a password or use another method to authenticate.

Now that we have all the items on the checklist sorted, we can go ahead to enable passkey support. After clicking Save, notice that we have passkeys enabled.

Using Passkeys in Our App

We now have all the configurations needed to support passkeys. Let’s head back and start our Angular application by running npm run start.

Notice that, now during sign-up, we are first prompted to enter our email. The form gives us an opportunity to create a passkey or continue with a password.

If the user agrees to create a passkey, it triggers the WebAuthn registration ceremony, which is the sequence of steps required to create a passkey, and this is handled by Auth0 automatically. To give a sneak peek of what happens during the process, we’ll also briefly discuss the three entities and the two FIDO protocols that make passkeys possible.

The server (relying party) in the diagram above represents the server-side application that wants to enroll users for passkeys. It communicates with the webpage running on the client’s device using the Web Authentication protocol over HTTP to send information about itself and the configuration required when creating or authenticating with passkeys. The client communicates with the authenticator following the low-level Client to Authenticator Protocol (CTAP) over USB or Bluetooth for roaming authenticators, or directly for platform authenticators.

Authenticators are hardware devices that create and persist the public key credentials representing the passkeys. Platform authenticators are authenticators built into a device (e.g., a MacBook’s Touch ID or an iPhone’s Face ID), while roaming authenticators are external to the user’s device (e.g., a YubiKey). It is important to note that the interactions between these three entities varies depending on whether the user is creating passkeys (WebAuthn registration ceremony) or using passkeys to log in (WebAuthn authentication ceremony).

The following steps are involved during registration:

Client clicks “Continue with passkey.”
Webpage requests credential creation options from Auth0 servers over HTTP.
Auth0 servers respond with credential creation options.
Client connects to authenticator by calling the window.navigator.credentials.create() method with the provided options.
The user is presented with a modal to verify their identity.
User verifies their identity using biometrics (Face ID, Touch ID, etc.), and the passkey is created.
The authenticator returns an attestation to the client, which then sends it to the server for verification.
If verification succeeds, a session is created for the user.

During login, notice that we get autocomplete when entering the email. When we click the “Continue with passkeys” button to log in with passkeys and choose a passkey, we verify with a biometric gesture and we’re logged in.
We need to note the following points that made this good UX possible, from both the configuration side on our Auth0 dashboard and the technical side of how passkeys work with the concept of resident keys.

First, the autocomplete and the “Continue with passkey” button are available because of the configuration we made on our dashboard earlier. This shows how simple it is to customize the authentication flow with passkeys with just a few tweaks.

Note that “webauthn” must be the entry in the autocomplete attribute, as shown above, to work correctly across different browsers.

Secondly, the autocomplete on the email input field is possible because of the autocomplete="webauthn" attribute on the input element, which allows the page to load any resident keys available for that domain.

Resident Keys

During sign-up in the last section, when we created the passkey, Auth0 favored the client-side discoverable passkeys option (also known as resident keys). Resident keys are passkeys whose availability can be detected on the client side without asking the server for any information about which passkeys are available.

This addresses the problem of using server-side discoverable keys, which require the user to provide an identifier to enable the server to determine which passkeys they own. This method placed too much dependence on the server and hurt the login experience. With client-side discoverable keys, the user is able to log in just by clicking, without having to provide any information.

Tying it all together, let’s briefly describe how the login flow works:

Client visits the page. As soon as the page mounts, it requests authentication options from the server, and the authentication process is triggered. This loads the resident keys and enables autofill for passkeys.
Client clicks the passkey autocomplete option on the input field from the dropdown. window.navigator.credentials.get() is called with the options to connect to the authenticator.
User is prompted to verify using their biometrics. If it succeeds, an assertion response is generated and sent back to the client, which then sends it to the server for verification.
If the assertion response is verified, a session is created for the user.

Best Practices When Using Passkeys

Since passkeys created are scoped to a particular domain (also known as the relying party ID), when using passkeys in production we should try to always use a custom domain we own instead of the default domain Auth0 provides. Also note that changing domains will invalidate existing passkeys that are not scoped to the new domain.
For users who do not have a device that supports passkeys, it is important to support other authentication methods, such as email and password, as we already have in our project.
With progressive enrollment, which is enabled by default, users who are signed into our application with other methods will be intermittently prompted to enroll their devices and create passkeys.
Also, passkeys should only be enabled on one database connection on our Auth0 dashboard. This keeps all passkeys stored in a central storage location to help maintain consistency and avoid fragmentation.

Conclusion

Passkeys are being adopted by major companies like Amazon, Google, Apple, GitHub and Microsoft for security and ease of use. This guide provides an easy way to use providers like Auth0 to build robust authentication systems, using passkeys. Hopefully, this will serve as a reference point when you need to use passkeys in your future projects.

What Enterprise Teams Actually Look for in an Angular UI Library

2026-07-28T12:57:08Z

See what mattered when a real enterprise team was exploring which Angular component library to use, and what keeps them using Kendo UI.

Editor’s note: To respect our customer’s privacy, some identifying details have been generalized while preserving technical insights and direct quotes from our conversation.

TL;DR What Enterprises Need in an Angular Library

Based on a conversation with an IT System Developer at an enterprise financial organization, five factors consistently influenced the team’s evaluation of an Angular UI library:

An enterprise-grade Angular data grid
A complete Angular component library
Documentation and API examples that keep developers productive
Reusable theming across multiple applications
Predictable upgrades and long-term stability

While this conversation focused on Progress Kendo UI for Angular, these evaluation principles apply broadly to enterprise Angular applications.

Intro

When Angular UI libraries are compared, the conversation usually starts with feature lists, demos and the latest capabilities. But that’s rarely where enterprise teams stop.

During a recent conversation with an IT System Developer at an enterprise financial organization, we noticed something interesting. The discussion kept returning to the same themes: an enterprise-grade grid, a complete Angular component library, documentation developers can rely on, reusable theming and predictable upgrades.

None of those topics are particularly flashy. Together, they reveal what experienced engineering teams often optimize for: not just what an Angular UI library can do today, but how it supports development over the years that follow.

The Grid Is Key, But the Whole Ecosystem Matters

For this team, the Angular DataGrid wasn’t simply another component. It was at the center of many of their internal business applications and the first thing they evaluated.

“The demand is to have a very good and advanced grid, because we use grids all over in our web applications, so that’s the primary choice.”

Their applications depend on complex data workflows, including master-detail views, grouping, sorting, and cell and row editing. Having those capabilities available out of the box saved the team from building and maintaining them themselves.

At first glance, it would be easy to conclude that this was simply a grid decision. But it wasn’t.

“We chose Kendo UI because of the Grid, but also because we use a wide variety of components.”

Those components include buttons, text inputs, checkboxes, labels, dropdowns, combo boxes, forms, dialogs, charts and more. Rather than combining multiple libraries, the team chose a single Angular component library that covered the majority of their application needs.

Cost was part of the conversation, too.

“We had to weigh the subscription cost, of course, but I think it’s very professional, a portfolio of components, and it fits our needs very, very well.”

The Grid may have started the evaluation, but the broader ecosystem is what kept coming up throughout the conversation.

Learn more: Explore the Kendo UI for Angular Data Grid.

Documentation Goes Beyond Support to Productivity

Documentation turned out to be just as important as the components themselves.

“I almost never need to write to you [Progress]. Your support site and your specification site are doing it for me. Usually, I find my answers in the API documentation and by looking at your examples.”

Good documentation doesn’t replace support. It means developers rarely need support.

For this team, comprehensive API references and practical examples meant fewer interruptions, fewer support requests and less time searching for answers. Documentation wasn’t something separate from the product. It was part of the development experience.

Explore the documentation: Browse the Kendo UI for Angular docs & demos.

Consistency Matters More as Your Application Portfolio Grows

The value of theming changes when you’re maintaining multiple applications instead of just one. Rather than creating a new theme for every project, this team maintains a single reusable theme across its Angular applications.

“We do the same theme for all our web applications. So when we have done one, we can just copy the files to the next. And that’s to eliminate work.”

That approach keeps branding consistent while eliminating repetitive work.

The team also shared a practical example from their upgrade experience.

“Earlier, trying to cope with the changes in the style sheets could take some time. We are using the new theme editor for that, so it’s OK now.”

That’s a subtle but important distinction. Progress ThemeBuilder isn’t only about creating themes. It’s about making those themes easier to maintain over time.

Explore ThemeBuilder: Learn how to create and maintain reusable themes across Angular applications.

For Enterprise Teams, Predictability Is a Must-Have

Business-critical applications need to keep working through framework upgrades, dependency updates and ongoing maintenance. When we asked about upgrades, the discussion wasn’t about the newest features. It was about confidence.

“In relation to major release updates, it’s very well tested.”

“There can be some minor changes we have to do, but most backwards compatibility is good.”

No software upgrade is completely frictionless. For this team, predictable releases and good backward compatibility mattered because they made upgrades easier to manage. Sometimes the best release isn’t the one with the longest list of new features. It’s the one that lets developers keep moving.

Enterprise Teams Evaluate Platforms, Not Features

Feature lists are easy to compare, but long-term developer experience isn’t. One thing became clear as the conversation unfolded: it never stayed on a single capability for very long.

The Angular Data Grid solved one set of challenges.
Documentation kept developers productive.
Reusable theming reduced repetitive work across applications.
Stable releases made upgrades easier to manage.

None of those capabilities tells the whole story on its own.

Together, they suggest a different way of evaluating an Angular UI library: it’s easy to compare individual components, but it’s much harder, and often much more valuable, to evaluate how an ecosystem supports a team over the lifetime of an application.

That isn’t a phrase the developer used during our conversation. It’s the conclusion we came away with after listening to what mattered most.

If there’s one lesson other engineering teams can take from this conversation, it’s this:

Don’t just compare features. Compare how much engineering work a platform helps your team avoid tomorrow, next year and several years from now.

Try Kendo UI for Angular

The 10 Best Angular UI Grids

2026-07-20T17:36:42Z

TL;DR What’s the best Angular grid? For most enterprise Angular applications, Progress Kendo UI for Angular Grid is the strongest all-around choice. It combines high-performance data handling, virtualization, AI-assisted features, theming tools and integration with a broader UI component library.

On the internet, data is everything. Since the beginning of the web, showing lists has been the standard way to present information.

We started with simple HTML tables, but over the years, displaying data has become much more than just creating a list. Today, it involves complex interactions and the need for data to travel smoothly between many different components.

In any application, when a list is slow or difficult to use, it is not just a small problem. It is a major blocker. A grid that cannot handle real-time updates does more than frustrate users; it can cause serious business problems and angry users.

In 2026, choosing a grid component is a business decision, not just a technical one. Modern grids must handle thousands of rows, update every second, export data for reports, integrate with AI agents and look good on all screens. You need all of this without making your developers write thousands of lines of custom code.

To understand why this matters, the best way is with a real-world scenario.

The Scenario

You have been hired by a startup to build a trading dashboard with real-time market data, thousands of rows updating constantly, complex filters, frozen columns, and one-click export to Excel. The CTO wants a working minimum viable product (MVP) ASAP to compete with time-to-market.

In this situation, your grid is the most important part of the product. Every second of lag or every missing feature is a threat to your deadline. If the grid fails during a demo with investors, the rest of the app does not matter.

Consider: Many teams waste half their time building basic features like virtual scrolling. However, the biggest problem is communication. A grid must talk to the rest of your app. When you mix different libraries for your grid and your buttons, making them work together is a nightmare.

Let’s look at the best options available today and see how they can help you and your team.

1. Kendo UI for Angular Grid

No matter how small, large or complex your data is, the Progress Kendo UI for Angular Grid is the best choice when you need a grid that meets every requirement. It is built to handle everything from simple lists to massive enterprise datasets with real-time updates.

This component is not just powerful; it is also easy to customize. Because it is part of a complete suite, the grid integrates perfectly with other Kendo UI components like charts and dropdowns. This solves the “headache” of making different parts of your app talk to each other.

I have watched how building grids has evolved over many years. Based on that experience, here are the reasons why Kendo UI is the right choice for professional projects:

Why Kendo UI Grid is the Right Choice for Professional Projects

Smart Grid and AI Assistant: This is where Kendo UI really changes the game. It is not just a table; it is a “smart” component. With the AI Smart Box, users can use natural language to search, filter and manage data. Instead of looking for exact keywords, the Semantic Search understands what the user actually wants.
AI-powered insights: The grid can highlight important rows and provide smart data summaries automatically. This helps users find the most important information without manual work.
Virtual scrolling and row virtualization: The grid handles hundreds of thousands of rows easily. Scrolling is fast even when data changes constantly, which is essential for trading.
Real-time data binding: It works excellently with live data streams. You can update the grid without refreshing the entire dataset, keeping the UI fast.
Frozen columns and column management: You can pin important columns while users scroll horizontally through large datasets.
Built-in Excel and PDF export: This is a native feature, not a third-party plugin. It keeps your styles, filters and column settings.
MCP Server: The Kendo UI MCP Server helps AI tools (like Cursor or Copilot) write better code by providing the correct patterns for the component.
ThemeBuilder: You can import Figma design tokens to make the grid match your brand perfectly without writing complex CSS.
Expert support: If you have a problem during a busy week, you can get help directly from the engineers who built the grid.

Pro tip: You can try the Kendo UI for Angular Grid for free for 30 days. Test it with your real data before you decide.

If you have always worked within the official Angular ecosystem, the next option on this list will be very familiar to you.

2. Angular Material Table (CDK)

Angular Material is the official UI library from the Angular team. Most Angular developers have used its table component.

The Good: It is very stable, updated frequently and follows Material Design standards. The Component Dev Kit (CDK) gives you a lot of flexibility.
The Cons: You must build almost every feature yourself. Sorting, filtering, virtual scrolling and export are not included by default. For a project with a short deadline, this is too much work.
My Feedback: Angular Material is a good starting point, but it is only a foundation. In a high-stakes project, you should not waste time building features that professional libraries have already solved.

When you need a tool that focuses entirely on high-performance tables as a standalone component, you will likely look at the following library.

3. AG Grid

AG Grid is a very popular standalone grid library. It is known for high performance and many enterprise features.

The Good: If your app is mostly about tables, AG Grid is very fast. The community version includes many features for free.
The Cons: A real application needs more than just a grid. You will also need charts, date pickers and modals. AG Grid does not provide these. If you mix it with other libraries, it is difficult to keep the design and styling consistent.
My Feedback: AG Grid is powerful, but it is a standalone tool. Kendo UI gives you the same power within a unified system. This means your grid, charts and dropdowns all use the same design and the same support team.

For teams that prefer a large collection of components that are easy to implement, there is another very common choice in the community.

4. PrimeNG

PrimeNG is a very complete library. Its p-table component is good for most standard use cases.

The Good: It has good documentation and is easy to start using. It works well for standard CRUD applications with medium-sized datasets.
The Cons: For extreme scenarios, such as thousands of real-time updates, it can have performance issues. Virtual scrolling is available but requires more manual configuration.
My Feedback: PrimeNG is a good choice for standard business apps. But for a fintech dashboard where the grid is the main product, you need a tool built for high performance from the start.

As your project moves into the enterprise space with specific corporate requirements, you might consider an alternative that is widely used in large companies.

5. Syncfusion Angular Grid

Syncfusion offers an enterprise grid with many features like row grouping and PDF export.

The Good: It has a long list of features and handles large data well. It integrates well if you already use other Syncfusion tools.
The Cons: The API does not always feel like standard Angular code, so there is a learning curve. Changing the design to match a Figma file can be difficult and slow.
My Feedback: If your designers and developers need to work together daily, the difficulty in styling Syncfusion can be a problem. Progress ThemeBuilder makes this process much faster and more accurate in Kendo UI.

Teams coming from a background in traditional software development often find that the next grid fits their existing mental model perfectly.

6. DevExtreme Angular DataGrid

DevExtreme by DevExpress is a feature-rich grid often used in traditional enterprise software.

The Good: It is great for complex scenarios like master-detail views and multi-level grouping. It will feel familiar if your team has a background in .NET or WinForms.
The Cons: Some of the patterns feel old for modern web development. Customizing the CSS to look modern can be a difficult task.
My Feedback: Modern applications need to be fast and look current. DevExtreme’s older patterns can slow down a team. The Kendo UI library uses a modern, Angular-native architecture that is easier to maintain.

If your main priority is fast data visualization and specialized charts, there is a competitor that focuses heavily on those areas.

7. Ignite UI for Angular Grid

Ignite UI focuses on data visualization and high-performance grids.

The Good: The rendering engine is very fast and handles live updates well.
The Cons: The community is smaller than other options. If you find a complex bug, it is harder to find answers or documentation.
My Feedback: Performance is important, but support is also critical. The Kendo UI Grid offers similar performance but adds better documentation and a larger community to help you when you have problems.

For developers who value a very clean design and a modular architecture based on modern TypeScript principles, there is an elegant solution to consider.

8. Taiga UI Table

Taiga UI is a modular library with a focus on TypeScript.

The Good: It has a very clean design. Because it is modular, you only use the code you need.
The Cons: You have to build many features yourself. Virtual scrolling and export are not ready to use out of the box.
My Feedback: Taiga UI is a great project, but it requires too much manual work for a short deadline. The Kendo UI library gives you 120+ components that are already tested and ready to use.

Some projects still use libraries that were very popular during the early versions of Angular and remain in many existing codebases.

9. ng2-smart-table

ng2-smart-table was a very popular choice in the early days of Angular.

The Good: It is very simple to set up for basic tasks like sorting and filtering.
The Cons: The library is not updated frequently anymore. This creates a risk of bugs or compatibility issues with new versions of Angular.
My Feedback: Using a library that is no longer maintained creates “technical debt.” The Kendo UI library is supported by Progress Software, which means it receives regular updates and a clear roadmap you can trust.

Finally, if your application requires a grid that behaves exactly like a spreadsheet instead of a standard list, there is a specialized tool for that specific case.

10. Handsontable

Handsontable provides a spreadsheet-like experience (like Excel) in the browser.

The Good: It is the best choice if your users need to edit data like a spreadsheet (bulk edits, formulas, etc.).
The Cons: The grid does not fully support Angular, works like a wrapper and is very limited (it also has a separate commercial license for bringing in Excel formulas features).
My Feedback: Handsontable is perfect for spreadsheets, but a trading dashboard has different needs. The Kendo UI Grid provides the necessary Excel features while offering native Angular integration and real-time performance.

Summary

Today we learned how many good Angular grids exist, but when developers or agents in 2026 need to cover all the needs for your team and project, the list of options becomes much shorter. Mst grids on this list are good at one specific thing. However, for a project where the grid is the core of the product, you need a complete solution.

I pick the Kendo UI for Angular Grid as the best choice because it combines performance, features and design flexibility, and is also ready for the AI era with tools like the MCP Server.

When you have a short deadline, you need a tool that helps you work faster from day one and keeps the focus on building your product.

As I mentioned, Kendo UI for Angular comes with a free 30-day trial. So go ahead and poke around:

Download Free Trial

Async Validation in Angular Signal Forms

2026-07-14T11:38:56Z

Learn how to implement async validation in Angular Signal Forms using the validateHttp function, for example to check whether a username is already taken.

Signal Forms create a form from a writable signal model, where the model is the source of truth, and any change in the form or the model is automatically reflected in the other.

Adding Sync Validations

To make it more usable, let us add some validations to the email field. We are going to add the validations below to the email field.

Required
Email

  signupForm = form(this.signupModel, (schemaPath) => {
    required(schemaPath.email, { message: 'Email is required' });
    email(schemaPath.email, { message: 'Please enter a valid email address' });
    
  });

Both required and email are synchronous validators, and they run on each value change of controls. The required() validates that the control value is neither null nor an empty string (''), and email() validates the control value against a standard email regular expression pattern.

Both validators execute synchronously on each value change of the control.

We can conditionally show error messages for sync validators in the template using the field-state signals touched(), invalid() and errors().

@if (signupForm.email().touched() && signupForm.email().invalid()) {
    <ul class="error-list">
      @for (error of signupForm.email().errors(); track error) {
        <li>{{ error.message }}</li>
      }
    </ul>
  }

The touched() && invalid() signals are used to show errors only after the user focuses and then blurs the field, so the form does not show errors on initial load.

Adding Async Validations

There are two ways you can add async validation to a signal form.

Using validateHttp()
Using validateAysnc()

In most cases, applications should use validateHttp() for asynchronous validation, as it simplifies HTTP-based validation with minimal configuration and supports most common scenarios.

validateAsync() is a lower-level API that directly exposes Angular’s resource primitive, providing full control over the validation process but requiring more implementation effort and a deeper understanding of the resource API.

Let’s see how we can use validateHttp() to check whether an email exists or not .

validateHttp(schemaPath.email, {
      request: ({ value }) => {
        const emailValue = value();
        if (!emailValue) return undefined; // skip when empty
        return `http://localhost:3000/user/check?email=${emailValue}`;
      },
      onSuccess: (response: { exists: boolean }) => {
        return response.exists
          ? {
              kind: 'emailTaken',
              message: 'This email is already registered',
            }
          : null;
      },
      onError: () => ({
        kind: 'serverError',
        message: 'Could not verify email. Please try again later.',
      }),
    });

We have an API that returns a response indicating whether the email already exists in the database, and we use the response’s exists property to determine whether the email is already registered.

{
  "exists": true,
  "user": {
    "id": 1,
    "name": "User 1",
    "email": "user1@example.com"
  }
}

We can show the pending state and error message from both sync and async validator as shown below:

@if (signupForm.email().pending()) {
    <span class="pending">Checking email availability...</span>
  }
  @if (signupForm.email().touched() && signupForm.email().invalid()) {
    <ul class="error-list">
      @for (error of signupForm.email().errors(); track error) {
        <li>{{ error.message }}</li>
      }
    </ul>
  }

The validation flow works like this:

User enters a value.
Synchronous validators run first.
If sync validation fails, async validation does not run.
If sync validation passes, async validation starts, and pending() becomes true.
Once the request completes, pending() becomes false.
Errors are updated based on the response.

This can be put in a flow chart as shown below:

Putting everything together, a signal-based signup form with both synchronous and asynchronous validators will look like this:

signupModel: WritableSignal<SignupFormValue> = signal<SignupFormValue>({
    email: '',
    password: '',
  });

  signupForm = form(this.signupModel, (schemaPath) => {
    required(schemaPath.email, { message: 'Email is required' });
    email(schemaPath.email, { message: 'Please enter a valid email address' });
    validateHttp(schemaPath.email, {
      request: ({ value }) => {
        const emailValue = value();
        if (!emailValue) return undefined; // skip when empty
        return `http://localhost:3000/user/check?email=${emailValue}`;
      },
      onSuccess: (response: { exists: boolean }) => {
        return response.exists
          ? {
              kind: 'emailTaken',
              message: 'This email is already registered',
            }
          : null;
      },
      onError: () => ({
        kind: 'serverError',
        message: 'Could not verify email. Please try again later.',
      }),
    });
    
  });

  protected onSubmit(event: Event): void {
    event.preventDefault();
    submit(this.signupForm, async () => {
      const credentials = this.signupModel();
      console.log('Signup submitted:', credentials);
    });
  }

And on the template, the pending state and error messages can be shown as below:

<form (submit)="onSubmit($event)">
  <p>
    <label for="signup-email">Emaillabel><br />
    <input id="signup-email" type="email" [formField]="signupForm.email" />

  p>
  @if (signupForm.email().pending()) {
    <span class="pending">Checking email availability...span>
  }
  @if (signupForm.email().touched() && signupForm.email().invalid()) {
    <ul class="error-list">
      @for (error of signupForm.email().errors(); track error) {
        <li>{{ error.message }}li>
      }
    ul>
  }
  <p>
    <label for="signup-password">Passwordlabel><br />
    <input id="signup-password" type="password" [formField]="signupForm.password" />
  p>
  <p>
    <button type="submit">Sign upbutton>
  p>
form>

validateHttp Function

The validateHttp function contains three components:

Request function
Success handler function
Error handler function

In the validateHttp, we have set the request function. It returns one of these three values:

Undefined to skip the validation.
A URL for performing the validation using the GET operation.
An HttpResourceRequest if you need to set additional request options, such as the verb header, etc. This is the same object you use with httpResource to configure the request object.

Read more about the httpResource here.

The onSuccess function receives the HTTP response and returns validation errors or undefined for valid values. It can also return multiple errors when needed.

The onError function handles request failures like network errors or HTTP errors.

If you need to validate an email using an endpoint with a POST request, custom headers and the email in the request body, you can do so by returning an httpResourceRequest from validateHttp, as shown below.

signupForm = form(this.signupModel, (schemaPath) => {
    required(schemaPath.email, { message: 'Email is required' });
    email(schemaPath.email, { message: 'Please enter a valid email address' });

    validateHttp(schemaPath.email, {
      request: ({ value }) => {
        const emailValue = value();
        if (!emailValue) return undefined;
        return {
          url: 'http://localhost:3000/user/check',
          method: 'POST',
          body: { email: emailValue },
          headers: { 'x-api-key': 'my-secret-key' },
        };
      },
      onSuccess: (response: { exists: boolean }) => {
        return response.exists
          ? { kind: 'emailTaken', message: 'This email is already registered' }
          : null;
      },
      onError: () => ({
        kind: 'serverError',
        message: 'Could not verify email. Please try again later.',
      }),
    });
  });

The other function for async validation is validateAsync() function. It is a lower-level API that exposes Angular’s resource primitive directly. It offers complete control but requires more code and familiarity with Angular’s resource API. Most applications should use validateHttp().

You should use validateAsync() for these purposes:

Non-HTTP validation – WebSocket connections, IndexedDB lookups or Web Worker computations
Custom caching strategies – Application-specific caching beyond simple memorization
Complex retry logic – Custom backoff strategies or conditional retries
Direct resource access – When you need the full resource lifecycle

In a future article, we’ll take a deeper look at validateAsync. For now, I hope this gives you a clear understanding of how to implement async validation in Angular Signal Forms using the validateHttp function. Thanks for reading!

Getting Started with Angular Signal Forms

2026-07-07T12:13:00Z

Learn the basics of Angular Signal Forms, including models, validation and two-way synchronization, to build reactive forms with confidence.

Angular version 21.0 introduced one of the most exciting and awaited features: Signal Forms. Traditionally, there have been two types of forms:

Template Forms
Reactive Forms

Angular 21.0 introduced a new form type:

Signal Forms

And now, Angular 22 makes Signal Forms stable. Signal Forms are a combination of Signal-based reactivity and forms. In my opinion, Signal Forms are the future of forms and user input in Angular.

This article gives you a basic introduction to Signal Forms and shows you how to work with models, validation and two-way synchronization.

First Signal Form

Signal-based forms use a new form function. It creates a form from a writable signal model, where the model is the source of truth, and any change in the form or the model is automatically reflected in the other.

Let’s start by creating an interface to represent the user:

export interface IUser {
    email: string;
    password: string;
}

Next, we create a model that will be used to create the form, as shown below. As mentioned earlier, the model must be a writable signal.

user : WritableSignal<IUser> = signal({
    email: '',
    password: ''  
  })

We can create a signal-based form using the form() function from the @angular/forms/signals.

loginForm = form(this.user);

That’s it. You have created a signal-based form in Angular.

The form function returns a FieldTree, where each field is represented as a signal. In other words, the form function produces a data structure in which every field is a signal enriched with signal-based properties such as value, dirty, invalid and others.

To better understand this structure, let’s print the following values:

console.log(this.loginForm.email().value());
console.log(this.loginForm().valid());
console.log(this.loginForm.email().invalid());
console.log(this.loginForm.email().dirty());
console.log(this.loginForm.email().touched());
console.log(this.loginForm.email().errors());

As shown in the example above, the email field is a signal, and all of its properties are signals as well. Because both the field and its properties are signals, you can use them directly in the template, as demonstrated below.

<input type="email" [formField]="loginForm.email" />
<input type="password" [formField]="loginForm.password" />

To use formField, import it into the component class, as shown below:

import { form, FormField } from '@angular/forms/signals';

@Component({
  selector: 'app-login',
  imports: [FormField],
  templateUrl: './login.html',
  styleUrl: './login.css',
})
export class Login {}

As discussed earlier, the form() function creates a form from the given model, where the model is the single source of truth, so changes in the form update the model and changes in the model update the form.

In simple words, the model and the form are connected through two-way data binding. This means that when the model signal changes, the form value updates accordingly, and when the form value changes, the model updates as well.

To demonstrate this, read the model signal value inside an effect, as shown below:

constructor(){
  effect(()=>{
    console.log(this.user())
  })
}

As soon as you start typing in the form, you can read the updated value in the effect. Similarly, when you change the model signal value, the form value is reflected as well.

this.user.set({
  email: 'a@a.com',
  password:'abc'
})
console.log(this.loginForm().value()); // updated value of the form

In summary, in signal-based forms, the model used by the form and the form itself are connected via two-way data binding. Updating one automatically updates the other.

Adding Validations

The form() function in Signal Forms makes it simple to add validators to form fields. You can pass a schema function to the form() function to add validators to the form.

In Signal Forms, validations are defined using a schema function. You pass this schema function as the second parameter to the form() function.

You can add the required validators to the email and password fields as shown below:

loginForm = form(this.userModel,(schema)=>{
  required(schema.email,{message:'email is required'});
  email(schema.email,{message:'email is not valid'});
  required(schema.password,{message:'password is required'});
});

We have added the required and email built-in validators and used the message option to provide custom error messages.

As discussed earlier, in a Signal Form, all properties of a field are signals. This allows you to use them directly. For example, to display validation error messages for the email field, as shown below.

<label>
  Email
  <input type="email" [formField]="loginForm.email" />
label>
@if (loginForm.email().invalid() && loginForm.email().touched()) {
  <div class="error">
    @for (error of loginForm.email().errors(); track error.kind) {
      <span>{{ error.message }}span>
    }
  div>
}

In the same way, error messages for the password field can be displayed as below:

<label>
        Password
        <input type="password" [formField]="loginForm.password" />
    label>
    @if (loginForm.password().invalid() && loginForm.password().touched()) {
    <div class="error">
        @for (error of loginForm.password().errors(); track error.kind) {
        <span>{{ error.message }}span>
        }
    div>
    }

Submitting the Form

To complete the form, you can add submit functionality by importing the submit() function and using that to submit the form.

  onSubmit(event: Event) {
    event.preventDefault();
    submit(this.loginForm, async () => {
      const u = this.userModel();
      console.log('Logging in with:', u);
    });
  }

The submit() function runs the logic only when the form is valid.

In the template, the form submit event can bind to the onSubmit () function using event binding, as shown below. You can also disable the submit button when the form is invalid.

<form (submit)="onSubmit($event)">
    // other code for fields …..
    <button [disabled]="loginForm().invalid()" type="submit">Loginbutton>
form>

Putting everything together, the login form using Signal Forms can be implemented as shown below.

The IUser interface is created as shown below:

export interface IUser {
    email:string; 
    password : string; 
}

The Login component using a Signal Form is created as shown below.

import { Component, signal, WritableSignal } from '@angular/core';
import { IUser } from '../user';
import { email, form, FormField, required, submit } from '@angular/forms/signals';

@Component({
  selector: 'app-login',
  imports: [FormField],
  templateUrl: './login.html',
  styleUrl: './login.css',
})
export class Login {

  userModel: WritableSignal<IUser> = signal({
    email: '',
    password: ''
  });

  loginForm = form(this.userModel, (schema) => {
    required(schema.email, { message: 'email is required' });
    email(schema.email, { message: 'email is not valid' });
    required(schema.password, { message: 'password is required' });
  });

  onSubmit(event: Event) {
    event.preventDefault();
    submit(this.loginForm, async () => {
      const u = this.userModel();
      console.log('Logging in with:', u);
    });
  }
}

In the template, the form can be created as shown below:

<form (submit)="onSubmit($event)">
    <label>
        Email
        <input type="email" [formField]="loginForm.email" />
    label>
    @if (loginForm.email().invalid() && loginForm.email().touched()) {
    <div class="error">
        @for (error of loginForm.email().errors(); track error.kind) {
        <span>{{ error.message }}span>
        }
    div>
    }

    <label>
        Password
        <input type="password" [formField]="loginForm.password" />
    label>
    @if (loginForm.password().invalid() && loginForm.password().touched()) {
    <div class="error">
        @for (error of loginForm.password().errors(); track error.kind) {
        <span>{{ error.message }}span>
        }
    div>
    }
    <button [disabled]="loginForm().invalid()" type="submit">Loginbutton>
form>

Understanding Forms Models

Signal Forms are backed by a model, which is a writable signal. When the model value changes, the form updates automatically. Likewise, when the user interacts with the form, the model is updated. In this way, the model and the form are connected through two-way binding, which means changes in one are reflected in the other.

It is always best practice to use an interface to define the model. For example, if we are creating a form to edit a product, we can define a type for it as shown below.

export interface IProduct{
    id:number;
    name:string;
    price:number;
    description:string;
    category:string; 
}

export interface IProductForm extends Omit<IProduct, 'id' | 'category'> {}

Now to edit the product, fetch it from the API using the resource API as shown below:

    idToFetch = signal(1);

    productsResource = resource({
        params: this.idToFetch,
        loader: async ({ params }) => {
            let id = params;
            const response = await fetch(`http://localhost:3000/product/${id}`);
            if (!response.ok) {
                throw new Error(`HTTP error! status: ${response.status}`);
            }
            return response.json() as Promise<IProductForm>;
        }
    });

We have received the product data to be updated from the API. In the next step, we will create a signal-based form to bind this data and allow the user to update the product.

   productUpdateModel = signal<IProductForm>({
        name: '',
        price: 0,
        description: ''
    });

    productForm = form(this.productUpdateModel);

That’s it. Now, in the template, use the formField directive to display the fetched product data in the form, as shown below.

<form (submit)="onSubmit($event)">
    <label>
        Name
        <input type="text" [formField]="productForm.name" />
    label>

    <label>
        Price
        <input type="number" [formField]="productForm.price" />
    label>

    <label>
        Description
        <input type="text" [formField]="productForm.description" />
    label>

    <button [disabled]="productForm().invalid()" type="submit">Updatebutton>
form>

To update the product, let’s add an input field and a button to load the product.

<label>Update Product Id : label>
<button (click)="fetchProduct(+productIdInput.value)">Load Productbutton>

To fetch the updated product, set the signal accordingly. There are multiple ways to bind the value returned from the API to the productUpdateModel. You can either use productResource.value() directly in the template or assign it as shown below.

   fetchProduct(id: number) {
        this.idToFetch.set(id);
        if (this.productsResource.hasValue()) {
            this.productUpdateModel.set(this.productsResource.value());
        }
    }

As you see from the above example, the form model and form fields are in two-way data-binding synchronisation, and changes flow bidirectionally between them.

The interaction between user input and the model follows these steps:

The user enters text or selects a value from the dropdown.
The formField directive detects the change.
The corresponding FieldState is updated.
The model signal is updated accordingly.

This flow is illustrated in the diagram below.

The flow between the model and the user input follows the steps below:

Use code to set() or update() signal model
Notifies all subscribers
Field state updates
formField directive updates the input element

This flow is illustrated in the diagram below.

Two-way data synchronization can be better understood by the following simple code example.

count = signal({ v: 0 });
  countInput = form(this.count);

  updateCount() {
    this.count.update(c => ({ v: c.v + 1 }));
  }

And on the template:

<input type="number" [formField]="countInput.v" />
 <button (click)="updateCount()">update countbutton>
 <p>Count: {{ count().v }}p>

When you run the above code, you will see that the input and model value are in sync with each other.

Optional Fields

Always use explicit TypeScript type to define the model. So to create a login form create a type like below.

export interface IUser {
    email:string; 
    password : string; 
    rememeberme?: boolean;
}

You use them to create a signal form as shown below:

  userModel: WritableSignal<IUser> = signal({
    email: '',
    password: '',
    rememberMe: null
  });

  loginForm = form(this.userModel);

When you define a form using explicit types as shown above, the resulting field tree is fully type-safe. For example, loginForm.email is inferred as FieldTree, and any attempt to access a property that doesn’t exist will produce a compile-time error. In the code below, TypeScript will infer type of email as string.

email = this.loginForm.email;

And to set the optional field:

Set the value explicitly to null
For input fields such , set the value to empty string.
Do not use undefined

Fields explicitly set to undefined are omitted from the field tree. A model defined as { value: undefined } behaves the same as {}. Accessing that field returns undefined instead of a FieldTree instance.

Nested Objects in Model

You can use nested objects to create a form like below:

export interface IProduct {
    id:number;
    name:string;
    price:number;
    description:string;
    category:string;
    vendor : IVendor;
}

export interface IVendor{
    id:number;
    name:string;
    email:string;
    phone:string;   
}

Next, you can create the form using the nested object as shown below:

   productModel = signal<IProduct>({
    id: 0,
    name: '',
    price: 0,
    description: '',
    category: '',  
    vendor: {
      id: 0,
      name: '',
      email: '',
      phone: ''
    } 
   });

   productForm = form(this.productModel);

In the template, you can access nested object properties using dot notation, as shown below.

<form (submit)="onSubmit($event)">
    <label>Namelabel>
    <input type="text" [formField]="productForm.name" />
    <label>Vendor Namelabel>
    <input type="text" [formField]="productForm.vendor.name" />
    <button type="submit">Submitbutton>
form>

Before moving to the validation section, note that the form model and the domain model are two different concepts and should be treated separately.

Your API response may map directly to the domain model, but you should define a dedicated form model when working with signal-based forms.

We will explore this distinction in more detail in a separate article.

Validations

You pass validation rules to the Signal Forms using a schema. You pass schema as second parameter to the form function.

  userModel: WritableSignal<IUser> = signal({
    email: '',
    password: ''
  });


  loginForm = form(this.userModel, (schema) => {
    required(schema.email, { message: 'email is required' });
    email(schema.email, { message: 'email is not valid' });
    required(schema.password, { message: 'password is required' });
  });

As shown above, you provide a schema definition along with validation rules to apply validations to the respective fields of the form.

The schema function gets a SchemaPathTree object that lets us define the validation rules. The schema function runs at the time of initialization, and validation runs automatically whenever field values change.

On the template, you can use the validation as shown below:

<label>
        Email
        <input type="email" [formField]="loginForm.email" />
    label>
    @if (loginForm.email().invalid() && loginForm.email().touched()) {
    <div class="error">
        @for (error of loginForm.email().errors(); track error.kind) {
        <span>{{ error.message }}span>
        }
    div>
    }

Validation works in these steps:

Define validation rules in schema
Validation rules runs when filed value changes
Validation errors are propagated as signals
UI automatically updates when validation state changes

There are two types of validations:

Synchronous validation – required(), email(), etc.
Asynchronous validation – validateHttp()

When a field value changes, Angular runs validation in the sequence:

First it runs all synchronous validations.
If all synchronous validation pass, then it runs asynchronous validation.
After that, it updates the field state signal values such as valid(), invalid(), errors() and pending().

Angular provides these built-in validation rules:

required()
email()
min()
max()
minLength()
maxLength()
pattern()

You can apply required() and email() validation on email field as shown below:

  loginForm = form(this.userModel, (schema) => {
    required(schema.email, { message: 'email is required' });
    email(schema.email, { message: 'email is not valid' });
  });

When you have multiple validation rules applied, each rule runs independently and can cause form to be invalid.

Angular Signal Forms make it straightforward to implement custom validations. For example, if you want to verify that the email belongs to the nomadcoder domain, you can easily add a custom validator as shown below.

  loginForm = form(this.userModel, (schema) => {
    required(schema.email, { message: 'email is required' });
    email(schema.email, { message: 'email is not valid' });
     validate(schema.email, ({ value }) => {
      if (!value().endsWith('@nomadcoder.ai')) {
        return {
          kind: 'emailDomain',
          message: 'Email must end with @nomadcoder.ai'
        }
      }
      return null;
    });
  });

In upcoming articles, we will get into details of custom validation and asynchronous validation.

Form Field and Its Signal Properties

The form function returns a FieldTree that represents all properties of the model. Each property is exposed as a signal, and each property signal includes a set of attributes that are also implemented as signals.

When you access a field from the field tree, as shown below, you can retrieve its associated attributes as illustrated:

The various signal attributes are as below:

value()
dirty()
hidden()
errors
errorSummary
valid
invalid
pending
submitting
Etc.

As all these are signals(), they can be directly used on the template. I hope now you understand Angular Signal Forms. In coming articles, we will go deeper into:

asynchronous validators
custom validators

I hope you find this article useful. Thanks for reading.

Building Component-Aware Production UIs with Angular and Kendo UI MCP

2026-06-15T16:26:20Z

Through MCP, we can use component-aware AI to help us build user interfaces in conjunction with our favorite component libraries. See it in Angular!

We as developers use AI tools like Cursor, Claude Code and Copilot; they have changed how we write code. We delegate entire sections of our applications to an agent, and for many tasks, this works really well.

But when it comes to building user interfaces with a specific framework, things get complicated fast. Results are unpredictable, the code feels incomplete and we end up spending more time fixing than building.

If you have felt that, you are not alone. The good news is that the problem is not the AI. The problem is how we are using it.

We will see why AI struggles with UI development and how a new approach called “component-aware AI” changes everything. But first, let’s understand what is really missing.

The Problem

In the world of AI, we read about context all the time, which is the key problem when things go wrong. When you ask your AI assistant to use a component from a specific framework, it relies on its training data. It does not know:

The exact version of Angular you are using
The best practices for your library
The specific design rules of your organization

Do you want to learn more about the context problem?

So the AI starts guessing. And that guessing creates real problems:

High costs and effort: We waste many tokens just explaining our UI library to the AI. We end up copying and pasting manuals, providing code examples and fixing mistakes, making the whole process slow and expensive.
The “fix and repeat” loop: We copy the code, find a small bug, ask the AI to fix it and repeat the cycle.
Low-quality code: The code the AI gives us is often incomplete or outdated. We spend more time fixing it than it would have taken to write it from scratch.

But we have good news: using a new approach called “component-aware AI” changes everything.

The Shift to MCP

We need a new way for the AI to work. We need “component-aware AI.” This shift is made possible by the Model Context Protocol (MCP). Instead of the AI trying to remember code from its training data, it can read the live documentation of your library in real time.

Think of it like the difference between following a recipe from memory versus using a smart kitchen robot with everything preconfigured. It is automated, precise and much freer from errors.

When you use an MCP like the Progress Kendo UI for Angular MCP, the AI assistant queries the official library data before it writes any code. This verifies that every property and every method is correct.

The best way to understand the difference is to see it in action. I have experienced the shift from working with blind AI to giving agents the right tools to deliver code with confidence and without technical debt. Let’s do it!

Want to build your own MCP server? Check this out: https://www.youtube.com/watch?v=mM8T8bSCTyk

Let’s start with the scenario you probably already know.

Open your terminal and run these two commands to create the project and install the Kendo UI for Angular Grid:

# Create the project
ng new accounting-app --style=scss --ssr=false
 
# Install Kendo UI Grid
ng add @progress/kendo-angular-grid

Then, you ask your AI assistant (without specialized context) to build the interface:

Prompt: “Create a General Ledger grid with Kendo UI for Angular. Show Date, Description, Debit, and Credit. Add footer totals.”

The project compiles and runs, but the result is full of immediate technical debt. Here is what the AI generates:

// ❌ BLIND AI: Ignores Kendo built-in aggregation utilities
export class App {
 protected readonly ledgerItems: LedgerEntry[] = [...];
 
 // Manual logic the developer must maintain forever
 protected get totalDebit(): number {
   return this.ledgerItems.reduce((sum, item) => sum + item.debit, 0);
 }
 
 protected get totalCredit(): number {
   return this.ledgerItems.reduce((sum, item) => sum + item.credit, 0);
 }
}

Let’s look at the problems here. For totalDebit, if you add more columns with totals, you have to manually write a .reduce() for each one. The AI does not know that Kendo UI already has aggregateBy built in.

Another common inconsistency is with colors. Instead of using design tokens, it uses hard-coded values like #f5f7fb, which breaks visual coherence across the app.

The worst part is the lack of accessibility. There are no ARIA attributes or semantic roles, which Kendo UI handles automatically when configured correctly.


<kendo-grid [data]="ledgerItems">
 <kendo-grid-column color="#f5f7fb" field="debit" title="Debit">
 kendo-grid-column>
kendo-grid>

In the end, you spend more time cleaning up AI code than you would have spent writing it from scratch. The real issue is that we are not giving the AI the right tools to perform at its best.

We can fix that, because the solution is simpler than you might think.

The Agentic Way: Using the Power of Kendo UI MCP

Now, let’s move to the productive workflow and combine the power of Kendo UI MCP with our agents.

Instead of the manual configuration and the “blind” approach, we start with a single command. Open your terminal and run:

npx kendo angular setup

Here is where the magic happens. It automatically installs the license and registers the Kendo UI MCP Server across your IDEs and AI agents (VS Code, Cursor, Claude Code). From this point on, your agent has full context and no longer has to guess.

Now we ask the same AI agent to build the same application with the same prompt. This time our agent, thanks to MCP, uses the Kendo UI Generator tool to generate the code.

Let’s look at the generated code and why it is production-ready.

// ✅ COMPONENT-AWARE AI: Uses Signals, Modern Angular Patterns, and Kendo's aggregateBy
import { aggregateBy, AggregateResult } from '@progress/kendo-data-query';
 
export class GeneralLedgerComponent {
 private ledgerService = inject(LedgerService);
 
 // Modern signal-based state
 protected ledgerEntries = signal<LedgerEntry[]>(this.ledgerService.getLedgerEntries());
 
 // Kendo's aggregateBy handles all column totals in one call, no manual .reduce() needed
 protected totals = computed<AggregateResult>(() =>
   aggregateBy(this.ledgerEntries(), [
     { field: 'debit', aggregate: 'sum' },
     { field: 'credit', aggregate: 'sum' },
   ])
 );
}

The AI now uses Signals (signal, computed) and proper dependency injection (inject), which are the recommended modern Angular patterns. And instead of a manual .reduce() per column, it uses Kendo UI aggregateBy. Add a new column with a total, and you just add one line to the array, nothing else.

In the SCSS file, instead of hard-coding colors, it uses official Kendo UI Design Tokens such as var(--kendo-color-surface-alt) and var(--kendo-color-success).

And in the template, the difference is clear:


<kendo-grid
   [data]="ledgerEntries()"
   [reorderable]="true"
   [navigable]="true"
   role="table"
   aria-label="General Ledger Entries"
>
kendo-grid>

That is the key difference. When we use Kendo UI for Angular MCP, our agents do not just generate code. They generate the right code, follow best practices and deliver to a high standard.

Here are the three benefits I value most:

Significantly reduced hallucinations: The AI does not guess property names. It reads the actual documentation in real time.
Accessible by default: Kendo UI components are built to follow accessibility standards. When the AI uses these components correctly, your app is automatically inclusive.
Token efficiency: No more copying large lines of documentation into your chat. The AI fetches only what it needs, saving you tokens and money.

Go deeper and explore everything that Kendo UI MCP can do.

Now that we have seen both worlds side by side, let’s talk about what this really means for how we choose our tools going forward.

Conclusion

Simply using AI is not enough. And simply using a component library is not enough anymore, either.

This is the paradigm shift. We are moving from a world where a library just gives you components to one where a library also provides the context layer that makes modern development possible. Kendo UI MCP is exactly that: it acts as a bridge between your agents and the library so that the AI can do its job properly rather than guessing.

By bridging that context gap, we move from “guessing” to “knowing” and agents stop hallucinating APIs and start delivering production-ready code.

My personal take: Next time you evaluate a UI library, do not just look at the component catalog. Ask if your framework has the tools for the way we build software today. Because that is the question I ask myself now, every time.

BTW, if you want to work less and ship more, it is time to make your agents work for you so you can focus on building what really matters.

Resources

Kendo UI for Angular
MCP Protocol: Learn more about MCP

Try Now

Remember, Kendo UI for Angular comes with a free 30-day trial, so you can explore all these goodies yourself.

Try Now

Angular 22: The Evolution of Modern Angular

2026-06-05T21:01:27Z

Signals, OnPush, declarative async resources: Angular 22 makes standard several features that help developers build better apps.

A few days ago, we checked out Google I/O 2026, and today we need to talk about our favorite framework: Angular. Why? Because version 22 is here!

Angular v22 is a major update focused on stability, performance and ergonomic APIs. It brings a more polished signal-driven platform and better data loading primitives that make modern apps feel faster and simpler to build.

Before we look at the most interesting changes, let’s talk about the foundation. Angular v22 stabilizes the features we have been testing in the last few versions. If you want to build a high-performance app today, these are the new standards.

Stable Signal Forms and httpResource

Reactive Forms were great, but they often felt separate from the modern Signal-based reactivity. In v22, Signal Forms are officially stable.

What does this mean for us?

Better reactivity: No more unnecessary updates when a single field changes.
Better type safety: We finally have a form system that works perfectly with TypeScript.

Do you remember HttpClient and the manual toSignal conversions? They worked, but they added extra code. Now we have httpResource.

It is the new standard for fetching data. It treats your HTTP requests as signals, automatically handling the loading, error, and data states for you.

Learn more: Dive deeper into Getting Started with httpResource API and learn more about Angular Signal Forms vs. Reactive Forms.

But what if your request depends on another signal? In v22, we have the new chain() method. It allows you to link resources together. If the first resource is loading, the second one waits automatically. This is a big win for complex data!

Wait, what if you are already using RxJS? Don’t worry, Angular has a solution for that too. Let’s see how v22 handles the transition from Observables to Resources.

RxResource vs. httpResource

A common question is: “Should I stop using RxJS?” The answer is no. Angular v22 introduces rxResource as the perfect partner for your existing Observable streams.

httpResource: Use this for standard API calls. It is optimized for the Fetch API and handles JSON automatically.
rxResource: Use this when your data source is an existing Observable. It allows you to use the power of RxJS operators inside the clean, Signal-based Resource API.

Now that we have our data fetching ready, how do we make sure our users and agents can navigate efficiently? Let’s talk about the new smart navigation features in the Router.

The Angular Router received some updates in v22 that solve common problems.

URL decoupling: You can now keep a clean URL in the address bar while the app shows a different state. With the new browserUrl input on RouterLink, you can show /settings while the router actually uses /account/advanced-preferences.
Parameter inheritance: Child routes now inherit parameters from their parents by default, and you don’t need extra configuration to get an ID from a parent route.

But a great UI and smart routing mean nothing if the page is slow to load. This brings us to the most impressive performance update in v22: incremental hydration.

Server-Side Rendering (SSR) is no longer a problem. In v22, incremental hydration is the default.

Angular now loads your application in small parts as they become visible. Combined with resource caching, the client can use the data fetched on the server without making a second API call. The user sees the data instantly, and the “flicker” of reloading data is gone.

Learn more: Explore The New Angular Hydration for in-depth details.

But performance is also about how the browser handles changes. This is where the biggest change in Angular’s history reaches its peak.

OnPush by Default

For years, ChangeDetectionStrategy.Eager (previously known as `Default`) was the standard for Angular’s change detection. With v22, ChangeDetectionStrategy.OnPushis now the default for new components!

By using ChangeDetectionStrategy.OnPush as the default, we get:

Better performance: The framework only checks what it needs to, exactly when it needs to, avoiding unnecessary checks.
A step closer to Zoneless: This sets the stage for eventually dropping zone.js in the future.

If you have an older app, don’t worry! There is a migration tool that adds ChangeDetectionStrategy.Eager (the new name for the old behavior) to your existing components exactly as before.

Now, how do we make sure our fast code actually works? Let’s talk about the new speed king of testing.

Vitest

Testing used to be the slow part of our work. Not anymore. Angular v22 officially replaces Karma/Jasmine with Vitest as the default test runner.

It is very fast and shares the same configuration as your build pipeline. Also, the new migrate-karma-to-vitest tool makes the change very easy, even for complex tests!

Do you want to try Vitest?

Angular Aria: Accessibility for Everyone

Building custom components with correct ARIA roles and focus management can be difficult. In v22, Angular Aria is officially stable.

Think of it as “headless accessibility.” It provides the logic you need to build your own accessible components. It handles the complicated parts of ARIA attributes and keyboard interactions for you.

Why does this matter for AI? Because accessible apps are much easier for AI Agents to understand!

Check this example about how to build accessible components with Angular Aria.

Async Dependency Injection

The injectAsync() function allows us to lazy-load services only when they are actually needed, while still creating the instance with Angular dependency injection. This keeps your app small and fast.

export class CheckoutComponent {
  // We declare the lazy injection in the injection context (class field)
  private paymentGatewayLoader = injectAsync(() => 
    import('./payment-gateway.service').then(m => m.PaymentGatewayService)
  );

  async onCheckoutCompleted() {
    // We only load the heavy PaymentGatewayService when the user actually checks out!
    const paymentGateway = await this.paymentGatewayLoader();
    await paymentGateway.processTransaction();
  }
}

Building a Dashboard with Angular 22

Instead of just explaining features, let’s build a practical dashboard example that uses the stable core of Angular v22: @Service(), httpResource() and the new template syntax.

Want to follow along? You can clone the complete project from GitHub: angular-22-nba-finals. Just run npm start and you’ll have the dashboard running locally.

The Data Service with @Service

Now, let’s create our service. We will use the new @Service() decorator (which replaces @Injectable()) and httpResource to fetch the games. Notice how httpResource handles loading and error states for you.

// src/app/nba.service.ts
import { Service } from '@angular/core';
import { httpResource } from '@angular/common/http';

export interface NbaGame {
  id: number;
  gameNumber: number;
  homeTeam: string;
  homeScore: number | null;
  awayTeam: string;
  awayScore: number | null;
  status: 'Final' | 'Scheduled';
  date: string;
  location: string;
}

@Service()
export class NbaService {
  // httpResource is the standard for fetching data
  gamesResource = httpResource<NbaGame[]>('/api/nba-finals');
}

The UI Layer & Error States

We display the data using the new @for block and keep the error handling inside the component template. This keeps the example focused on stable Angular v22 behavior.

// src/app/app.ts
@Component({
  template: `
    
    
  `
})

Our Dashboard component remains simple:

// src/app/dashboard.component.ts
import { Component, inject } from '@angular/core';
import { NbaService } from './nba.service';

@Component({
  selector: 'app-dashboard',
  template: `
    
      NBA Finals 2026: Knicks vs Spurs

      @if (nbaService.gamesResource.isLoading()) {
         Loading game data...
      } @else {
        
          @for (game of nbaService.gamesResource.value(); track game.id) {
            
              Game {{ game.gameNumber }} • {{ game.date }}
              
                {{ game.homeTeam }} {{ game.homeScore }} vs {{ game.awayScore }} {{ game.awayTeam }}
              
              {{ game.status }}
            
          }
        
      }
    
  `
})
export class DashboardComponent {
  nbaService = inject(NbaService);
}

Save changes and run ng server navigate in the browser and tada!!!

Done!! We play with the stable part of Angular v22 using @Service() for a clean singleton service definition, httpResource() for declarative, signal-based HTTP loading and @for with @if in templates to render loading and data states.

And, of course, AI is not forgotten by the Angular team. They updated and added new tools for Angular MCP and Skills. Let’s see them!

Angular MCP and Skills

Of course, Angular continues embracing AI. The Angular MCP exposes app state and builds workflows for tools that understand Angular projects. That includes server-side MCP tools such as devserver.wait_for_build, devserver.start and devserver.stop.

Version 22 also introduces Agent Skills for Angular, a lightweight set of skill definitions that give AI assistants direct knowledge of modern Angular idioms and best practices. These skills are useful for teams that want to integrate agent-assisted coding into their workflow without pain.

Learn more about Angular MCP: angular.dev/ai/mcp
Learn more about Agent Skills for Angular: github.com/angular/skills

Recap

Angular 22 is a declaration that the way we build for the web has evolved. And by using Signals, OnPush performance and declarative async resources, we can build applications that are faster, simpler and easier to maintain.

This release is about making stable patterns:

Use httpResource() for fetch-heavy components.
Use @Service() for singleton services.
Use injectAsync() when you want to defer heavy service loading.
Let template syntax like @for and @if keep your view code readable.
Embrace the AI era with Agent Skills and MCP tools.

My advice is don’t just read this article—build something! Take the dashboard we sketched and turn it into an interactive experience with Progress Kendo UI for Angular AI Chat. A chat interface is a powerful way to explore the series score in real time and it’s a great way to test Angular 22 with a modern Kendo UI scenario.

Feel free to watch for all the new features in Angular 22:

For a complete overview and to verify all the new features, you can check the official release post: Announcing Angular v22.

Happy coding!

Angular Grid at Scale: How Kendo UI Handles Millions of Rows

2026-04-21T16:17:26Z

Let’s say the Monday after the Super Bowl, your boss wants to see a dashboard list of the more than 120 million people who watched it. (The reality of this situation does not matter. Just go with it!) Your boss says, “The dashboard needs to show every connected viewer in real time. A grid. Sortable. Filterable. And it can’t be slow.”

You open your code editor, create an HTML table, and try to render one million rows. The browser freezes. The tab crashes. Your Monday just got worse.

You need to display large amounts of data in a grid without killing the browser. The trick is simple: don’t render what the user can’t see.

This is where virtual scrolling comes in. Instead of creating a DOM element for every single row, you only render the rows visible on screen, plus a few extra. The user scrolls smoothly through millions of records, each new batch loading in as needed, and the browser stays fast and responsive.

Let’s do it together! Today, we will build a Super Bowl Dashboard in Angular. We will see how to handle one million viewers using Progress Kendo UI for Angular Grid. We will start with a simple table, see why it fails and then fix it using virtual scrolling and server-side data fetching.

Let’s make this work in a real project.

Setting Up the Project

First, create a new Angular application by running the command:

ng new superbowl-dashboard

Navigate to the project:

cd superbowl-dashboard

Now install the Angular Grid. The ng add command handles dependencies and theme configuration for us:

ng add @progress/kendo-angular-grid --skip-confirmation

This installs the grid package and its peer dependencies and sets up the Kendo UI default theme.

Once the installation is done, we need to activate our Kendo UI license. This step removes the watermark and unlocks all the features.

Don’t have a license? Don’t worry! You can get a completely free trial with no credit card required, so you can follow along and build the dashboard without worrying about the watermark.

To do this, download the license key file from your Telerik account. Then, run this command inside your project folder:

npx kendo-ui-license activate

Because the Kendo UI Grid is so robust, it includes many features that can slightly increase the initial bundle size. We need to prevent Angular from throwing a “bundle initial exceeded maximum budget” error when we run or build an app. Open the angular.json file and increase the budgets config for the initial type to around 5MB for warnings and 10MB for errors.

Perfect! We have a fresh Angular project with Kendo UI Grid installed and styled. Now let’s generate our Super Bowl viewers’ fake data.

Generating One Million Viewers

Before we start with the grid, we need data. We’ll create a single service that handles everything: generating fake viewer data for client-side demos and simulating a paginated server API for server-side scrolling.

To create the service, open the terminal and run the following Angular CLI command:

ng g s services/viewer

First, we will define a simple Viewer interface so our grid knows what fields to expect. Then, our service will include a generateViewers method to create mock data, and a fetchPage method that simulates a paginated server API. We won’t use fetchPage right away, but it will be ready for when we implement server-side virtual scrolling later.

Don’t worry too much about the exact implementation of the helper methods; the main idea here is not how to generate fake users, but how to create a grid capable of supporting massive amounts of data without breaking a sweat!

Open src/app/services/viewer.ts and add the following:

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

export interface Viewer {
  id: number;
  username: string;
  watchTimeMin: number;
  isLive: boolean;
}

export interface PagedResult {
  data: Viewer[];
  total: number;
}

const ADJECTIVES = [
  "Swift",
  "Lucky",
  "Bold",
  "Chill",
  "Epic",
  "Happy",
  "Lazy",
  "Wild",
  "Cool",
  "Fast",
];

const NOUNS = [
  "Fan",
  "Eagle",
  "Tiger",
  "Bear",
  "Wolf",
  "Hawk",
  "Fox",
  "Lion",
  "Shark",
  "Bull",
];

@Injectable({ providedIn: "root" })
export class ViewerService {
  private readonly TOTAL_VIEWERS = 1_000_000;

  generateViewers(count: number, startId = 0): Viewer[] {
    const viewers: Viewer[] = [];

    for (let i = 0; i < count; i++) {
      viewers.push({
        id: startId + i + 1,
        username: `${this.randomFrom(ADJECTIVES)}${this.randomFrom(NOUNS)}${this.randomBetween(1, 9999)}`,
        watchTimeMin: this.randomBetween(1, 240),
        isLive: Math.random() > 0.08,
      });
    }

    return viewers;
  }

  /**
   * Simulates a server API call with pagination.
   * Uses a small delay to mimic real network latency.
   */
  async fetchPage(skip: number, take: number): Promise<PagedResult> {
    await new Promise((resolve) => setTimeout(resolve, 80));

    return {
      data: this.generateViewers(take, skip),
      total: this.TOTAL_VIEWERS,
    };
  }

  private randomFrom<T>(arr: T[]): T {
    return arr[Math.floor(Math.random() * arr.length)];
  }

  private randomBetween(min: number, max: number): number {
    return Math.floor(Math.random() * (max - min + 1)) + min;
  }
}

Each viewer has a fun auto-generated username (like SwiftEagle4821), their watch time and a live status. The fetchPage method is an async function that simulates a paginated API with a small delay to mimic network latency. We’ll use generateViewers first and come back to fetchPage later.

With our service ready, let’s see what happens when we try to render all these viewers at once.

The Problem: Rendering All Rows at Once

Let’s try to do it and experience the problem firsthand. Open src/app/app.ts and replace its content:

import { Component, inject, signal } from "@angular/core";
import { CommonModule } from "@angular/common";
import { ViewerService, Viewer } from "./services/viewer";

@Component({
  selector: "app-root",
  standalone: true,
  imports: [CommonModule],
  templateUrl: "./app.html", 
})
export class App {
  private viewerService = inject(ViewerService);
  viewers = signal<Viewer[]>([]);

  loadViewers(count: number): void {
    const data = this.viewerService.generateViewers(count);
    this.viewers.set(data);
  }
}

Now, let’s open our template file, src/app/app.html and add a few buttons for 1K, 10K and 100K viewers. These buttons will call our loadViewers() method to quickly generate different amounts of fake data.

Finally, we’ll use the component in our template. The key property to pay attention to is [data]="viewers()", which tells Kendo UI to read from our reactive signal and constantly display the list of viewers.

<h1>Super Bowl Viewers Dashboardh1>
<p>Connected viewers: {{ viewers().length.toLocaleString() }}p>

<div class="actions">
  <button (click)="loadViewers(1_000)">1K Viewersbutton>
  <button (click)="loadViewers(10_000)">10K Viewersbutton>
  <button (click)="loadViewers(100_000)">100K Viewersbutton>
  <button (click)="loadViewers(1_000_000)">1M Viewersbutton>
div>

<div class="grid-container" style="height: 600px; overflow: auto;">
  <table border="1" style="width: 100%; border-collapse: collapse;">
    <thead>
      <tr>
        <th>#th>
        <th>Usernameth>
        <th>Watch (min)th>
        <th>Liveth>
      tr>
    thead>
    <tbody>
      @for (viewer of viewers(); track viewer.id) {
      <tr>
        <td>{{ viewer.id }}td>
        <td>{{ viewer.username }}td>
        <td>{{ viewer.watchTimeMin }}td>
        <td>{{ viewer.isLive ? 'Yes' : 'No' }}td>
      tr>
      }
    tbody>
  table>
div>

Now we can run our app. Go to the terminal and execute the following command:

ng serve

This will start the local development server. Once it finishes compiling, open your browser and navigate to http://localhost:4200.

Click “1K Viewers” and it feels smooth. Click “10K Viewers” and you will notice a significant lag.

Now click “100K Viewers” … and watch the browser scream for help. The page will freeze, the scroll will be jumpy and you might even get the “Page Unresponsive” dialog.

We have seen the problem: standard HTML tables and simple loops cannot handle huge datasets. When you click the 1M Viewers button, the browser stops working.

OK, but how can we fix this?

The Solution: Angular Grid withVirtual Scrolling

If you read about Kendo UI, you know the Kendo UI Grid, but before we to start to use it, I want to explain “virtual scrolling.” Think of virtual scrolling like a camera moving over a big stadium. You only see the seats in the camera frame, maybe 50 seats. The stadium has 1,000,000 seats, but the camera doesn’t need to show all of them at once. It only shows what is visible.

Kendo UI Grid does exactly this with one property: scrollable="virtual". Let’s use it.

First, update your app.ts. We need to import KENDO_GRID and remove the CommonModule because the grid will handle everything now:

import { Component, inject, signal } from "@angular/core";
import { KENDO_GRID } from "@progress/kendo-angular-grid";
import { ViewerService, Viewer } from "./services/viewer";

@Component({
  selector: "app-root",
  imports: [KENDO_GRID],
  templateUrl: "./app.html", 
})
export class App {
  private viewerService = inject(ViewerService);
  viewers = signal<Viewer[]>([]);

  loadViewers(count: number): void {
    const data = this.viewerService.generateViewers(count);
    this.viewers.set(data);
  }
}

Now, let’s update src/app/app.html. We will replace the standard

with the component:

<h1>Super Bowl Viewers Dashboardh1>
<p>Connected viewers: {{ viewers().length.toLocaleString() }}p>

<div class="actions">
  <button (click)="loadViewers(10_000)">10Kbutton>
  <button (click)="loadViewers(100_000)">100Kbutton>
  <button (click)="loadViewers(1_000_000)">1Mbutton>
div>

<kendo-grid
  [data]="viewers()"
  [height]="600"
  scrollable="virtual"
  [rowHeight]="36"
  [pageSize]="50"
>
  <kendo-grid-column field="id" title="#" [width]="70">kendo-grid-column>
  <kendo-grid-column field="username" title="Username" [width]="180">kendo-grid-column>
  <kendo-grid-column field="watchTimeMin" title="Watch (min)" [width]="110">kendo-grid-column>
  <kendo-grid-column field="isLive" title="Live" [width]="70">kendo-grid-column>
kendo-grid>

Why Does This Work?

We added three important properties to the to make it fast:

scrollable="virtual": This tells Kendo UI: “Don’t create all the rows at once. Only create the ones the user can see right now.”
[rowHeight]="36": The grid needs to know exactly how tall each row is. This helps the grid calculate the scroll position correctly.
[pageSize]="50": This is how many rows Kendo UI keeps in the DOM. A good tip: set this to 3 times the number of rows visible on your screen.

Now, if you click the buttons, you will see that a page with 10,000, 100,000 or even one million viewers scrolls smoothly. The browser is fast because only ~50 rows are in the DOM at any time.

Kendo UI Grid does all the hard work for the rendering.

But there is one more problem. We fixed the rendering, but we are still loading one million records into the browser’s memory. For a real app, loading 1,000,000 records at once is a bad idea. It uses too much RAM and it is slow to start.

What if we want to show one million users in real-time without using all the RAM? Let’s use the final solution: Server-Side Data Fetching.

Server-Side Data Fetching with Endless Scrolling

Here’s the reality: the Super Bowl has 120 million viewers. We can’t load all of them into the browser at once. Instead, the grid should fetch data page by page as the user scrolls , loading only what’s needed, when it’s needed.

Kendo UI Grid supports this out of the box with the scrollBottom event. When the user scrolls to the bottom of the current data, the grid fires this event, and we simply fetch the next page and append it. Let’s build it!

Generate a new component by running the command in the terminal:

ng g c components/live-grid

Open src/app/components/live-grid/live-grid.ts and replace the content with:

import { Component, inject, signal, ChangeDetectionStrategy } from "@angular/core";
import { KENDO_GRID } from "@progress/kendo-angular-grid";
import { ViewerService, Viewer } from "../../services/viewer";

@Component({
  selector: "app-live-grid",
  imports: [KENDO_GRID],
  templateUrl: "./live-grid.html",
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class LiveGrid {
  private viewerService = inject(ViewerService);

  isConnected = signal(false);
  loading = signal(false);
  viewers = signal<Viewer[]>([]);
  pageSize = 1_000;

  connect(): void {
    this.isConnected.set(true);
    this.loadMore();
  }

  onScrollBottom(): void {
    if (this.loading()) return;
    this.loadMore();
  }

  private loadMore(): void {
    this.loading.set(true);
    
    this.viewerService.fetchPage(this.viewers().length, this.pageSize).then((result) => {
      this.viewers.update((current) => [...current, ...result.data]);
      this.loading.set(false);
    });
  }
}

The logic here is straightforward. First, connect() starts the process by fetching the initial data page using loadMore(). Then, whenever the user scrolls to the bottom of the grid, the (scrollBottom) event fires, triggering onScrollBottom() to fetch and append the next chunk of data to our viewers signal.

To make this work in the UI, we just need to set scrollable="scrollable" on our Kendo Grid to enable endless scrolling, and bind our loading signal to show a skeleton animation during the fetch.

Now let’s build the template in src/app/components/live-grid/live-grid.html to tie all of this together:

<h2>Live Server Feedh2>
<p>Viewers: {{ viewers().length }}p>

<button (click)="connect()" [disabled]="isConnected()">Connect to Live Feedbutton>

@if (isConnected()) {
<kendo-grid 
    [data]="viewers()" 
    [height]="600" 
    scrollable="scrollable"
    [loading]="loading()"
    (scrollBottom)="onScrollBottom()">
    <kendo-grid-column field="id" title="#" [width]="70">kendo-grid-column>
    <kendo-grid-column field="username" title="Username" [width]="180">kendo-grid-column>
    <kendo-grid-column field="watchTimeMin" title="Watch (min)" [width]="110">kendo-grid-column>
    <kendo-grid-column field="isLive" title="Live" [width]="70">kendo-grid-column>
kendo-grid>
}

Wire the component into the app. Update app.ts:

import { Component } from "@angular/core";
import { LiveGrid } from "./components/live-grid/live-grid";

@Component({
  selector: "app-root",
  imports: [LiveGrid],
  templateUrl: "./app.html",
})
export class App {}

And src/app/app.html:

<h1>Super Bowl Viewers Dashboardh1>
<app-live-grid />

Run ng serve, open http://localhost:4200 and click “Connect to Live Feed.”

You’ll see the grid load the first 1,000 viewers. Now scroll down. When you reach the bottom, the grid fetches the next 1,000 viewers and appends them and the loading skeleton appears briefly while data is being fetched. Keep scrolling, and watch the viewers counter grow until it gets to 1,000,000. Yeah!!

Recap

We saw the problem: rendering thousands of rows at once makes the browser freeze. Then we added Kendo UI virtual scrolling with scrollable="virtual". This is the secret to showing large datasets without crashing.

Finally, we used server-side data fetching with the (scrollBottom) event. The grid loads data page by page. This keeps the memory usage low and the experience smooth.

In your next challenge don’t worry about the data, Kendo UI Grid makes it easy. With a few properties, your dashboard can handle millions of rows. ✌

Give it a try for free!

Try Kendo UI for Angular

Happy coding!

Source Code: https://github.com/danywalls/kendo-grid-large-app

Telerik Blogs | Web | Angular

Moving to Angular Zoneless

What Are NgZone and ZoneJS?

How Does Zoneless Change Detection Work?

Build a Zoneless Product Dashboard

Step 1: Create the Angular Project

Zoneless in Angular 22

What About Older Angular Versions?

Step 2: Install Kendo UI Components

Step 3: Fetch Products with httpResource

Step 4: Connect Kendo UI Components with Signals

Test Zoneless Components

Common Migration Issues

A Timer Changes State But the UI Does Not Update

A Manual RxJS Subscription Leaves a Stale View

A Third-Party Widget Does Not Notify Angular

A Practical Migration Path

Recap

Open Challenge

Using Kendo UI with Svelte

TL;DR

✔️ Svelte with Kendo UI for jQuery

Create a New SvelteKit Project

Install Packages

Activate Kendo UI

Create a jQuery Declaration File

Dynamically Import jQuery on the Browser

Handle CSS

Load a Grid Element

Create a Loader

✔️ Kendo UI in Astro

Install Astro

Choose Your Kendo UI Framework

Install Dependencies

Configure CSS

Activate Your Kendo UI License

Create Svelte Component

Create our Grid Component

Load Vue with Svelte

Resources

Try Kendo UI

Ready with WebMCP: Building Agent-Ready Apps with Telerik and Kendo UI

What Is WebMCP?

Using Telerik and Kendo UI AI Tools for WebMCP

Preparing Your Browser

1. Enable the Browser Flag

2. Install and Configure the Telerik WebMCP Extension

The Starting Point: Our Existing NBA Scout Dashboard

Testing the App as a Human User

The Problem: How an AI Agent Sees Our App Today

Making the Existing Application Agent-Ready

Install @progress/kendo-angular-webmcp

Step 2: Import KENDO_WEBMCP in the Component

Add the kendoWebMcp Directive to the Grid

What Just Happened Here?

Interacting with the AI Agent

Verifying the Tools

Recap

The 10 Best Angular UI Chart Libraries

The Scenario

1. Kendo UI for Angular Charts

Why Kendo UI Charts Is the Best Choice IMO

2. Chart.js with ng2-charts

3. Apache ECharts

4. Highcharts Angular

5. FusionCharts Angular

6. ApexCharts Angular

7. D3.js with Angular

8. ngx-charts

9. Syncfusion Angular Charts

10. Plotly.js

Recap

Do You Want to Try It?

Angular State Management: From Local Signals to NgRx SignalStore

Setting Up the Project

Configuring Polyfills

Project Structure

Accounting Dashboard

What Problem Does State Management Solve?

Local State with Signals