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 <kendo-textbox> 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: `
    <kendo-textbox
      [value]="searchTerm()"
      (valueChange)="searchTerm.set($event)"
      placeholder="Search entries..."
      [clearButton]="true"
    />

    <p>Showing {{ filteredCount() }} of {{ entries().length }} entries</p>

    @for (entry of filteredEntries(); track entry.id) {
      <div>
        {{ entry.date }} - {{ entry.description }}: {{ entry.total | currency }}
      </div>
    } @empty {
      <p>No entries found.</p>
    }
  `
})
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 <kendo-dropdownlist> 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: `
    <h3>New Journal Entry</h3>

    <label>Revenue Account:</label>
    <kendo-dropdownlist
      [data]="revenueAccounts()"
      textField="name"
      valueField="code"
      [valuePrimitive]="true"
      [defaultItem]="{ code: '', name: 'Select account...' }"
      (valueChange)="onSelectAccount($event)"
    >
    </kendo-dropdownlist>

    @if (selectedAccount(); as acct) {
      <p>Selected: {{ acct.name }} - {{ acct.type }}</p>
    }
  `
})
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?

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:

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

1. 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.
2. Signals and services are the new default. Most data does not need a complex store.
3. Use classic NgRx only for complex problems. If you need a clear history of changes or DevTools, the extra code is worth it.
4. 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.

When a product or tool is a crucial part of your application, support is more than just a nice-to-have. For enterprise development teams, support issues could mean anything from a single blocked developer to an entire delayed release. The larger and more critical the application, the more important predictable access to technical expertise becomes.

So rather than simply saying Progress provides strong Telerik and Kendo UI support, here are the numbers behind it—customer satisfaction, response and resolution times, escalation rates and the technical resources available beyond a simple or individual support case.

Support at a Glance

• 98%+ customer satisfaction on case closure
• 95.5%+ customer satisfaction per interaction
• 24-hour response-time Service Level Agreement (SLA)
• 50%+ of cases resolved within 14 hours
• <14 hours median time to first response
• ~99.8% of tickets resolved without escalation
• New AI-powered chat embedded in ticket submission and documentation to provide instant answers

What Does Enterprise-Grade Support Mean?

Enterprise-grade technical support combines predictable response commitments, access to technical expertise, efficient issue resolution and self-service resources that help teams resolve problems without creating prolonged development blockers.

Technical Support from Technical Engineers

We believe that good support is part of the product experience. Our technical support engineers bring hands-on expertise, helping teams get from problem to solution without unnecessary delays or layers of escalation. Telerik Technical Support Engineers are technical specialists with software development expertise, equipped to investigate implementation-level issues rather than simply triage and route them. Approximately 99.8% of support tickets are resolved within Technical Support without requiring escalation to product engineering.

Fast Turnaround

We also understand that when a project is blocked, timing is of the essence. That’s why our support teams provide a 24-hour response-time SLA—but most of the time, you won’t even have to wait that long. Our median time to first response is under 14 hours.

In fact, over half of support cases are resolved within 14 hours, helping teams move from problem to solution quickly. Most issues also stay with the support organization rather than requiring engineering escalation. And by “most,” I mean “very nearly all”: approximately 99.8% of tickets are resolved without escalation.

Exceptional Customer Satisfaction

More than 98% of customers report satisfaction at case closure, and a 95.5%+ CSAT score (Customer Satisfaction) per interaction reflects high quality throughout the support experience.

What About Support Beyond Tickets?

Support is about more than just answering one-off tickets, though. That’s why we offer a massive collection of technical knowledge that helps developers across the community—whether they’re troubleshooting a problem, learning a feature, evaluating an API or looking for implementation examples. Those resources mean that developers may not even need to open a support ticket in the first place! The vast library of public technical knowledge empowers developers with the knowledge they need, saving direct technical support for unique and specific edge case instances.

Available Public Technical Knowledge

• 290K+ answered forum threads
• 6.5K+ knowledge base articles
• 10K+ demos
• 24K+ conceptual documentation articles
• 29K+ API reference articles.
• 100+ answered community questions each month

These resources are publicly searchable and indexable, which allows the impact of our excellent support to scale far beyond what could be offered via tickets alone. Developers can benefit from solutions documented through years of customer and community interactions, while organizations can build their own expertise on top of a large, accessible body of technical knowledge.

What Our Customers Say

The numbers are impressive, but what matters more to us is what our customers have to say about their support experiences. These are just a small sample of quotes from users who have worked with our support teams and had wonderfully positive experiences.

Clear Instructions

“I’m incredibly grateful for the technical assistance I received. The support was not only timely but also highly effective—resolving my issue quickly and professionally. The guidance was clear and spot-on, helping me identify the missing step and implement the correct solution without delay. Thanks to this help, everything is now working perfectly. I truly appreciate the responsiveness and expertise. This kind of support makes a huge difference!”

High-Quality Responses

“Your developer support is AWESOME! I can’t imagine moving to another control suite. You guys are the best!”

Fast and Detailed

“Prompt and on-point with all of our communications. I appreciate the detailed responses and explanations!”

Going the Extra Mile

“Spent extra time making sure I had the resources and information to fix my problem […] created an example project and code snippets. Thank you so much!

Better Support Means Better End Products

Faster access to expert assistance can reduce delivery risk by helping developers resolve blockers before they become prolonged delays. Strong technical support and a comprehensive knowledge base also reduces engineering time spent troubleshooting, searching for answers, going in circles with AI chatbots or developing brittle workarounds—lowering the total cost of ownership over time. Support is, therefore, not simply a service attached to the product; it's part of the risk assessment that teams should evaluate when choosing a partner they expect to rely on for years.

Enterprise teams working with Telerik and Kendo UI can have confidence that when a problem arises, there’s a reliable solution—and an experienced team behind the technology, just waiting to help.

FAQ

How Quickly Does Telerik Technical Support Respond?

Telerik Technical Support includes a 24-hour response-time Service Level Agreement (SLA), but our median time to first response is less than 14 hours.

How Quickly Are Telerik Support Cases Resolved?

Over half of cases are resolved within 14 hours, with less than 1% requiring escalation.

Are Telerik Support Cases Handled by Technical Experts?

Yes, Telerik Technical Support Engineers are technical specialists with software development expertise, equipped to investigate implementation-level issues rather than simply triage and route them.

What Self-Service Support Resources Does Telerik Provide?

Our library of self-support technical knowledge resources includes extensive community forums with over 290k answered threads, over 6.5k Knowledge Base articles, over 10k demos, over 24k conceptual documentation articles, over 29k API reference articles and more than 100 new community questions answered each month.

Want to See for Yourself?

Our 30-day free trials include access to support. The Telerik DevCraft suite lets you pick your favorite flavor, so check it out:

Try DevCraft

The legal profession is going through enormous changes, some driven by changes in the business (e.g., outsourcing) and some by technology (AI). As a result, applications created for legal professionals like lawyers and paralegals have to reflect and support those changes.

For example, thanks to outsourcing, AI and more sophisticated third-party software, the amount of time a legal professional spends on research (once a key skill in the field) is shrinking. In the same way, legal professionals are now spending less time drafting legal documents (another formerly critical skill) and more time reviewing/correcting the products of various software systems.

Many things in the profession have not changed, of course. Today’s legal professionals still need to be able to understand their clients’ needs and analyze the issues each client faces. Legal professionals must provide solutions that are attainable while meeting their clients’ needs and be able to communicate the resulting courses of action (with their risks) both to their clients and the other parties involved.

Actually, here’s an interesting survey of legal professionals that the Progress ShareFile team put together. Lawyers love the work they do—but many still face workflow friction that slows client service, delays intake and creates unnecessary complexity. Of the participating legal professionals surveyed:

• 97% say AI and automation will be important to the future of legal
• 84% say workflow inconsistencies impact efficiency
• 95% want tools that are simple and easy to use

When it comes to executing the selected actions, much remains the same: filing deadlines remain critical, as do keeping clients compliant with relevant laws and advocating for clients’ interests in criminal and civil cases.

While the business has changed, clients have also changed and are increasingly using self-serve and lower cost options (e.g., community legal workers). When working with legal professionals, clients are increasingly assessing their experience by how the client’s interaction is personalized and customized to their needs. As a result, legal professionals are moving away from traditional hourly based billing toward value-based billing and are increasingly focused on efficiency.

The net result is an increased demand for “legal services” (contract life cycle management, for example) instead of “legal advice” like routine contract negotiation.

The Progress Telerik and Kendo UI DataGrid is an essential part of building applications that support those changing needs.

Retrieving and Finding Documents

For example, a legal case still involves thousands of documents: client records, meeting notes, case files, pleadings, affidavits, court filings, expert reports and more. Most of those documents are now digital assets, stored in various repositories that can be accessed through the DataGrid. Using the DataGrid’s virtualization features enables users to retrieve and review large numbers of documents quickly—essential in being responsive to clients’ needs.

The DataGrid offers multiple tools for filtering, sorting and searching for specific documents. Professionals can find documents by specific clauses, case IDs or document types, even across large repositories. The DataGrid AI-enabled Semantic Search even lets users find records just by typing in what they want (e.g., “Show me all the active cases”).

Once the relevant document is found, professionals can have multiple options in reviewing the document, depending on their needs. Documents can be viewed in the DataGrid, of course, but can also be reviewed in popup windows to show key information without leaving the current screen. Or users can navigate to a separate screen to view the document in full.

Organizing Documents and Data

Given the variety of documents, the DataGrid’s ability to organize those documents into groups is critical. The DataGrid can be configured to provide a predefined set of groups, and users can create their own groups as they need them by dragging and dropping columns in the grid.

Going beyond simple groups, the DataGrid can be configured as a hierarchy of document groups to organize documents by whatever criteria the user needs. Because the DataGrid has the ability to nest grids with different layouts within, for example, a document hierarchy, different document types can be displayed with different formats.

Some things remain constant, though. Even in the evolving world of legal professionals, time remains of the essence. While nunc pro tunc (“now for then”) can apply, it remains essential for filings to be made on time and correctly. DataGrid templates enable users, without leaving their current screen, to switch between a document-oriented view and a time-based view to see what’s pending (and conditional formatting can be used to highlight filings that still need development).

The DataGrid’s ability to organize any kind of data, in any order, to support any analysis is also essential to supporting the way the profession is evolving. Businesses now expect their legal departments to not only find ways to manage legal risk but also to provide strategic insights to improve revenues and decrease costs. Legal professionals increasingly need tools—like the DataGrid—that support exploring data to help them provide those insights.

For example, in the contract management area, clients now expect their legal representatives to be able analyze past performance of various terms in contracts to identify opportunities both for improving future contracts and renegotiating existing contracts (or identifying contracts that can’t be improved and should be terminated).

Sharing Data

Client confidentiality remains a key concern in any interaction with a legal professional. The DataGrid’s ability to integrate with code that authenticates and authorizes users to control access to data helps provide that. The DataGrid’s UI supports hiding columns, hiding whole rows and formatting individual cells hide information, all driven by the user’s authorized roles.

On the other hand, legal information often needs to be shared with others (courts, clients, other members of the office, opposing counsel). The DataGrid supports exporting selected rows or the whole grid in both Excel and PDF formats (these options can also be turned off to help prevent data from leaving the application’s secure environment). Any hidden rows, columns and obfuscated data remain hidden during export and, where necessary, custom code can be inserted into the export process to further control the process.

Updating Information

While reporting data is important, the DataGrid also provides excellent support for updating information efficiently. Users can update single rows, enter a “bulk update” mode that supports updating multiple rows, open popup windows for individual rows to improve the update experience or navigate from the DataGrid to full screen editing for any row.

The DataGrid also provides built-in validation to help prevent invalid data being entered and supports both synchronous validation (stopping the user from continuing until data is validated) and asynchronous validation (allowing the user to continue when validation is time-consuming but preventing updates when the user tries to save their data). Validation can be extended with custom code that can take advantage of the DataGrid’s error-handling support (displaying error messages in tooltips, for example).

In addition to providing multiple shortcuts that enable experienced users to work efficiently, the DataGrid supports WCAG accessibility guidelines out of the box. For occasional users, the DataGrid’s various assistants (AI Toolbar Assistant, AI Column Assistant, etc.), let users perform complex operations with natural language commands.

As the legal profession changes, the applications that support legal professionals must also change. The Telerik and Kendo UI DataGrid gives you the ability to support those evolving needs.

Check out the Telerik DevCraft suite of products to learn about the DataGrid in your favorite .NET or JavaScript flavor, like the Blazor Grid or the Angular Grid.

Get your hands on the whole suite free for 30 days:

Try Telerik DevCraft

A while back, I wrote about How to Manage Composition API Refs in Vue 3 When Unit Testing, and more recently we’ve been working through the TanStack Query series, finishing up with mutations and pagination.

Now we get to the part nobody really wants to write but that pays for itself the first time a refactor doesn’t break in production: tests. Testing components that use TanStack Query has a few specific gotchas that don’t really come up with regular Vue components, and I want to walk through how I usually approach it.

What Makes TanStack Query Tricky to Test?

A normal component test is straightforward: mount the component, assert what’s in the DOM, maybe simulate some clicks, assert again. Done.

A TanStack Query component adds a few wrinkles:

• It needs a QueryClient provided through the app instance. Mount it without one and you’ll get a vague error.
• It does asynchronous work as soon as it mounts, so the very first thing you assert is going to be a loading state.
• The thing it’s asynchronously talking to (fetch, axios, whatever) needs to be mocked, or your tests will hit your real API.
• It caches across renders. If you don’t reset the cache between tests, one test can pollute another.

Each of these is solvable in a couple of lines. The trick is knowing where each line goes.

Setting Up a Test QueryClient

The first thing we need is a way to mount a component with a fresh QueryClient in each test. I usually wrap this in a small helper.

tests/utils/withQueryClient.js

import { mount } from '@vue/test-utils'
import { QueryClient, VueQueryPlugin } from '@tanstack/vue-query'

export const mountWithQuery = (component, options = {}) => {
  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        retry: false,
        gcTime: 0,
      },
    },
  })

  return mount(component, {
    ...options,
    global: {
      ...(options.global ?? {}),
      plugins: [
        ...(options.global?.plugins ?? []),
        [VueQueryPlugin, { queryClient }],
      ],
    },
  })
}

A few things worth pointing out:

• We create a fresh QueryClient for each test. This is critical. If you reuse a single client across tests, the cache from one test bleeds into the next, and you’ll spend an afternoon hunting down phantom failures.
• retry: false disables the default retry behavior. In a test, we want failures to be failures, not “wait three seconds for two more retries before giving up.”
• gcTime: 0 makes sure cached data isn’t kept around. Combined with the fresh client, this gives us proper isolation.

In real codebases, I usually expose this as a helper from a tests/utils/ folder and have my test files import it. Whether you use Vitest or Jest, the shape is the same.

Mocking Fetch

Now for the API. Our component reaches the outside world through fetch, and in a test we absolutely do not want it talking to a real server. So we swap fetch for a stub that returns whatever we tell it to.

Vitest makes this painless with vi.stubGlobal. I set it up once in a global setup file so every test starts with a fresh, fake fetch and the real one gets restored when the test is done.

tests/setup.js

import { afterEach, beforeEach, vi } from 'vitest'

beforeEach(() => {
  vi.stubGlobal('fetch', vi.fn())
})

afterEach(() => {
  vi.unstubAllGlobals()
})

Point Vitest at this file with setupFiles: ['./tests/setup.js'] in your vitest.config.js, and every test gets a clean fetch mock for free.

There’s one slightly annoying detail. fetch doesn’t resolve to your data directly, it resolves to a Response object with .ok, .status, and a .json() method. Since we’ll be building those over and over, a tiny helper keeps the tests readable.

tests/utils/jsonResponse.js

export const jsonResponse = (data, { ok = true, status = 200 } = {}) => ({
  ok,
  status,
  json: async () => data,
})

That’s the entire mocking setup. No extra dependencies, nothing intercepting at the network level, just a fake function that hands back the same shape fetch would.

Writing Your First Test

Let’s put it all together. Imagine we have the following component:

UserList.vue

<script setup>
import { useQuery } from '@tanstack/vue-query'

const fetchUsers = async () => {
  const response = await fetch('https://myapp.com/users')
  if (!response.ok) {
    throw new Error('Failed to fetch users')
  }
  return response.json()
}

const { data, isPending, isError } = useQuery({
  queryKey: ['users'],
  queryFn: fetchUsers,
})
</script>

<template>
  <p v-if="isPending">Loading...</p>
  <p v-else-if="isError">Error</p>
  <ul v-else>
    <li v-for="user in data" :key="user.id">{{ user.name }}</li>
  </ul>
</template>

And here’s the test.

UserList.spec.js

import { describe, it, expect } from 'vitest'
import { flushPromises } from '@vue/test-utils'
import { mountWithQuery } from './utils/withQueryClient'
import { jsonResponse } from './utils/jsonResponse'
import UserList from '../src/components/UserList.vue'

describe('UserList', () => {
  it('shows a loading state and then the user list', async () => {
    fetch.mockResolvedValue(
      jsonResponse([
        { id: 1, name: 'Ada Lovelace' },
        { id: 2, name: 'Grace Hopper' },
      ])
    )

    const wrapper = mountWithQuery(UserList)

    expect(wrapper.text()).toContain('Loading...')

    await flushPromises()

    expect(wrapper.text()).toContain('Ada Lovelace')
    expect(wrapper.text()).toContain('Grace Hopper')
  })
})

Let’s break it down. First we tell our fake fetch what to resolve to (because the setup file stubbed it globally, we can reach for fetch directly). Then we mount the component, immediately assert that the loading state is visible (the query hasn’t resolved yet), flushPromises to let the microtasks run, and finally assert that the list rendered.

flushPromises from @vue/test-utils is the easiest way I’ve found to get past the async boundary. It awaits every queued promise, including the mocked fetch and the reactive update inside TanStack Query. If you forget it, you’ll see the loading state forever and a confused test runner.

If flushPromises isn’t enough (some flows need a few extra ticks), you can also lean on vi.waitFor or the equivalent in your test runner, which retries an assertion until it passes or times out.

Testing the Error Path

Errors are easy to test once the happy path works. We just tell fetch to resolve to a failed response for that one test:

it('shows an error state when the API fails', async () => {
  fetch.mockResolvedValue(
    jsonResponse({ message: 'oops' }, { ok: false, status: 500 })
  )

  const wrapper = mountWithQuery(UserList)
  await flushPromises()

  expect(wrapper.text()).toContain('Error')
})

Notice how our component checks response.ok and throws when it’s false. That thrown error is what flows through TanStack Query into the isError branch, which is exactly what we’re asserting on. This is also why retry: false in our helper matters so much: without it, the query would dutifully retry the failing request a few times before giving up, and your test would crawl.

Because the setup file gives every test a brand-new fetch mock, this mockResolvedValue only affects this one test. Nothing to clean up by hand.

Testing Mutations

Mutations are very similar, but with a twist. Because they don’t fire automatically on mount, we have to actually trigger them. Let’s say we have a component that creates a user when a button is clicked.

CreateUser.spec.js

import { describe, it, expect } from 'vitest'
import { flushPromises } from '@vue/test-utils'
import { mountWithQuery } from './utils/withQueryClient'
import { jsonResponse } from './utils/jsonResponse'
import CreateUser from '../src/components/CreateUser.vue'

it('creates a user when the form is submitted', async () => {
  fetch.mockResolvedValue(
    jsonResponse(
      { id: 1, name: 'Ada', email: 'ada@example.com' },
      { status: 201 }
    )
  )

  const wrapper = mountWithQuery(CreateUser)

  await wrapper.find('input[name="name"]').setValue('Ada')
  await wrapper.find('input[name="email"]').setValue('ada@example.com')
  await wrapper.find('form').trigger('submit')
  await flushPromises()

  const [url, options] = fetch.mock.calls[0]
  expect(url).toBe('https://myapp.com/users')
  expect(JSON.parse(options.body)).toEqual({
    name: 'Ada',
    email: 'ada@example.com',
  })
  expect(wrapper.text()).toContain('User created')
})

Two things to call out. First, because fetch is a vi.fn(), every call is recorded. fetch.mock.calls[0] gives us the arguments of the first call, so we can pull out the URL and the request options and assert against them. We parse options.body back from JSON to confirm the right payload went out the door, not just that something happened. That’s the part of a mutation that actually tends to break.

Second, we’re using two awaits back to back: one for the form submission, and flushPromises to let the mutation’s async work resolve. You’ll see this pattern a lot. When in doubt, throw in another await flushPromises() and see if your assertion passes.

Testing Cache Invalidation

One of the most valuable tests you can write covers the interaction between a mutation and the queries it invalidates. When you create a user, does the list actually refresh? This is the integration that breaks most often, and it’s easy to get subtly wrong: forget invalidateQueries in your mutation or invalidate the wrong key, and the list just sits there showing stale data.

To test it, we mount a page that brings both pieces together. Picture a UserPage that renders the user list and a create form (the form is probably its own child component, but from the test’s point of view we just mount the page and treat it as one unit). We create a user, then assert the new name appears in the list.

This is actually where mocking fetch directly reads quite nicely. The component makes three requests in a known order, so we queue up three responses with mockResolvedValueOnce.

UserPage.spec.js

import { describe, it, expect } from 'vitest'
import { flushPromises } from '@vue/test-utils'
import { mountWithQuery } from './utils/withQueryClient'
import { jsonResponse } from './utils/jsonResponse'
import UserPage from '../src/pages/UserPage.vue'

it('refreshes the user list after creating a user', async () => {
  fetch
    // initial list load
    .mockResolvedValueOnce(jsonResponse([{ id: 1, name: 'Ada' }]))
    // the create mutation
    .mockResolvedValueOnce(
      jsonResponse({ id: 2, name: 'Grace' }, { status: 201 })
    )
    // the refetch triggered by invalidateQueries
    .mockResolvedValueOnce(
      jsonResponse([
        { id: 1, name: 'Ada' },
        { id: 2, name: 'Grace' },
      ])
    )

  const wrapper = mountWithQuery(UserPage)
  await flushPromises()

  expect(wrapper.text()).toContain('Ada')
  expect(wrapper.text()).not.toContain('Grace')

  await wrapper.find('input[name="name"]').setValue('Grace')
  await wrapper.find('form').trigger('submit')
  await flushPromises()
  await flushPromises()

  expect(wrapper.text()).toContain('Grace')
})

Let’s break it down. The three mockResolvedValueOnce calls line up with the exact sequence of requests the page makes: the list loads on mount, the form submission POSTs the new user and then invalidateQueries fires off a fresh GET for the list.

Notice the two flushPromises after the submit. This is the longest async cascade in the article (submit, the mutation resolves, its onSuccess calls invalidateQueries, the list refetches, then the DOM updates), and that’s more hops than a single flush reliably drains.

When a test like this comes out flaky, an extra await flushPromises() is almost always the fix. If you’d rather not count ticks by hand, wrap the final assertion in vi.waitFor(() => expect(wrapper.text()).toContain('Grace')), which retries until it passes or times out.

This test mirrors what an actual user does: see the list, submit a form, see the updated list. It catches a whole class of bug that narrow unit tests don’t, like forgetting invalidateQueries in your mutation or invalidating the wrong key.

I’ve found that having one or two of these per major flow (create, update, delete) catches more real regressions than a hundred isolated component tests.

A Few Conventions That Have Saved Me Hours

• One QueryClient per test: I cannot stress this enough. The fresh-client helper at the top of this article is the single most useful thing I do.
• Disable retries in tests: A failing test that takes nine seconds to fail because of three retries is a debugging nightmare.
• Reach for the happy-path response by default, override per test for the unhappy path: mockResolvedValue for the common case, a one-off mockResolvedValueOnce or mockRejectedValue for the test that needs something different. Keeps each test focused on what’s special about it.
• Don’t try to test internal TanStack Query behavior: If you find yourself writing a test that asserts something about staleTime or refetching, pause. That’s the library’s responsibility, not yours. Test what your component does, not what TanStack Query does.

To be quite honest with you, that last point is the one I see violated the most. People write a test that mocks the whole useQuery composable, then assert that their component “calls useQuery with the right key.” Those tests don’t actually catch any real bugs, they just assert that the code is the code. Mock fetch, not the library.

Wrapping Up

Once you have a mountWithQuery helper, a setup file that stubs fetch and the rhythm of flushPromises, testing TanStack Query components stops feeling weird and starts feeling like regular component testing. You’re back to “render the component, simulate a thing, assert what’s in the DOM.”

For more on the testing side specifically, the official testing guide is worth a read (it’s React-flavored but the patterns translate cleanly), and the Vitest mocking docs are great if you want to go deeper on stubbing globals and inspecting mock calls.

Happy testing!

If you’re part of creating applications in the medical field, many (or most) of your users are going to be medical professionals: trained individuals who are licensed/certified to provide preventative, curative or rehabilitative healthcare to patients. This includes doctors, nurses, paramedics, dentists, their support staff (e.g., pharmacists) and other health professionals (e.g., physiotherapists).

Really, the group of users includes anyone who is certified to provide care (i.e., diagnosing, treating or managing) for either physical or mental illnesses. As broad as that group is, those professionals have a set of shared needs that your application will need to support.

For example, all medical professionals work in evidence-based environments where it’s difficult to have “too much” information … but where it’s essential to find the relevant details quickly. All these professionals (and the applications they use) must also adhere to various regulatory standards, including confidentiality and privacy requirements.

Many medical professionals are working in environments where time is critical and, as result, are environments best described as “high stress”: Too much to do, not enough time to do all of it, and frequent interruptions by new, high priority tasks. Speed and “ease of use” are essential here, but “ease of use” must also include flexibility to meet changing needs.

Finally, as that list of different people suggests, medical professionals work in highly collaborative environments, where they are constantly calling on other professionals in different specialties or departments to support their patients. The ability to share data is also critical.

You can support all those needs with the DataGrid component in your favorite Progress Telerik or Kendo UI library.

Reporting the Data

A medical professional will often need to handle large volumes of complex patient data, sometimes for multiple patients (doctor’s offices, hospital wards) and sometimes for a single patient (reviewing patient history). Because of the time-critical nature of the field, medical professionals need to get to the data quickly either in real time or near real time.

You can leverage the DataGrid OnRead event and support for Observables to load initial data quickly and to respond to changes in the data as those changes happen.

Being able to find “what matters” in large amounts of is also going to be important to your users. Out of the box, the DataGrid allows users to reorder and pin columns, filter data and group data to pull together what matters to them right now.

See, for example, the React Healthcare Management sample app, with a Progress KendoReact DataGrid displaying a filterable list of patients.

However, users will also want to be able quickly switch between DataGrid configurations they use frequently (grouping, column order, filters) rather than have to recreate those configurations from scratch: switching from viewing patient data grouped and sorted by patient or room to seeing the data grouped and organized by time (either historical dates or future activities). You can implement “one-click” switching between those settings by using DataGrid templates, or you can give users the ability to save DataGrid configurations that are useful to them.

Medical professionals are also going to value having key data highlighted as soon as that data is displayed. But you can also use the DataGrid conditional formatting (at the row or cell level) to highlight critical data. In addition, the DataGrid “scroll to item” option lets you programmatically put critical data on the screen for the user to review.

Much medical data is hierarchical in nature (for example, patients in a ward, patients attending a clinic in any time period, a single patient’s medical history). Your users can take advantage of the DataGrid’s ability to define new groups as needed by dragging and dropping columns.

And you can also leverage the DataGrid’s ability to create nested hierarchies to allow your users to view the groups that matter to them as soon as the data is displayed. The DataGrid’s hierarchical display then allows your users to expand those high-level groups to, for example, drill down to individual patients in a ward or to single events in a patient’s medical history.

Regulatory Issues, Sharing Data and Privacy

Out of the box, the DataGrid (in addition to supporting assistive technologies like Jaws and ZoomText) is designed to be compliant with both the Web Content Accessibility Guidelines and the Americans with Disabilities Act accessibility guidelines. But you can also take advantage of the DataGrid’s ability to dynamically hide columns and mask sensitive data to let you control what data is seen by users (based, for example, on the user’s roles as retrieved from whatever authorization system their organization uses).

The DataGrid also integrates cleanly with server-side data processing, enabling you to decide what data you want to keep on the server and what you’re willing to send to the client.

Because medical professionals are working collaboratively with other professionals to deliver patient care, exporting data is often essential. Out of the box, users can easily support export DataGrid data in either CSV or PDF format. Users can choose to export a single page from the DataGrid, export a filtered subset of the data or export all the data in the grid. The DataGrid also supports integrating your own custom code into the export process so that you can control what data is shared, helping to protect sensitive data from leaving the security parameters of your application.

Because of the nature of the data in medical applications, you’ll also want to take advantage of DataGrid protection against Cross-Site Scripting attacks by using the HtmlEncode property to reduce the attack surface of your grid. When interacting with SQL data sources, using the DataGrid’s Parameter elements can help protect your application’s data from SQL injection attacks.

Updating the Data

In the evidence-based environment that medical professionals work in, reporting data is important. Equally important is capturing and recording data quickly without losing accuracy.

Users can rapidly update data within the grid without, for example, having to open a separate form (though you can enable popup forms for individual rows or even navigate to another form in order provide a UI that supports more intensive data entry). The DataGrid supports row-by-row editing to enable updating a single entry in the grid (including locking out cells in a row to prevent inadvertent changes). The DataGrid also support bulk editing that allows the user to update multiple rows before saving their changes with a single button click.

The shortcuts and keyboard navigation built into the DataGrid allow experienced users to move quickly through the grid and update data without having to reach for the mouse. On top of that, the new “smart” AI features in the DataGrid let users enter natural language queries to find or highlight rows that meet the criteria that users provide. The DataGrid has various AI assistants (Chat, Column and Toolbar) to go further in letting users describe what they want the grid to do and have the grid respond without the user having to get involved in the detailed mouse movements.

In a medical environment verifying that only valid entries are made in patient data (including, for example, medication dosages) is essential. The DataGrid has built-in support for validating data entry, including integrating your own custom validation to support maintaining data integrity.

To put it another way: With the DataGrid, you can create applications that integrate with any clinical workflow and provide medical professionals with the tools they need to better meet the needs of their job.

You saw the KendoReact Grid above. Check out the Telerik DevCraft suite of products to learn about the DataGrid in your favorite .NET or JavaScript flavor, like the Blazor Grid or the Angular Grid.

Get your hands on the whole suite free for 30 days:

Try Telerik DevCraft

Displaying data to users is common in web applications. One question you may ask, and which doesn’t always have the same answer, is how to choose the right component to do it.

Would it be appropriate to show a table with all the columns? Or would a card gallery like those used in mobile apps be better?

For that reason, in this article we will analyze the components Blazor ListView and Blazor DataGrid from the Progress Telerik UI library, comparing their features. Let’s go!

The Problem of Choosing the Wrong Component

How we choose to display information in our web application depends on several variables:

• The type of user: A user who requires detailed information about an item is not the same as someone who only needs to see general information.
• The amount of fields to display: Quickly viewing information is not the same as analyzing and comparing data.
• The task to perform with the data: You may need to perform complex operations like grouping, applying filters or making comparisons between them, or you may not.

Not being clear about the purpose of using the information could lead to poor user experiences or make it difficult to work with the data.

Getting to Know the Blazor DataGrid Component

The Blazor DataGrid component allows viewing data in a tabular form. The idea of the component is to display many records in a table format with all the necessary tools for a user to analyze them.

It is a quite robust and flexible component, which in its latest versions incorporates AI features for better data understanding. Among its main capabilities we can find:

• Sorting by one or multiple columns
• Filtering on each column
• Grouping by dragging headers
• Paging with traditional pagination or virtual scrolling
• Inline or popup editing of records
• Resizable, reorderable and lockable columns
• Exporting to Excel and PDF
• Single or multiple selection
• Customization using templates
• Drag & drop support
• Smart AI features that work with natural language queries

From the characteristics described, you can notice that we are talking about a component that should be used when users want to see many rows and fields at the same time and be able to manipulate them.

Some ideal use cases for this component are administrative panels, ERPs, support dashboards, internal tools or any interface where data takes priority over aesthetics.

The Blazor ListView Component

The Blazor ListView component can be considered a freer component than the Blazor Grid. Instead of a tabular structure, the data is provided to you as a context that you can render as you wish. This means you can customize the UI to create cards, timelines, custom rows or any Razor structure you want.

Some of the component’s main features include:

• Customizable built-in paging
• On-demand loading
• Handling of CUD operations through built-in commands
• Custom data source operations
• Fully customizable templates

This component is ideal when the data is not tabular or when the layout needs to adapt to multiple screen styles. Some examples of when to use this component are news feeds, visual catalogs, item galleries, among others.

When to Use a Grid vs. a ListView?

In addition to the analysis we’ve done for each component, I’d like to share some comparative points about when to use a Grid and when to use a ListView.

It’s advisable to use a Grid when:

• You need the user to be able to compare values across rows
• Each record has many fields to be analyzed
• Screen space is not an issue
• You require complex operations such as sorting, filtering or grouping
• You need to edit data in bulk
• You need to export table data

On the other hand, it’s advisable to use a ListView when:

• Records have few fields or are ideal for visually rich interfaces
• User interaction involves viewing items one at a time, not analyzing them
• You need full control over the layout of each item
• You are building some type of app that includes a card-like component or similar

Let’s see how both views look in a real example.

Creating a Blazor Project with ListView and Grid

To demonstrate the difference between the two components and see when it’s convenient to use one over the other, let’s create a component that loads 50 orders and allows switching the view between a ListView-style and a Grid-style.

To achieve this, start by creating a project with the Blazor Web App template, selecting Interactive render mode in Server and Interactivity location in Global. Then, you can follow the official installation guide for Telerik UI for Blazor to install the Telerik components in your project.

Defining the App Data Model

Once the Telerik components are installed in the project, the next step will be to create the data model that represents a sales order in the system. For this, we will use a record type as follows:

public record SalesOrder(
    int OrderId,
    string Customer,
    string Product,
    string Category,
    int Quantity,
    decimal UnitPrice,
    DateTime OrderDate,
    string Status)
{
    public decimal Total => Quantity * UnitPrice;
}

Now, let’s create a service that will generate the fictitious orders.

Creating a Data Service

Let’s create a service class that will be used to generate the fictitious orders. For this, let’s add an interface and its corresponding implementation:

public interface ISalesService
{
    IReadOnlyList<SalesOrder> GetOrders();
}

public class SalesService : ISalesService
{
    private static readonly string[] Customers =
    [
        "Contoso", "Fabrikam", "Adventure Works",
        "Northwind Traders", "Telerik"
    ];

    private static readonly (string Product, string Category, decimal Price)[] Catalog =
    [
        ("Laptop Pro 15",      "Electronics", 1299.99m),
        ("Wireless Mouse",     "Electronics",   45.00m),
        ("4K Monitor",         "Electronics",  399.50m),
        ("Mechanical Keyboard","Electronics",  129.99m),
        ("Running Shoes",      "Clothing",      89.95m),
        ("Winter Jacket",      "Clothing",     159.99m),
        ("Organic Coffee",     "Food",          24.50m),
        ("Premium Tea Box",    "Food",          18.75m),
        ("Office Chair",       "Furniture",    249.00m),
        ("Standing Desk",      "Furniture",    599.00m)
    ];

    private static readonly string[] Statuses =
        ["Pending", "Shipped", "Delivered", "Cancelled"];

    public IReadOnlyList<SalesOrder> GetOrders()
    {
        var random = new Random(42);
        var orders = new List<SalesOrder>();

        for (int i = 1; i <= 50; i++)
        {
            var item = Catalog[random.Next(Catalog.Length)];
            orders.Add(new SalesOrder(
                OrderId: 1000 + i,
                Customer: Customers[random.Next(Customers.Length)],
                Product: item.Product,
                Category: item.Category,
                Quantity: random.Next(1, 10),
                UnitPrice: item.Price,
                OrderDate: DateTime.Today.AddDays(-random.Next(0, 60)),
                Status: Statuses[random.Next(Statuses.Length)]
            ));
        }

        return orders;
    }
}

The code is simple, defining arrays with information that will simulate a business dataset, as well as generating 50 orders by randomly combining the arrays.

To be able to inject the service, we will go to Program.cs, where we will add it as Singleton:

var builder = WebApplication.CreateBuilder(args);
...
builder.Services.AddSingleton<ISalesService, SalesService>();

var app = builder.Build();

With the service ready, we can start with the visual tests.

Preparing the Orders Page

In the Components\Pages folder we will create a new component called SalesOrders.razor, which will look as follows:

@page "/sales-orders"
@using SalesOrderListGridDemo.Services
@using SalesOrderListGridDemo.Models
@rendermode InteractiveServer
@inject ISalesService SalesService

<PageTitle>Sales Orders</PageTitle>

<h1>Sales Orders</h1>

<p>
    Switch between the <strong>ListView</strong> and the
    <strong>DataGrid</strong> using the toggle below.
</p>

<div class="sales-toolbar">
    <TelerikButtonGroup SelectionMode="@ButtonGroupSelectionMode.Single">
        <ButtonGroupToggleButton Selected="@(currentView == ViewMode.ListView)"
                                 SelectedChanged="@(_ => SetView(ViewMode.ListView))">
            ListView
        </ButtonGroupToggleButton>
        <ButtonGroupToggleButton Selected="@(currentView == ViewMode.Grid)"
                                 SelectedChanged="@(_ => SetView(ViewMode.Grid))">
            DataGrid
        </ButtonGroupToggleButton>
    </TelerikButtonGroup>

    <span class="text-muted">@orders.Count orders loaded</span>
</div>

@code {
    private enum ViewMode { ListView, Grid }

    private List<SalesOrder> orders = new();
    private ViewMode currentView = ViewMode.ListView;

    protected override void OnInitialized()
    {
        orders = SalesService.GetOrders().ToList();
    }

    private void SetView(ViewMode view) => currentView = view;
}

In the code of the previous page, you can notice a few things:

• We have created a enum with the options ListView and Grid, which will allow us to switch between views.
• We load the orders into OnInitialized.
• The method SetView allows changing the view.
• We use a Blazor Button Group component, ideal for handling multiple grouped buttons. In this case, we implement it to activate one view or the other through the assignment of a state with Selected. Also, when a button is clicked, SelectedChanged is fired, which invokes the method SetView.

With the options section ready, let’s render the ListView component.

Rendering a Blazor ListView

The next step will be to render the ListView. To do this, we will add a conditional block and use the component TelerikListView:

@if (currentView == ViewMode.ListView)
{
    <TelerikListView Data="@orders"
                     Pageable="true"
                     PageSize="9">
        <Template Context="order">
            <div class="order-card">
                <div class="order-card-header">
                    <span class="order-card-id">#@order.OrderId</span>
                    <span class="status-badge status-@order.Status">@order.Status</span>
                </div>
                <div class="order-card-product">@order.Product</div>
                <div class="order-card-meta">@order.Customer   @order.Category</div>
                <div class="order-card-meta">@order.OrderDate.ToString("MMM dd, yyyy")</div>
                <div class="order-card-footer">
                    <span class="text-muted">@order.Quantity   @order.UnitPrice.ToString("C")</span>
                    <span class="order-total">@order.Total.ToString("C")</span>
                </div>
            </div>
        </Template>
    </TelerikListView>
}

In the previous code, the property Data binds to the service’s list. We configure some additional properties such as paging (Pageable) and number of items per page (PageSize). Also, we use a Template to define a custom view, highlighting only the most important data such as product, customer, category, date, total, etc.

To make the layout look correct, we will add some visual styles in wwwroot/app.css:

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

.order-card {
    border: 1px solid #e2e8f0;
    border-radius: 0.5rem;
    padding: 1rem;
    background: #fff;
    box-shadow: 0 1px 2px rgba(0,0,0,0.04);
    display: flex;
    flex-direction: column;
    gap: 0.5rem;
    height: 100%;
}

.order-card-header,
.order-card-footer {
    display: flex;
    justify-content: space-between;
    align-items: center;
}

.order-card-product {
    font-size: 1.1rem;
    font-weight: 600;
    color: #0f172a;
}

.order-card-meta {
    color: #64748b;
    font-size: 0.9rem;
}

.order-total {
    font-weight: 700;
    color: #0f172a;
}

.status-badge {
    display: inline-block;
    padding: 0.15rem 0.6rem;
    border-radius: 999px;
    font-size: 0.75rem;
    font-weight: 600;
    text-transform: uppercase;
}

.status-Pending   { background: #fef3c7; color: #92400e; }
.status-Shipped   { background: #dbeafe; color: #1e40af; }
.status-Delivered { background: #dcfce7; color: #166534; }
.status-Cancelled { background: #fee2e2; color: #991b1b; }

When running the application, we can see the layout we created using the ListView:

In the image above, you can notice that there is no comparison between orders; rather, there is navigation between the list items. If users wanted to group items, filter them or perform complex operations, this would not be the right component. Let’s now see how to implement a Grid.

Adding a Grid Component to the App

Let’s see how a Grid component looks, completing the else branch of the conditional in the code to add a TelerikGrid:

else
{
    <TelerikGrid Data="@orders"
                 Pageable="true"
                 PageSize="15"
                 Sortable="true"
                 FilterMode="@GridFilterMode.FilterRow"
                 Groupable="true"
                 Resizable="true"
                 Reorderable="true">
        <GridColumns>
            <GridColumn Field="@nameof(SalesOrder.OrderId)" Title="Order #" Width="110px" />
            <GridColumn Field="@nameof(SalesOrder.Customer)" Title="Customer" />
            <GridColumn Field="@nameof(SalesOrder.Product)" Title="Product" />
            <GridColumn Field="@nameof(SalesOrder.Category)" Title="Category" Width="140px" />
            <GridColumn Field="@nameof(SalesOrder.Quantity)" Title="Qty" Width="90px" />
            <GridColumn Field="@nameof(SalesOrder.UnitPrice)" Title="Unit Price" Width="130px" DisplayFormat="{0:C}" />
            <GridColumn Field="@nameof(SalesOrder.Total)" Title="Total" Width="130px" DisplayFormat="{0:C}" />
            <GridColumn Field="@nameof(SalesOrder.OrderDate)" Title="Date" Width="140px" DisplayFormat="{0:d}" />
            <GridColumn Field="@nameof(SalesOrder.Status)" Title="Status" Width="130px" />
        </GridColumns>
    </TelerikGrid>
}

In the previous code we can see the notable difference between the two components:

1. It has parameters like Sortable, Groupable, Resizable, Reorderable, etc., which enable capabilities a user expects in a table-like format.
2. The number of items shown per page is set to 15, because each row takes up less space.
3. If needed, we could customize the columns to display custom content.

When running the application, we will have a result like the following:

In the image above, you can see that we perform operations such as grouping, sorting and filtering rows.

Final Comparison Between Components

Once we have the application assembled and have seen how each component looks, we can reach the following conclusion:

• Use a ListView when you want to treat each record as an individual entity, customizing its visual hierarchy. It is a component intended to be consumed by users.
• Use a DataGrid when you want a spreadsheet-like experience, with operations such as sorting, grouping, filtering, etc. It is a component intended to be operated by users.

Each of the views has a different purpose, although it is possible to combine their use to create mixed experiences.

Conclusion

Throughout this article we have examined the ListView and Grid components from Progress Telerik UI for Blazor. We have discussed the best scenarios for using each of them, as well as the implementation code to use them.

We can conclude that you should use a ListView when the information is intended for end users, requires a high degree of customization and offers a unique exploratory experience.

On the other hand, a DataGrid can be used to display multiple records in a tabular form when operations that enable analysis are needed, such as grouping, sorting, filtering, etc.

Now I invite you to create spectacular experiences using both components. The whole Telerik UI for Blazor library is available in the free 30-day trial, including the ListView and the DataGrid.

Try Now

If you are a financial analyst, your responsibility is to “understand the numbers”—not just in terms of what “the numbers” tell you about the past but what those numbers can tell you about the future. That understanding drives your ability both to make informed decisions yourself and to support others in making informed decisions.

As a financial analyst, you work with a variety of data from multiple sources, some of them external (market information, financial forecasts) and many of them internal (budgets, financial statements and other organization data). Essentially, you turn data into information so that information can drive decisions by becoming business intelligence.

Each of your organization’s applications manages part of your organization’s data and, as a result, can provide data that you need for that process. A data exploration tool, embedded in an application’s user interface or as a standalone tool, can automatically bring together the information for any area of business. That commitment to a set of data can eliminate the time needed to extract, transform and load the data that a more general-purpose financial analysis tool (e.g., Cube) requires. You just open the application and there’s your data, ready for you to work with.

That’s only useful to you, however, if the application’s user interface goes beyond simple transaction management—if the application includes a tool that enables you to work with and explore the data embedded in the application. You need a tool that, among other things, can:

• Work with data from a wide variety of sources
• Handle large amounts of data but remain responsive (you don’t want to have to wait on your data being displayed so that you can work on it)
• Format the data to highlight key issues
• Give you the ability to change the data display as you’re working with the data to support whatever analysis you need
• Integrate support for Large Language Models to let you leverage AI analytics
• Export the data so that you can use it in other tools
• Support looking at the “big picture” while also letting you drill down into the essential detail

And, critically, you need a tool that works “the way you expect” so you don’t have to figure out how to use the tool and can concentrate on the data the grid delivers.

The Progress Telerik and Kendo UI DataGrid does all those things. (See the Blazor DataGrid Demo for example.) Some of those features are available in any implementation of the grid (“works the way you expect,” for instance). Some features will require you to specify to the application’s developers how you want the grid to work.

If, for example, you want the DataGrid to work with a data source that includes lot of rows, you’ll want developers to enable the DataGrid’s “load on demand” feature. Similarly, if you’re going to be working with data that others will be updating, you’ll want your grid to be implemented using observables that let you see those changes as early as possible.

The Initial Display

Typically, for example, you’ll want to have the DataGrid configured so that, as you open the application, the grid retrieves the data that you normally expect to work with. But if you’ll need to look at several different data sources as part of analyzing the data, then you’ll also want to have the DataGrid configured to allow you to dynamically switch to that other data.

For that initial display, you can also have your grid act as a dashboard that highlights cells (or whole rows) that signal key issues. If there are specific values that you want highlighted in the grid, you can have those values built in. But, if you want, you can also have the ability to change the values/thresholds used to highlight the data you’re interested in.

You can, of course, sort the grid’s rows into the order you need. But you can also, at any time, reorder the grid’s columns (or suppress columns) to pull together the data you’re interested right now.

And, also by default, you can filter the grid to show just the rows you need for a particular analysis. You can filter by arbitrary values (e.g., “variances greater than 5%”) or have a checkbox option for specific columns that makes it easier to select the rows you want. The DataGrid’s toolbar also includes a search textbox that you can use to find specific rows.

Supporting Multiple Configurations

That’s already multiple options and, as a result, a lot of opportunities for you to dynamically reconfigure the DataGrid as you’re working with it. Fortunately, you can also have the DataGrid save and restore your configuration settings so that you can quickly switch between different grid configurations as you need them.

AI Support

In the modern world, you’ll also want to decide how much of the grid’s AI support you’ll want to have enabled. The DataGrid gives you multiple ways to access AI processors:

• The AI Toolbar for Data Operations lets you use plain language commands to explore your data through filtering, grouping and sorting
• The AI Toolbar for Highlighting lets you flag rows that meet complicated conditions
• The AI Assistant adds a column to your table with a button that opens an AI prompt window to let you ask any question that makes sense

Grouping and Aggregating Data

The DataGrid also lets you organize rows into meaningful groups. You can, as you’re viewing the data, select the rows that you want to group or drag/drop columns or rows to create the groups you need. (See Grouping options for KendoReact Grid as an example.)

Once you create groups, you can include displays of aggregate values for those groups. But you don’t have to create groups to get aggregate values. You can, as you’re working with the grid, select the rows and columns you want to be included in your aggregated values.

While the DataGrid supports the typical aggregate functions “out of the box” (e.g., count, sum, average, etc.), you can have more sophisticated aggregates integrated into your grids.

Drilling Down

You can also have the DataGrid configured as a hierarchy of high-level sections that you can drill down into to reveal nested, detailed data. You can have your data nested as many levels deep as you need, and each level can have its own, distinct set of columns and aggregates. Effectively, you can expand your high-level rows into a different grid of detail data that reflects your needs at each level.

Exporting Data

The DataGrid also supports exporting data in a variety of formats so you can integrate other tools into your analysis (or you can just copy grid data so you can paste into some other tool).

You’re not limited to copying or exporting all the data in the grid. While you’re working with the grid, you can select the rows and columns you want you want to export into another tool (or just share with others—the grid supports multiple export formats, including PDF). If your application is using the Telerik Chart control you can export your data straight into the chart for visualization.

And, if you are using the DataGrid to facilitate selecting the data to export into some other tool, the grid supports a “high density” mode that packs more data on the screen. (See the Kendo UI for Angular Grid Grouping Display Modes page for example.)

As an analyst, you can’t really have too much data—provided, of course, your tools let you review and explore that data effectively. The Telerik DataGrid gives you a customizable window into the data for any application, turning the application itself into a tool for analyzing its own data. That enables you to create the business intelligence that drives better decisions, which is, after all, the purpose of being a financial analyst.

Check out the Telerik DevCraft suite of products to learn about the DataGrid in your favorite .NET or JavaScript flavor. And you can try out the whole suite free for 30 days.

Try Telerik DevCraft

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

Log in to Progress and purchase a Kendo UI for Angular license, or try it for free.

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</p>

          <h2
            class="m-0 max-w-[11ch] text-[clamp(1.7rem,4vw,2rem)] font-semibold leading-[1.08] tracking-tight text-slate-900 text-balance">
            {{ selectedRestaurant.name }}
          </h2>

          <div class="grid justify-items-center gap-3">
            <p class="m-0 text-[1rem] leading-6 text-slate-700">
              {{ selectedRestaurant.cuisine }}
            </p>

            <span
              class="inline-flex min-h-10 items-center justify-center rounded-full border border-slate-300/40 bg-white/90 px-5 text-sm font-bold text-slate-900 shadow-[0_6px_18px_rgba(15,23,42,0.06)]">
              {{ selectedRestaurant.mode === 'dine-in' ? 'Dine-in' : 'Takeout' }}
            </span>
          </div>
        </div>
      </section>
      } @else {
      <div
        class="rounded-[1.75rem] border border-dashed border-slate-400/60 bg-slate-50/75 px-5 py-6 text-center text-[0.95rem] leading-6 text-slate-500">
        @if (filteredRestaurants.length === 0) {
        No restaurants found for this option.
        } @else {
        Click the button to pick a restaurant.
        }
      </div>
      }

      <p class="text-center text-[0.82rem] font-semibold text-slate-500">
        {{ 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

AI stopped being “the thing that writes your code” a while ago. At this point, it’s showing up at nearly every stage of the job: helping you build the app, automate the parts nobody wants to do by hand and keep an eye on how AI-powered features actually behave once real users touch them.

This month’s updates across Progress Telerik, Kendo UI, Telerik Reporting, Fiddler and Progress AI Observability are a good snapshot of that shift. Here’s what’s new and, more importantly, what it actually lets you do.

But before that … We’re walking through everything below on Progress AI Monthly: Telerik, Kendo UI & More livestream on August 28, 9 a.m. ET. No sign-up, just show up.

YouTube · LinkedIn · Twitch

Build

More AI, Fewer Tokens

Before getting to what’s new, a word on what’s gotten leaner: token consumption is down by up to 45% across our .NET products, with better output quality on top of that, so the same prompt now costs you less and gets you more. Alongside that, the Agentic UI Generator for Telerik UI for Blazor, KendoReact and Kendo UI for Angular is now available as an agent-native skill instead of an externally configured tool, which makes it noticeably easier to deploy in air-gapped and regulated environments.

See the MCP servers page.

Build UI with a Prompt

The Agentic UI Generator now supports Telerik UI for ASP.NET Core. Describe what you need in plain language, and it generates real, framework-aware code that follows the patterns you’d already be using: grids, forms, navigation, layout, the works. That means less time assembling scaffolding and more time on the parts of the app that actually need your judgment.

A few things people are already using it for: business applications, admin portals, customer-facing dashboards, analytics views and data-driven workflows.

See how the ASP.NET Core UI Generator works.

Build Reports with Natural Language

The Telerik Reporting AI Report Generator in Web Report Designer has already been generating charts and gauges from a plain description of what you want to see. Now that same idea extends to structured report content: tables, lists, crosstabs, summary rows, headers and footers, and grouped structures.

Describe the table you need. For instance, grouped by region, with subtotals. And the Generator builds it, then hands you a preview to check before anything actually lands in the report.

Explore AI-Generated Tables, Lists and Crosstabs.

Build Faster with New Components

Not every update this month is AI-flavored. Some of it is just useful, new UI:

• Telerik UI for Blazor: Expansion Panel
• KendoReact: OTP Input
• Kendo UI for Vue: Barcode, PDF Viewer
• Telerik UI for .NET MAUI: Charts (Preview), Circular Slider
• Telerik UI for WPF: Smart Paste Button, Inline AI Assistant
• Telerik UI for WinForms: Smart Paste Button

Build AI-ready Experiences with the LLM Kit

The LLM Kit isn’t just something you bolt on after the fact to keep tabs on your agents. It’s a set of components for building the AI-powered experience itself. Chat-style interfaces, multi-step agent workflows, tool-call displays, approval steps, citations, checkpoints: the pieces you’d otherwise have to design and build from scratch are already there, ready to wire into your app.

It gives you a real head start on shipping AI features that feel considered rather than bolted on, and, as a side benefit, your users and your team can actually see what the AI is doing along the way.

It’s available now for Telerik UI for Blazor, UI for ASP.NET Core, UI for MVC, Kendo UI for Angular, UI for jQuery and KendoReact.

Automate

Automate Application Upgrades

Nobody enjoys upgrading a codebase, and it’s rarely the highest-value use of anyone’s afternoon. AI-assisted migration is now available for Telerik UI for ASP.NET Core, UI for MVC, UI for WPF, KendoReact and Kendo UI for jQuery through the Upgrade Assistant (part of the MCP engine). It handles the changes it already knows how to make on its own and walks you through the ones that need a human decision, so version bumps stop eating whole sprints.

Automate Reporting Operations with AI Agents

Telerik Report Server now ships with a native MCP Server, so assistants like Copilot, Claude, Cursor and Codex can work directly inside your reporting environment instead of going through a custom integration you’d have to build and maintain. Once you’ve set up a Personal Access Token, agents can:

• Generate reports
• Manage data sources
• Schedule reports
• Handle general reporting-environment admin

See Report Server MCP docs.

Automate Debugging with Fiddler MCP

Debugging gets a lot more useful when your AI assistant can see what actually happened over the wire, not just what the code says should happen. Fiddler MCP connects your coding assistant to real traffic captured in Fiddler Everywhere, actual requests, responses, headers, status codes, so it’s reasoning from evidence instead of guessing. Set it up with one click inside Fiddler Everywhere, then go from “something’s broken” to a fix without leaving your IDE.

Explore Fiddler Everywhere MCP.

Automate Licensing for CI/CD

Automation isn’t only about what your agents do. It’s also about what shouldn’t need a human to manage. Deployment Keys give you a dedicated way to license automated builds and deployments: each key ties to a registered application and the exact Telerik or Kendo products it uses, so tracking, monitoring and reporting on product usage across your CI/CD environments gets a lot less manual.

Observe

Building faster and automating more only gets you so far if you can’t tell what your AI systems are actually doing once they’re live. That’s the part teams tend to underinvest in until something goes wrong.

Learn Why AI Observability Matters

If you want to go deeper on this, join Jeff Fritz and Progress Product Manager Lyubomir Atanasov on August 26 for “AI Observability: When AI Goes Off the Rails.” They’ll walk through some genuinely memorable public AI failures, then run a live Progress AI Observability demo covering agent tracing, drift and hallucination detection, and performance and cost monitoring.

Register for the webinar.

Help Shape the Future of Agentic Development

This is also the thinking behind the Progress Agent Harness Early Access Program: structured, auditable AI workflows, with early adopters getting a direct line to the roadmap. As agents take on more, being able to manage them predictably matters just as much as what they can build.

Join the Agent Harness EAP.

What’s New and Release History

To see everything that’ is new in August 2026 release edition, visit the What’s New in Telerik and Kendo UI page. For a deeper dive into each product, follow the links below.

Blazor has become a serious platform for building modern web applications with .NET. As the framework has matured, commercial UI component libraries have become an important part of the Blazor development experience.

Instead of building every Grid, Chart, Scheduler, Form, Editor, and navigation component from scratch, teams can rely on mature component suites to accelerate development, improve UI quality and reduce long-term maintenance effort. Two of the most common options for Blazor development are Progress Telerik UI for Blazor and Syncfusion Blazor.

Both are mature. Both provide large component collections, commercial support, documentation, examples and tooling for .NET developers. Both can be used to build complex business applications.

The decision is rarely about whether one product is objectively “better.” A more useful question is: “Which library better matches the way your team builds, maintains, upgrades and scales Blazor applications over time?”

At a high level, Syncfusion Blazor is attractive for teams that want a very broad component catalog, access to many specialized controls and a Community License for qualifying users. Telerik UI for Blazor is a strong fit for teams that value a cohesive developer experience, predictable APIs, strong theming workflows, product polish, support reputation and long-term maintainability.

This comparison looks at both products through practical evaluation criteria: onboarding, component coverage, grid capabilities, theming, accessibility, performance, support, AI readiness and long-term project fit.

Quick Decision Summary

Choose Telerik UI for Blazor if…

• You are building a long-lived application that will be maintained for several years.
• Multiple developers or product teams will contribute to the same UI codebase.
• You value predictable APIs and standardized implementation patterns.
• You need strong theming, design-token management or designer-developer collaboration.
• You care about upgrade experience, support quality and long-term maintainability.
• You want a component suite that is easy for both developers and AI coding assistants to reason about.

Key Differences at a Glance

What Most Teams Eventually Optimize For

When teams first compare component libraries, they usually start with feature lists.

That makes sense. Component count, available controls, Grid features, Scheduler options, chart types, templates, exporting and documentation examples are easy to compare.

But once a Blazor application moves into production, different questions become more important:

• How easy is the application to maintain?
• Can new developers understand the UI code quickly?
• Are component APIs predictable?
• How painful are upgrades?
• Can we apply the same branding across multiple applications?
• Can designers and developers work from the same design system?
• How reliable is support when something breaks?
• Can AI coding assistants generate correct and maintainable UI code?

This is where the distinction between breadth and cohesion matters.

Syncfusion has a strong case when a team wants access to a broad collection of components, related document libraries and specialized controls. Telerik has a very strong case when a team wants a more unified development model, mature theming workflows and a polished component experience across the core UI scenarios that most business applications depend on.

Neither priority is wrong. The better choice depends on what your team values most.

Time to First Value

Feature comparisons are useful, but the first developer experience is usually more practical:

• How do I install the package?
• How do I configure licensing?
• How do I set up NuGet access?
• How do I create the first Blazor project?
• How quickly can I render a real component?
• How many manual steps are required before I can start evaluating the library?

This is where time to first value becomes important.

Time to First Value: Telerik UI for Blazor

Telerik puts a strong emphasis on guided onboarding. The product experience includes getting-started documentation, templates, licensing guidance, CLI-based workflows and integration with Telerik tooling.

Telerik focuses heavily on onboarding and guided setup, and this includes:

• Structured getting-started documentation
• Starter project guidance
• Project templates and configuration assistance
• Consistent setup patterns across components

The Telerik CLI can help reduce setup friction by assisting with project creation, package configuration, licensing-related setup, templates and related tooling.

This matters because early evaluation is not only about installing a NuGet package. It is about reducing the number of small setup decisions that slow teams down before they can assess the actual components.

The setup becomes as simple as:

For larger teams, this kind of guided setup can be useful because new developers do not need to rediscover the same configuration steps independently.

Time to First Value: Syncfusion Blazor

Syncfusion also has a strong onboarding story. Its ecosystem includes product documentation, sample applications and a large collection of examples. The Syncfusion Blazor samples repository describes demos for Blazor Server and Blazor WebAssembly apps, including project files targeting modern .NET versions.

That breadth of examples can be valuable when a developer is looking for a specific scenario or specialized component behavior.

Time-to-First-Value Takeaway

For a small proof of concept, both products can get developers started quickly.

The advantage of Telerik UI is more about guided setup and a cohesive path from installation to production-style usage. Syncfusion’s advantage is the large ecosystem of samples.

Component Coverage

Component count is one of the most visible comparison points.

Syncfusion Blazor is known for broad component coverage. Its Community License page describes access to 145+ Blazor components for eligible users and organizations. Syncfusion’s broader product line also includes UI components, document SDKs and standalone UI SDKs under the Community License description.

That breadth is a legitimate advantage. Teams that need niche controls, document processing capabilities, PDF-related libraries, Office document support or specialized UI scenarios may find Syncfusion difficult to overlook.

Telerik UI for Blazor takes a somewhat different approach. It provides a large suite of core Blazor components, but its strongest value proposition is not simply the number of controls. Telerik UI is strongest when the application depends heavily on polished core components such as Grid, Charts, Scheduler, Forms, Inputs, Editors, Layout, Navigation, Upload and theming.

For many business applications, both libraries cover the essential requirements. The practical difference is often not “Does a component exist?” but:

• How predictable is it to configure?
• Does it follow familiar patterns from other components in the same suite?
• Does documentation match real development scenarios?
• Is the component easy to theme and maintain?
• Does it fit into a shared UI platform?

Component Coverage Takeaway

Syncfusion has the advantage in overall breadth and specialized coverage.

Telerik has the advantage when teams want a cohesive suite focused on core business application scenarios, polished UI behavior and maintainable implementation patterns.

The Grid: The Component That Often Decides the Evaluation

If one component influences UI library decisions more than any other, it is usually the grid.

Business applications spend a large amount of time displaying, filtering, grouping, sorting, editing, exporting and analyzing data. For many teams, the grid is not just one component. It is the center of the application.

Both Telerik UI for Blazor and Syncfusion Blazor provide capable Grid components with support for common business scenarios such as:

• Sorting
• Filtering
• Grouping
• Paging
• Virtualization
• Inline editing
• Batch editing
• Templates
• Aggregates
• Exporting
• Hierarchical data
• Large dataset scenarios

Both vendors can support serious data-heavy applications. In practice, grid performance depends not only on the component itself but also on data access strategy, rendering mode, server communication, virtualization configuration and application architecture.

Telerik UI for Blazor Grid

The Telerik UI for Blazor Grid is strongest when teams care about a polished and predictable implementation model.

The main advantages are not only feature availability, but how the Grid fits into the broader development experience:

• Predictable configuration patterns
• Strong template support
• Familiar event and data-binding approaches
• Alignment with the rest of the Telerik component suite
• Accessibility-specific documentation
• A mature experience for common business data scenarios

Telerik Grid accessibility is WCAG 2.2 AA and Section 508 compliant, follows WAI-ARIA best practices for keyboard navigation and is tested with popular screen readers. That is a concrete point worth considering for teams building applications with formal accessibility requirements.

Syncfusion Blazor Grid

The Syncfusion Grid is also highly capable and has a broad feature surface. It is particularly attractive when teams need extensive configuration options or specialized behaviors.

Syncfusion’s Grid supports accessibility standards including ADA, Section 508, WCAG 2.2 and ARIA roles, with details on screen reader support, RTL support, color contrast, mobile device support, keyboard navigation and Axe-core validation.

Grid Takeaway

Both Grids are mature and capable.

Syncfusion’s Grid stands out for broad functionality and configurability. The Telerik Grid stands out for a polished developer experience, accessibility documentation and a usage model that tends to fit well into long-lived applications with multiple contributors.

If your evaluation is based on a specific Grid feature, test that feature in both products. If your evaluation is based on long-term maintainability, onboarding, accessibility and shared implementation patterns, Telerik deserves stronger consideration.

Scheduler, Charts and Dashboards

After the Grid, Scheduler and Charts are often among the most important components in business applications.

Scheduler

Both Telerik and Syncfusion support common scheduling scenarios such as:

• Day, week and month views
• Recurring events
• Resource grouping
• Drag-and-drop editing
• Custom templates
• Business calendar scenarios

Syncfusion is attractive when the team wants broad scenario coverage and many examples.

Telerik is attractive when the Blazor Scheduler needs to feel like part of the same UI platform as the Grid, Forms, Inputs, Dialogs, Charts and navigation components.

Charts and Dashboards

Both libraries provide charting capabilities suitable for dashboards, reporting UIs, KPI tracking, analytics screens and business intelligence-style interfaces.

The distinction is less about whether common chart types exist and more about the surrounding workflow:

• How easily can charts be themed?
• Can they follow the same visual system as the rest of the app?
• Can multiple teams reuse the same design language?
• Can dashboard screens stay visually aligned over time?

This is where the Telerik theming story becomes especially relevant.

Theming and Design-System Governance

Theming is often underestimated during evaluations.

At the start of a project, teams usually focus on functionality. Later, especially in long-lived applications, theming becomes a product and architecture concern.

Questions start to appear:

• Can we align components with our brand?
• Can designers and developers collaborate without translating everything manually?
• Can we reuse themes across multiple applications?
• Can we manage design tokens centrally?
• Can we support light and dark modes?
• Can we avoid one-off CSS overrides that become hard to maintain?
• Can we update the visual language without rewriting large parts of the UI?

This is one of Progress Telerik UI’s clearest differentiators.

Progress Telerik ThemeBuilder

Progress Telerik ThemeBuilder is a SaaS tool that enables teams to create custom themes and preview how they affect component appearance. It can generate a CSS file that can be used in a Blazor app instead of a built-in theme.

ThemeBuilder also supports capabilities that matter in design-system driven organizations, including:

• Atomic customization
• CSS/SASS variables
• Custom HTML support
• Figma integration
• Theme modes and built-in themes
• Custom fonts and iconography
• Project sharing
• Version control
• Collaboration and user access rights

This is more than visual customization. It helps teams create a shared styling workflow between design and engineering.

For organizations with multiple product teams, this can reduce duplicated CSS work, prevent visual drift between applications and make brand updates easier to manage.

Syncfusion Customization

Syncfusion also provides styling and customization options. For many teams, those capabilities will be enough.

However, if centralized design-system governance is a major requirement, Progress Telerik ThemeBuilder gives it a particularly strong position.

Theming Takeaway

Both libraries can be customized.

Telerik has a clearer advantage when teams need design tokens, Figma-related workflows, centralized branding, visual governance and reusable themes across multiple applications.

Blazor App Accessibility

Accessibility should be part of any serious UI library evaluation.

Teams building applications for public sector, healthcare, finance, education, government or large internal platforms often need to consider:

• WCAG
• Section 508
• Keyboard navigation
• Screen reader support
• WAI-ARIA roles and attributes
• Color contrast
• Accessible interaction alternatives
• Accessibility conformance documentation

Telerik Accessibility

Telerik UI for Blazor provides an accessibility compliance table that lists WCAG 2.2 compliance levels for individual components. Progress Telerik also provides an Accessibility Conformance Report through VPAT.

For the Grid specifically, Telerik documents WCAG 2.2 AA and Section 508 compliance, WAI-ARIA best practices, keyboard navigation, and screen reader testing.

Syncfusion Accessibility

Syncfusion documents accessibility support for Blazor components, including WAI-ARIA, WCAG 2.2, Section 508, keyboard navigation, screen reader support, RTL support and color contrast considerations.

Syncfusion’s DataGrid accessibility documentation also provides a detailed view of supported standards and limitations for complex interactions.

Accessibility Takeaway

Both vendors take accessibility seriously and provide documentation around standards and component behavior.

The Telerik component-level compliance table and documented Grid compliance are helpful for teams that need formal accessibility evidence. Syncfusion also provides broad accessibility documentation, including detailed DataGrid accessibility coverage.

For accessibility-sensitive applications, the best approach is to test the exact components and configurations your application will use.

Support, Documentation and Learning Resources

Support quality is hard to capture in a comparison table, but it often becomes critical after adoption.

During a trial, teams should evaluate:

• How quickly developers find answers in documentation
• Whether examples match real scenarios
• How clear upgrade notes are
• How support handles complex issues
• Whether feedback and bug reports are visible
• Whether the vendor provides practical guidance beyond simple demos

Telerik UI for Blazor Support

Progress Telerik has a long-standing reputation in the ecosystem for polished components, detailed documentation, active forums, feedback channels and strong support. That reputation is one of the reasons Telerik UI is often favored by teams building long-lived applications.

This should still be validated during evaluation. The best support test is not reading a marketing page. It is submitting realistic trial questions and measuring how useful the answers are.

Syncfusion Blazor Support

Syncfusion also provides commercial support, documentation, samples and a large knowledge base. Its broad ecosystem can be helpful when developers are searching for examples across many controls and scenarios.

Syncfusion’s large sample repository is especially useful when teams want to inspect working examples and compare usage across components.

Support Takeaway

Both vendors provide serious support and learning resources.

Telerik UI is often especially attractive for teams that prioritize product polish, support confidence and long-term UI quality. Syncfusion is strong for teams that value broad documentation coverage, many samples and a large ecosystem.

Product Quality, Stability and Upgrade Experience

Product quality is more than whether a component works in a demo.

For long-lived applications, quality usually means:

• Stable APIs
• Clear documentation
• Predictable behavior
• Accessibility guidance
• Reliable release notes
• Manageable upgrades
• Good support for modern .NET versions
• Transparent handling of bug fixes and breaking changes
• Similar concepts across related components

This is where the Telerik UI value proposition becomes stronger. Its advantage is not only that the components are polished, but that the suite tends to feel like a coherent product rather than a collection of unrelated controls.

That can reduce cognitive load for teams. Developers who learn common Telerik concepts in one component often find similar ideas elsewhere in the suite.

Syncfusion’s broader catalog is valuable, but naturally creates a larger surface area to learn, test and govern. That tradeoff may be completely acceptable if the team needs the additional breadth.

Upgrade Experience Takeaway

For short-lived apps, upgrade experience may not matter much.

For applications expected to live for several years, upgrade predictability and maintainable implementation patterns become important. Telerik UI is particularly compelling for teams that prioritize those concerns.

AI Readiness and Agentic Development

A few years ago, component library evaluations focused primarily on features, performance and support. Today, many teams are adding another criterion to their evaluation:

How well does the platform integrate with AI-assisted development workflows?

The discussion is no longer limited to AI-powered components. Developers increasingly expect AI tools that can help generate interfaces, configure components, validate code, enforce design-system rules and accelerate application development.

Progress Telerik AI Approach

Progress Telerik has invested in AI-assisted development across several areas of the product ecosystem, combining UI components, AI-powered tooling and agentic workflows into a more complete development experience.

The foundation of this effort is the Telerik AI Coding Assistant, which integrates directly into developer workflows through IDE-based experiences, GitHub Copilot extensions, and MCP-based tooling. The assistant can help generate Telerik UI for Blazor code, configure components, scaffold common scenarios, generate sample data and provide implementation guidance using Telerik-specific knowledge rather than generic web examples.

Beyond code generation, Progress Telerik has introduced an Agentic UI Generator that uses a collection of specialized assistants working together through an MCP-based architecture. Rather than generating isolated snippets, it can help create complete pages, dashboards, layouts and component configurations while following Telerik component patterns and design-system guidance.

The platform includes specialized assistants for:

• Page and UI generation
• Component selection and configuration
• Layout creation
• Styling and theming
• Icons and visual assets
• Accessibility guidance
• Validation and quality checks
• Project onboarding and setup workflows

These capabilities are orchestrated through the Agentic UI Generator, allowing developers to work at a higher level of abstraction when creating Blazor applications.

Telerik AI Plugins, MCP and Development Tools

One notable aspect of the Telerik AI strategy is the focus on developer tools rather than only AI-enabled components.

The Telerik MCP-based tooling includes plugin capabilities for:


This allows AI tools to work with Telerik-specific knowledge instead of relying solely on generic LLM training data, which can help reduce incorrect component usage and configuration errors.

In addition, Telerik provides AI-enhanced capabilities within its component ecosystem, including AI-powered chat experiences, semantic search scenarios, AI-assisted data operations, AI integrations within Grid and Editor components, WebMCP support, and integration scenarios involving technologies such as A2UI, AG-UI and Microsoft Agent Framework.

Syncfusion AI Position

Syncfusion is also actively investing in AI-based developer experiences and provides AI-related features, assistants and tooling across its ecosystem. Like Progress Telerik, Syncfusion is exploring AI-assisted development workflows and has published AI-related resources and component skills for developers working with its platform.

One of Syncfusion’s broader advantages remains the size of its overall ecosystem, which includes a large collection of UI components, document processing libraries and developer tools that can participate in AI-assisted workflows.

AI Readiness Takeaway

Which platform has the stronger AI story? Today, both Progress Telerik and Syncfusion are investing in AI.

The difference is less about whether AI capabilities exist and more about where the investment is focused.

Syncfusion’s strength comes from the breadth of its ecosystem and the large number of controls, libraries, and scenarios available to developers.

Telerik UI’s strength comes from providing an increasingly connected AI development experience that spans:

• AI Coding Assistant
• Agentic UI Generator
• MCP-based development tooling
• Specialized AI assistants
• Validation workflows
• Accessibility guidance
• Design-system alignment
• AI-enhanced components and features

For teams looking beyond AI-powered controls and toward AI-assisted UI development, Telerik currently offers one of the more comprehensive AI stories available in the Blazor ecosystem. The combination of UI generation, component-aware assistants, validation tooling, theming guidance and MCP integration makes the AI capabilities feel like part of the overall developer workflow rather than a collection of isolated features.

Where Telerik Has a Clear Advantage

Telerik is strongest when the team cares less about maximizing the catalog and more about building a maintainable UI platform.

Telerik is particularly compelling when:

• The application will live for several years.
• Multiple developers or product teams will work in the same codebase.
• The Grid, Forms, Charts, Scheduler and layout components need to feel cohesive.
• Design-system governance matters.
• The team wants strong theming workflows through ThemeBuilder.
• Accessibility evidence is important.
• Support confidence is a major factor.
• AI-assisted development is becoming part of the engineering workflow.

The clearest Telerik differentiator is ThemeBuilder. Its support for visual customization, variables, Figma integration, theme modes, custom fonts, project sharing, version control and collaboration makes it especially useful for teams that need a structured design-to-development workflow.

Pros and Cons

Telerik UI for Blazor

Syncfusion Blazor

Decision Framework

Telerik UI for Blazor is likely the better fit if…

1. The application will be maintained for several years.
2. Multiple developers or teams will contribute to the UI.
3. You need a shared design system.
4. The Grid is central to your application.
5. Accessibility documentation is important.
6. You want a polished and cohesive development experience.
7. Support confidence is part of the buying decision.
8. You expect AI-assisted development to become more important.
9. You value maintainability more than raw component count.

Syncfusion Blazor is likely the better fit if…

1. You need the large component catalog.
2. You need niche components.
3. The Community License applies to you.
4. Your team is comfortable managing a larger API surface.
5. Your evaluation is primarily driven by breadth and feature availability.

Final Verdict

If your primary goal is maximizing the number of available controls, accessing specialized components, benefiting from a Community License, Syncfusion Blazor is difficult to overlook.

If your priority is building a long-lived Blazor application with a cohesive developer experience, strong theming, accessibility documentation, support confidence, predictable implementation patterns and maintainable UI architecture, Telerik UI for Blazor offers a very compelling value proposition.

The choice comes down to what your team wants to optimize for. Feature breadth matters during evaluation. Maintainability matters in production.

For teams building applications that need to scale across developers, products, themes, accessibility requirements, and future AI-assisted workflows, Telerik UI for Blazor stands out as the stronger long-term choice—not because Syncfusion is weak, but because Telerik UI for Blazor’s strengths align especially well with the needs of structured, design-system driven, maintainable Blazor development.

Try Telerik UI for Blazor

JavaScript gets a new language standard every year. Some editions introduce syntax that changes how programs are written or how they perform. The ECMAScript 2026 (ES17) version brings a handful of useful features which we will look at. These features add focused APIs for tasks that JavaScript developers already handle with small helpers, repeated checks or easy-to-miss workarounds.

In this article, I will focus on additions that can remove code, make intent clearer or prevent subtle errors.

Runtime support: These APIs did not arrive in every runtime at the same time. Check the Browser compatibility table on each linked MDN page for the browsers and runtimes you support. Use a tested fallback when an API is unavailable.

Image generated with AI

Build a Map as Values Arrive

In my article about array grouping, I showed a simple way to group related things using Object.groupBy() and Map.groupBy(). Both methods begin with a collection that already exists, but what if you want to do the same for streaming data?

For example, this code groups employees from an asynchronous stream:

const employeesByDepartment = new Map();

for await (const employee of employeeStream) {
  if (!employeesByDepartment.has(employee.department)) {
    employeesByDepartment.set(employee.department, []);
  }

  employeesByDepartment
    .get(employee.department)
    .push(employee);
}

There is nothing complicated here, but the has(), set() and get() sequence is boilerplate code around the operation we actually care about—adding a new employee to a department.

ECMAScript 2026 adds Map.prototype.getOrInsert() and Map.prototype.getOrInsertComputed(). These methods return the value corresponding to the specified key. If not present, it inserts a new entry with the key and a given default value, and returns the inserted value.

You should use getOrInsertComputed() whenever the default should be created lazily, particularly when creating it is expensive, has side effects or allocates a mutable object such as an array. With the computed version, the code from before becomes:

const employeesByDepartment = new Map();

for await (const employee of employeeStream) {
  employeesByDepartment
    .getOrInsertComputed(employee.department, () => [])
    .push(employee);
}

The result is simple and compact.

Collect an Asynchronous Iterable into an Array

An asynchronous generator is a useful way to hide pagination. Its caller can consume one sequence without knowing where one response page ends and the next begins. For example:

async function* fetchAllIssues(url) {
  while (url) {
    const response = await fetch(url);

    if (!response.ok) {
      throw new Error(`Request failed: ${response.status}`);
    }

    const page = await response.json();

    yield* page.items;
    url = page.next;
  }
}

To collect every result into an array, you would normally write a loop:

const issues = [];

for await (const issue of fetchAllIssues("/api/issues")) {
  issues.push(issue);
}

The Array.fromAsync() method can be used to perform that collection directly:

const issues = await Array.fromAsync(
  fetchAllIssues("/api/issues"),
);

Isn’t that shorter and simpler?

Despite its name, the method also accepts synchronous iterables and array-like objects. It awaits values from those sources one at a time.

Array.fromAsync() also accepts a mapping function, and the runtime waits for the mapped result before reading the next value. For example, the same code can be adjusted to return only the issue title using the map function:

const issueTitles = await Array.fromAsync(
  fetchAllIssues("/api/issues"),
  (issue) => issue.title,
);

Given that example, it might be misleading to think that Array.fromAsync() runs independent operations concurrently. For example:

// The requests start one after another.
const sequential = await Array.fromAsync(urls, fetchJson);

// All requests are initiated before any of them is awaited.
const concurrent = await Promise.all(urls.map(fetchJson));

You should use Promise.all() when independent operations can run at the same time. And reach for Array.fromAsync() when the source or mapping step may be asynchronous, and you want lazy, ordered consumption. Also remember what the method returns—an array containing every result. Keep the for await...of loop when you want to process a large stream incrementally and avoid collecting a stream that may never end.

Combine Iterables into One Lazy Sequence

Sometimes several iterable sources should behave like one continuous sequence. Suppose an application checks its built-in routes first, then registered routes by plugins and finally a catch-all route. You could spread everything into a new array, but that would eagerly consume each iterable and allocate another collection.

A generator can keep the sequence lazy:

function* allRoutes() {
  yield* builtInRoutes;
  yield* pluginRoutes;
  yield fallbackRoute;
}

Iterator.concat(), on the other hand, expresses the same operation without the custom generator:

const allRoutes = Iterator.concat(
  builtInRoutes,
  pluginRoutes,
  [fallbackRoute],
);

The result yields the built-in routes first, followed by the plugin routes and then the fallback. Values are pulled only as the consumer advances the iterator; Iterator.concat() does not collect them into a new array first. Each argument must be an iterable object, which is why the example wraps fallbackRoute in an array.

The Iterator.concat()method works with synchronous iterables only. It does not combine asynchronous iterables.

Preserve Large Integers in JSON

Chat platforms often hand out snowflake IDs as part of a message or other kinds of data. These are commonly 64-bit integers and can exceed Number.MAX_SAFE_INTEGER, so parsing them as JSON numbers can silently lose precision. Consider this response:

const payload = `{
  "messageId": 1183028002140618753,
  "channel": "general"
}`;

const event = JSON.parse(payload);

console.log(event.messageId);
// 1183028002140618800

The logged value isn’t the value in the JSON text.

ECMAScript 2026 gives the JSON.parse() reviver function a third argument, named context. When the value is an unmodified primitive from the parser, context.source contains the original JSON text. We can use that to parse and convert the text to the proper type, in this case BigInt.

Here’s the sample from earlier, rewritten using the reviver function:

const event = JSON.parse(
  payload,
  (key, value, context) => {
    if (key === "messageId") {
      return BigInt(context.source);
    }

    return value;
  },
);

console.log(event.messageId);
// 1183028002140618753n

By the time the reviver receives value, the Number has already lost precision. However, context.source lets the code ignore that damaged value and build a BigInt from the original digits instead.

Serialization has the opposite problem: JSON.stringify() throws when it reaches a BigInt, unless you handle the value. The new JSON.rawJSON() method lets a replacer function for JSON.stringify provide valid JSON text for a primitive value. The JSON.rawJSON() method creates a “raw JSON” object containing JSON text.

Here’s an example using JSON.stringify() and JSON.rawJSON() together:

const json = JSON.stringify(
  event,
  (key, value) =>
    typeof value === "bigint"
      ? JSON.rawJSON(value.toString())
      : value,
);

console.log(json);
// {"messageId":1183028002140618753,"channel":"general"}

Used together, the two APIs let this program recover the original digits as a BigInt and serialize those digits back into JSON without rounding them.

Using those APIs doesn’t mean you should turn every integer into a BigInt. A count, price and database identifier may all appear as JSON numbers, but they do not necessarily belong in the same underlying JavaScript type. That said, it is important to remember that the parser exposes context.source only for unmodified primitive values, and JSON.rawJSON() accepts only valid JSON text representing a primitive value.

Convert Bytes to and from Base64 or Hex

Binary data has often taken an unnecessary detour through strings. Converting to and from bytes wasn’t a natural interface in the language. I think Bun was the first JS runtime I used that had a built-in API for converting bytes to various data types. Fortunately, the 2026 ECMAScript standard release brings the following functions for converting bytes:

• Uint8Array.prototype.toBase64
• Uint8Array.prototype.toHex
• Uint8Array.prototype.setFromHex and its static form Uint8Array.fromHex
• Uint8Array.prototype.setFromBase64 and its static form Uint8Array.fromBase64

How are they useful, you may ask?

Imagine you want to create a URL-safe token. The code might look like this:

const bytes = crypto.getRandomValues(new Uint8Array(32));

const token = btoa(String.fromCharCode(...bytes))
  .replaceAll("+", "-")
  .replaceAll("/", "_")
  .replace(/=+$/, "");

The program starts with bytes, turns them into a temporary string, encodes that string and then adjusts the alphabet and padding. It works, but none of those intermediate steps express the real task: encode these bytes as base64url.

We can use the Uint8Array.prototype.toBase64() method to do the conversion instead:

const bytes = crypto.getRandomValues(new Uint8Array(32));

const token = bytes.toBase64({
  alphabet: "base64url",
  omitPadding: true,
});

The reverse conversion is also as simple as:

const decoded = Uint8Array.fromBase64(token, {
  alphabet: "base64url",
});

The setFromBase64() and setFromHex() methods write into an existing array and return an object with read and written counts. Unlike fromBase64() and fromHex(), they are useful when you need to control memory allocation, decode into a preallocated buffer or track how much input fits. See the docs for Uint8Array.fromBase64() to learn about the available input options and runtime support.

These methods do not replace TextEncoder or TextDecoder. Use those APIs to convert between text and bytes; use the new Uint8Array methods to convert between bytes and base64 or hexadecimal representations.

Recognize Error Objects Across Realms

The instanceof Error looks like the obvious way to check if an object is an Error. It stops being reliable when the value comes from another JavaScript realm, e.g., an iframe or the Node.js vm context. Each realm has its own Error constructor, so a genuine error from another realm can fail an instanceof check.

Try this in the browser console:

const iframe = document.createElement("iframe");
document.body.append(iframe);

const otherError = new iframe.contentWindow.Error("Failure");

console.log(otherError instanceof Error);
// false

This may not surprise many experienced JavaScript programmers who have been deceived by some JavaScript quirkiness.

The solution is to use the new Error.isError(). Error.isError() performs a built-in check by testing for the internal [[ErrorData]] slot instead of relying on the current realm’s prototype chain. This makes it analogous to Array.isArray() as a reliable cross-realm check.

If you append console.log(Error.isError(otherError)) to the previous code snippet you ran in your browser console, you should see the correct result.

The method is also useful in a catch block because JavaScript allows any value to be thrown:

try {
  await runPlugin();
} catch (value) {
  const error = Error.isError(value)
    ? value
    : new Error(String(value), { cause: value });

  reportError(error);
}

You should use Error.isError() when you need to know whether a value is a real Error object. It deliberately does not treat a plain object with name and message properties as one.

Sum Floating-point Values More Accurately

A straightforward reduce() can lose information while adding floating-point values, and the failure mode is sneakier than you’d expect, because the result doesn’t always look obviously wrong. Consider a motion-sensor library that applies a large per-device calibration offset, adds a small reading, then removes the offset again:

const readings = [1e16, 3.5, -1e16];

const total = readings.reduce(
  (sum, value) => sum + value,
  0,
);

console.log(total);
// 4

The correct answer is 3.5—that’s the actual reading once the offset cancels out. Near 1e16, adjacent representable numbers are two units apart. The exact value 1e16 + 3.5 therefore rounds to 1e16 + 4, and subtracting the offset leaves 4 instead of 3.5. The result isn’t a crash but a plausible-looking wrong number, which is what makes this type of bug easy to miss in code review.

That’s where Math.sumPrecise() comes in. It uses a more accurate summation algorithm, so switching from .reduce() to Math.sumPrecise() gets you the correct answer.

Here’s an accurate way to rewrite it:

const total = Math.sumPrecise(readings);

console.log(total);
// 3.5

The Math.sumPrecise() method accepts an iterable of numbers. It does not coerce strings or BigInt values into numbers. An empty iterable, or one containing only -0, returns -0. The name deserves one warning though, because Precise does not mean decimal arithmetic precision. This familiar result does not change:

console.log(Math.sumPrecise([0.1, 0.2]));
// 0.30000000000000004

Both inputs are already binary floating-point approximations. Math.sumPrecise() reduces the additional error introduced while summing them; it does not change how JavaScript represents numbers. That makes it useful for numerical aggregation, but not a complete solution for money. Use an appropriate decimal type or an integer representation for financial values.

That’s a Wrap

The useful part of the ECMAScript 2026 standard is not a dramatic change to the language. It is that several common use cases now have direct names: get a Map value or create it, preserve the original digits from JSON, encode bytes without pretending they are text, collect an asynchronous sequence, recognize a real Error, sum numbers with less loss and join iterables lazily. None of these APIs will transform an application on its own. They can, however, replace code that is easy to repeat (boilerplate code), easy to get slightly wrong or harder to understand than the operation it performs.

That is why JavaScript has become nicer to use!

Make sure to check runtime support before using these additions in production. The standard defines the language, but every runtime follows its own release schedule. You can get the source code for some of the examples on GitHub.

Further Reading

• ECMAScript 2026 language specification
• TC39 finished proposals at the ECMAScript 2026 cutoff

In the modern fast-paced era, teams need more than a simple to-do list. They need structured, visual workflows that reflect real project states, support multiple roles and integrate smoothly into existing processes. The Progress Telerik UI for Blazor TaskBoard, also known as a Kanban Board, is purpose-built for exactly that.

In this post, we will explore the key TaskBoard features and walk through a practical two-role enterprise scenario: an administrator who configures the board and a user who works with the tasks.

What Is the Telerik UI for Blazor TaskBoard?

The TelerikTaskBoard component displays task and progress information as Cards organized in Columns. The component supports:

• Flexible data binding with convention-based or custom property names
• Drag-and-drop for Cards and Columns
• Built-in and custom toolbar tools
• CRUD operations for Cards and Columns
• A rich event model
• Card priorities with color coding
• Column-level restrictions about the maximum allowed number of Cards
• Customizable templates for Cards and Column headers

Data Binding

The TaskBoard recognizes a set of default model property names out of the box, which means you can bind your data without any extra configuration as long as your classes follow the naming convention. For simplicity, the examples in this blog post will follow the default conventions.

The Status property is the link between Cards and Columns: a Card is rendered inside the Column with a matching Status value. If your domain model uses different property names, you can map them via parameters such as CardStatusField, ColumnStatusField, etc.

Card Model

public class TaskBoardCard 
{ 
    public int    Id          { get; set; } 
    public int    Index       { get; set; } 
    public string Title       { get; set; } 
    public string Description { get; set; } 
    public string Status      { get; set; } 
    public string Priority    { get; set; } 
} 

Column Model

public class TaskBoardColumn 
{ 
    public int                     Index    { get; set; } 
    public string                  Status   { get; set; } 
    public string                  Title    { get; set; } 
    public string                  Width    { get; set; } 
    public int?                    WipLimit { get; set; } 
    public bool                    Enabled  { get; set; } 
    public TaskBoardColumnButtons? Buttons  { get; set; } 
} 

Drag and Drop

Drag-and-drop is the signature UX feature of any Kanban board, and the TaskBoard delivers it with minimal setup.

Dragging Cards

Card-dragging is enabled by default (CardDraggable="true"). When a user drops a Card into a different column or a different position within the same column, the OnCardMove event fires. Update the Card’s Index and Status in the handler:

<TelerikTaskBoard OnCardMove="@OnTaskBoardCardMove" /> 
 
@code { 
    private void OnTaskBoardCardMove(TaskBoardCardMoveEventArgs<TaskBoardCard> args) 
    { 
        args.Item.Index  = args.NewIndex; 
        args.Item.Status = args.NewStatus; 
    } 
} 

Reordering Columns

Column reordering is disabled by default (ColumnReorderable="false"). When enabled, the OnColumnReorder event gives you the old and new index so you can update the original data source or cancel the operation:

<TelerikTaskBoard ColumnReorderable="true" 
                  OnColumnReorder="@OnColumnReorder" /> 
 
@code { 
    private void OnColumnReorder(TaskBoardColumnReorderEventArgs<TaskBoardColumn> args) 
    { 
        // Use args.NewIndex to update the original Column data source 
        // or 
        // args.IsCancelled = true; // Revert the reordering 
    } 
} 

Editing Cards and Columns

The TaskBoard supports built-in create, edit and delete operations for both Cards and Columns.

Card CRUD Events

Each operation requires a corresponding event handler that updates your data collection:

<TelerikTaskBoard CardData="@TaskBoardCards" 
                  OnCardCreate="@OnCreate" 
                  OnCardUpdate="@OnUpdate" 
                  OnCardDelete="@OnDelete" /> 
 
@code { 
    private List<TaskBoardCard> TaskBoardCards { get; set; } = new List<TaskBoardCard>(); 
 
    private void OnCreate(TaskBoardCardCreateEventArgs<TaskBoardCard> args) 
    { 
        args.Item.Id = 12345; 
 
        TaskBoardCards.Add(args.Item); 
    } 
 
    private void OnUpdate(TaskBoardCardUpdateEventArgs<TaskBoardCard> args) 
    { 
        args.OriginalItem.Title       = args.Item.Title; 
        args.OriginalItem.Description = args.Item.Description; 
        args.OriginalItem.Priority    = args.Item.Priority; 
    } 
 
    private void OnDelete(TaskBoardCardDeleteEventArgs<TaskBoardCard> args) 
    { 
        TaskBoardCards.Remove(args.Item); 
    } 
} 

Column CRUD Events

Column operations follow the same pattern. When a Column is deleted, the app decides what to do with orphaned Cards—keep them, delete them or move them to another column:

<TelerikTaskBoard ColumnData="@TaskBoardColumns" 
                  OnColumnCreate="@OnTaskBoardColumnCreate" 
                  OnColumnDelete="@OnTaskBoardColumnDelete" 
                  OnColumnUpdate="@OnTaskBoardColumnUpdate" /> 
 
@code { 
    private List<TaskBoardColumn> TaskBoardColumns { get; set; } = new List<TaskBoardColumn>(); 
 
    private void OnTaskBoardColumnCreate(TaskBoardColumnCreateEventArgs<TaskBoardColumn> args) 
    { 
        args.Item.Status = "new-unique-status"; 
        TaskBoardColumns.Add(args.Item); 
    } 
 
    private void OnTaskBoardColumnDelete(TaskBoardColumnDeleteEventArgs<TaskBoardColumn> args) 
    { 
        TaskBoardColumns.Remove(args.Item); 
    } 
 
    private void OnTaskBoardColumnUpdate(TaskBoardColumnUpdateEventArgs<TaskBoardColumn> args) 
    { 
        args.OriginalItem.Title = args.Item.Title; 
        args.OriginalItem.Status = args.Item.Status; 
        args.OriginalItem.Width = args.Item.Width; 
        args.OriginalItem.WipLimit = args.Item.WipLimit; 
    } 
} 

ToolBar

The TaskBoardToolBar sits above the Columns and provides both built-in and custom tools. With regard to editing, the ToolBar provides a built-in <TaskBoardToolBarAddColumnTool /> component that renders a Button that fires the OnColumnCreate event.

<TelerikTaskBoard> 
    <TaskBoardToolBar> 
        <TaskBoardToolBarAddColumnTool Icon="@SvgIcon.Plus" /> 
    </TaskBoardToolBar> 
</TelerikTaskBoard> 

Two-Role TaskBoard Use Case

A common pattern separates the board configuration from day-to-day usage. The following samples demonstrate this pattern with two TaskBoard instances that share the same column settings.

Administrator Role: Configuring the Board Columns

The administrator starts from an empty TelerikTaskBoard to create and manage the workflow stages (e.g., Backlog, In Progress, Under Review, Done).

A TelerikGrid with inline editing and row drag-and-drop lets the administrator define the available priority levels and assign a color to each. A TelerikColorPalette editor uses color values from the Telerik CSS theme.

@using System.Text.Json 
 
@inject IJSRuntime JS 
 
<h1>TaskBoard Management</h1> 
 
<h2>TaskBoard Columns</h2> 
 
<TelerikTaskBoard CardData="@TaskBoardCards" 
                  ColumnData="@TaskBoardColumns" 
                  ColumnReorderable="true" 
                  Height="300px" 
                  OnColumnCreate="@OnTaskBoardColumnCreate" 
                  OnColumnDelete="@OnTaskBoardColumnDelete" 
                  OnColumnReorder="@OnTaskBoardColumnReorder" 
                  OnColumnUpdate="@OnTaskBoardColumnUpdate" 
                  TColumn="@TaskBoardColumn" 
                  TItem="@TaskBoardCard"> 
    <TaskBoardSettings> 
        <TaskBoardColumnSettings Buttons="@(TaskBoardColumnButtons.EditColumn | TaskBoardColumnButtons.DeleteColumn)" 
                                 Width="300px" /> 
    </TaskBoardSettings> 
    <TaskBoardToolBar> 
        <TaskBoardToolBarAddColumnTool Icon="@SvgIcon.Plus" /> 
    </TaskBoardToolBar> 
</TelerikTaskBoard> 
 
<h2>Task Priorities</h2> 
 
<TelerikGrid Data="@TaskBoardPriorities" 
             ConfirmDelete="true" 
             EditMode="@GridEditMode.Inline" 
             OnUpdate="@OnGridUpdate" 
             OnCreate="@OnGridCreate" 
             OnDelete="@OnGridDelete" 
             RowDraggable="true" 
             OnRowDrop="@OnGridRowDrop" 
             TItem="@TaskBoardCardPriority"> 
    <GridToolBarTemplate> 
        <GridCommandButton Command="Add">Add Item</GridCommandButton> 
    </GridToolBarTemplate> 
    <GridColumns> 
        <GridColumn Field="@nameof(TaskBoardCardPriority.Text)" /> 
        <GridColumn Field="@nameof(TaskBoardCardPriority.Color)"> 
            <Template> 
                @{ TaskBoardCardPriority priority = (TaskBoardCardPriority)context; } 
                <div class="priority-color"> 
                    <strong style="background-color: @(priority.Color);"></strong> 
                    <span>@GetColorKeyword(priority.Color)</span> 
                </div> 
            </Template> 
            <EditorTemplate> 
                @{ TaskBoardCardPriority priority = (TaskBoardCardPriority)context; } 
                <TelerikColorPalette @bind-Value="@priority.Color" 
                                     Colors="@PriorityColors" 
                                     Columns="6" 
                                     Size="@ThemeConstants.ColorPalette.Size.Large" /> 
            </EditorTemplate> 
        </GridColumn> 
        <GridCommandColumn Title="Commands"> 
            <GridCommandButton Command="Edit">Edit</GridCommandButton> 
            <GridCommandButton Command="Save" ShowInEdit="true">Save</GridCommandButton> 
            <GridCommandButton Command="Cancel" ShowInEdit="true">Cancel</GridCommandButton> 
            <GridCommandButton Command="Delete">Delete</GridCommandButton> 
        </GridCommandColumn> 
    </GridColumns> 
</TelerikGrid> 
 
<TelerikButton OnClick="@OnConfirmTaskBoardClick">Confirm TaskBoard Configuration</TelerikButton> 
 
<style> 
    .priority-color { 
        display: flex; 
        align-items: center; 
    } 
 
    .priority-color > strong { 
        display: inline-block; 
        width: 1.2em; 
        height: 1.2em; 
        margin-right: .5em; 
    } 
</style> 
 
@code { 
    private List<TaskBoardCard> TaskBoardCards { get; set; } = new List<TaskBoardCard>(); 
    private List<TaskBoardColumn> TaskBoardColumns { get; set; } = new List<TaskBoardColumn>(); 
    private List<TaskBoardCardPriority> TaskBoardPriorities { get; set; } = new List<TaskBoardCardPriority>() 
        { 
            new TaskBoardCardPriority() { Text = "Low", Value = "low", Color = "var(--kendo-color-success)" }, 
            new TaskBoardCardPriority() { Text = "Normal", Value = "normal", Color = "var(--kendo-color-info)" }, 
            new TaskBoardCardPriority() { Text = "High", Value = "high", Color = "var(--kendo-color-warning)"}, 
            new TaskBoardCardPriority() { Text = "Critical", Value = "critical", Color = "var(--kendo-color-error)" } 
        }; 
 
    private void OnTaskBoardColumnCreate(TaskBoardColumnCreateEventArgs<TaskBoardColumn> args) 
    { 
            args.Item.Status = $"status-{++LastId}"; 
            TaskBoardColumns.Add(args.Item); 
    } 
 
    private void OnTaskBoardColumnDelete(TaskBoardColumnDeleteEventArgs<TaskBoardColumn> args) 
    { 
        TaskBoardColumns.Remove(args.Item); 
 
        TaskBoardCards.RemoveAll(c => c.Status == args.Item.Status); 
    } 
 
    private void OnTaskBoardColumnReorder(TaskBoardColumnReorderEventArgs<TaskBoardColumn> args) 
    { 
 
    } 
 
    private void OnTaskBoardColumnUpdate(TaskBoardColumnUpdateEventArgs<TaskBoardColumn> args) 
    { 
        args.OriginalItem.Title = args.Item.Title; 
        args.OriginalItem.Status = args.Item.Status; 
        args.OriginalItem.Width = args.Item.Width; 
        args.OriginalItem.WipLimit = args.Item.WipLimit; 
    } 
 
    private async Task OnConfirmTaskBoardClick() 
    { 
        await JS.InvokeVoidAsync("localStorage.setItem", 
                new object\\\[] { "taskboard-columns", JsonSerializer.Serialize(TaskBoardColumns) }); 
 
        await JS.InvokeVoidAsync("localStorage.setItem", 
                new object\\\[] { "taskboard-priorities", JsonSerializer.Serialize(TaskBoardPriorities) }); 
    } 
 
    private readonly string\\\[] PriorityColors = new string\\\[] 
    { 
        "var(--kendo-color-info)", 
        "var(--kendo-color-primary)", 
        "var(--kendo-color-secondary)", 
        "var(--kendo-color-tertiary)", 
        "var(--kendo-color-inverse)", 
        "var(--kendo-color-success)", 
        "var(--kendo-color-warning)", 
        "var(--kendo-color-error)", 
        "var(--kendo-color-series-b)", 
        "var(--kendo-color-series-c)", 
        "var(--kendo-color-series-d)", 
        "var(--kendo-color-series-f)" 
    }; 
 
    private string GetColorKeyword(string themeColorName) 
    { 
        return themeColorName.Replace("var(--kendo-color-", "").Replace(")", ""); 
    } 
 
    private void OnGridDelete(GridCommandEventArgs args) 
    { 
        TaskBoardCardPriority deletedItem = (TaskBoardCardPriority)args.Items.First(); 
 
        TaskBoardPriorities.Remove(deletedItem); 
    } 
 
    private void OnGridCreate(GridCommandEventArgs args) 
    { 
        TaskBoardCardPriority createdItem = (TaskBoardCardPriority)args.Items.First(); 
 
        TaskBoardPriorities.Insert(0, createdItem); 
    } 
 
    private void OnGridRowDrop(GridRowDropEventArgs<TaskBoardCardPriority> args) 
    { 
        TaskBoardPriorities.Remove(args.Item); 
 
        int destinationItemIndex = TaskBoardPriorities.IndexOf(args.DestinationItem); 
        if (args.DropPosition == GridRowDropPosition.After) 
        { 
            destinationItemIndex++; 
        } 
 
        TaskBoardPriorities.Insert(destinationItemIndex, args.Item); 
    } 
 
    private void OnGridUpdate(GridCommandEventArgs args) 
    { 
        TaskBoardCardPriority updatedItem = (TaskBoardCardPriority)args.Items.First(); 
        int originalItemIndex = TaskBoardPriorities.FindIndex(i => i.Value == updatedItem.Value); 
 
        if (originalItemIndex != -1) 
        { 
            TaskBoardPriorities\\\[originalItemIndex] = updatedItem; 
        } 
    } 
 
    private int LastId { get; set; } 
 
    public class TaskBoardCard 
    { 
        public string Description { get; set; } = string.Empty; 
        public int Id { get; set; } 
        public int Index { get; set; } 
        public string Priority { get; set; } = string.Empty; 
        public string Status { get; set; } = string.Empty; 
        public string Title { get; set; } = string.Empty; 
    } 
 
    public class TaskBoardColumn 
    { 
        public TaskBoardColumnButtons? Buttons { get; set; } 
        public bool Enabled { get; set; } = true; 
        public int Index { get; set; } 
        public string Status { get; set; } = string.Empty; 
        public string Title { get; set; } = string.Empty; 
        public string Width { get; set; } = string.Empty; 
        public int? WipLimit { get; set; } 
    } 
} 

User Role: Working with Tasks

The second example demonstrates the user’s workspace. It loads the column and priority definitions saved by the administrator and then presents a fully operational TelerikTaskBoard where cards can be created, edited, moved and deleted.

Notice that the column management buttons are absent, and the user can only manage cards. The TaskBoardSearchBox tool lets them quickly filter cards by title or description. The task priorities automatically color-code the left border of each card.

@using System.Text.Json 
@using Telerik.Blazor.Components.TaskBoard 
 
@inject IJSRuntime JS 
 
<PageTitle>Counter</PageTitle> 
 
<TelerikTaskBoard CardData="@TaskBoardCards" 
                  ColumnData="@TaskBoardColumns" 
                  ColumnReorderable="true" 
                  Height="600px" 
                  Priorities="@TaskBoardPriorities" 
                  OnCardCreate="@OnTaskBoardCardCreate" 
                  OnCardDelete="@OnTaskBoardCardDelete" 
                  OnCardMove="@OnTaskBoardCardMove" 
                  OnCardUpdate="@OnTaskBoardCardUpdate" 
                  TColumn="@TaskBoardColumn" 
                  TItem="@TaskBoardCard"> 
    <TaskBoardSettings> 
        <TaskBoardColumnSettings Buttons="@(TaskBoardColumnButtons.AddCard)" 
                                 Width="300px" /> 
    </TaskBoardSettings> 
    <TaskBoardToolBar> 
        <TaskBoardSearchBox /> 
    </TaskBoardToolBar> 
</TelerikTaskBoard> 
 
@code { 
    private List<TaskBoardCard> TaskBoardCards { get; set; } = new List<TaskBoardCard>(); 
    private List<TaskBoardColumn> TaskBoardColumns { get; set; } = new List<TaskBoardColumn>(); 
    private List<TaskBoardCardPriority> TaskBoardPriorities { get; set; } = new List<TaskBoardCardPriority>(); 
 
    private void OnTaskBoardCardCreate(TaskBoardCardCreateEventArgs<TaskBoardCard> args) 
    { 
        args.Item.Id = ++LastId; 
 
        // Optionally, add the Card to the bottom of the column 
        //int maxIndexInColumn = TaskBoardCards.Where(c => c.Status == args.Item.Status).Select(c => c.Index).DefaultIfEmpty(0).Max(); 
        //args.Item.Index = ++maxIndexInColumn; 
 
        TaskBoardCards.Add(args.Item); 
    } 
 
    private void OnTaskBoardCardDelete(TaskBoardCardDeleteEventArgs<TaskBoardCard> args) 
    { 
        TaskBoardCards.Remove(args.Item); 
    } 
 
    private void OnTaskBoardCardMove(TaskBoardCardMoveEventArgs<TaskBoardCard> args) 
    { 
        args.Item.Index = args.NewIndex; 
        args.Item.Status = args.NewStatus; 
    } 
 
    private void OnTaskBoardCardUpdate(TaskBoardCardUpdateEventArgs<TaskBoardCard> args) 
    { 
        args.OriginalItem.Description = args.Item.Description; 
        args.OriginalItem.Index = args.Item.Index; 
        args.OriginalItem.Priority = args.Item.Priority; 
        args.OriginalItem.Title = args.Item.Title; 
        args.OriginalItem.Status = args.Item.Status; 
    } 
 
    protected override async Task OnAfterRenderAsync(bool firstRender) 
    { 
        if (firstRender) 
        { 
            //TaskBoardColumns = await LocalStorage.GetItem<List<TaskBoardColumn>>("taskboard-columns") ?? new List<TaskBoardColumn>(); 
            //TaskBoardPriorities = await LocalStorage.GetItem<List<TaskBoardCardPriority>>("taskboard-priorities") ?? new List<TaskBoardCardPriority>(); 
 
            string serializedColumns = await JS.InvokeAsync<string>("localStorage.getItem", "taskboard-columns"); 
            TaskBoardColumns = JsonSerializer.Deserialize<List<TaskBoardColumn>>(serializedColumns) ?? new List<TaskBoardColumn>(); 
 
            string serializedPriorities = await JS.InvokeAsync<string>("localStorage.getItem", "taskboard-priorities"); 
            TaskBoardPriorities = JsonSerializer.Deserialize<List<TaskBoardCardPriority>>(serializedPriorities) ?? new List<TaskBoardCardPriority>(); 
 
            StateHasChanged(); 
        } 
    } 
 
    private int LastId { get; set; } 
 
    public class TaskBoardCard 
    { 
        public string Description { get; set; } = string.Empty; 
        public int Id { get; set; } 
        public int Index { get; set; } 
        public string Priority { get; set; } = string.Empty; 
        public string Status { get; set; } = string.Empty; 
        public string Title { get; set; } = string.Empty; 
    } 
 
    public class TaskBoardColumn 
    { 
        public TaskBoardColumnButtons? Buttons { get; set; } 
        public bool Enabled { get; set; } = true; 
        public int Index { get; set; } 
        public string Status { get; set; } = string.Empty; 
        public string Title { get; set; } = string.Empty; 
        public string Width { get; set; } = string.Empty; 
        public int? WipLimit { get; set; } 
 
        public TaskBoardColumn Clone() 
        { 
            return new TaskBoardColumn() 
            { 
                Status = this.Status, 
                Title = this.Title, 
                Width = this.Width, 
                WipLimit = this.WipLimit 
            }; 
        } 
    } 
} 

Key Takeaways

The Telerik UI for Blazor TaskBoard fits naturally into enterprise workflows with its data-driven and event-driven architecture. Here are the design principles the examples above demonstrate:

• Separation of concerns – Board structure (columns, priorities) lives apart from the task data, enabling role-based access and centralized configuration.
• Convention-based models – Default property names (Status, Index, Title, etc.) eliminate boilerplate configuration while still allowing full customization via field-mapping parameters.
• Event-sourced mutations – Every user action fires a cancellable event. Your handlers decide what gets persisted and how, making integration with any backend straightforward.
• Progressive disclosure – TaskBoardCardSettings and TaskBoardColumnSettings let you show exactly the right buttons to the right roles.
• Theme-aware colors – Using CSS theme variables (var(--kendo-color-error)) for priority colors enables visual consistency across Telerik themes with zero extra work.

Resources

• TaskBoard Documentation
• TaskBoard Live Demos

Ready to Experiment with the TaskBoard Control?

TaskBoard and 120 other Telerik UI for Blazor components are all available for a free 30-day trial:

Try Now

Two requests arrive at your application at the exact same moment. Both read the same data, both attempt to update it, and everything appears to work correctly. Yet one update silently overwrites the other. This is a classic race condition. In this post, you’ll see how these problems arise and how to prevent them using common concurrency control techniques.

Working with systems that execute multiple operations in milliseconds is not a distant reality. On the contrary, in medium- and large-scale applications, this is a common scenario.

But along with this level of concurrency comes a problem that is often overlooked: race conditions. When not handled properly, they can lead to inconsistencies and even silently corrupt data.

In this post, we will explore the concept of race conditions, understand how to identify them in practice, and discuss strategies to protect our applications against this type of issue.

What Is a Race Condition?

According to Microsoft documentation on race conditions and deadlocks, a race condition occurs when two threads access and modify a shared resource at the same time. The final result depends on the order in which these operations are executed.

The problem is that this order is not guaranteed; it can vary with each execution. This leads to unpredictable behavior, such as inconsistent data, lost updates or invalid states.

Imagine two requests trying to update an account balance at the same time. Both read the same initial value, perform separate calculations and save the result. Depending on which one saves last, one update may overwrite the other, even if both were performed correctly in isolation.

When Do Race Conditions Occur?

Race conditions don’t appear “out of nowhere.” They usually arise from some very common code and architectural patterns. Below, we’ll look at two of the best-known: Read-Modify-Write and Check-Then-Act.

Read-Modify-Write

The idea here is simple: you read a value, make some modification to it and then write it back. The problem starts when two or more executions do this at the same time. Consider the image below:

Note that both readings happen simultaneously, returning the value of 50. However, Thread A adds 20 to the initial value, while Thread B adds 10. The problem occurs when Thread A updates the initial value (50) to 70, while Thread B updates it 1 second later with the value of 60, completely disregarding the value previously added by Thread A.

The result is an incorrectly calculated value, something that would certainly cause losses in a production environment.

Check-Then-Act

The Check-Then-Act pattern is often even more subtle than the previous pattern. The problem with this pattern is not in updating a value, but in making a decision based on a state that may change before the action takes place. Consider the image below:

In this case we have two threads that check the stock quantity of a product. In both queries, the quantity is 1, and even though there is a check, both purchases were executed based on an invalid state. After all, when Thread A executed the purchase, there was no longer any quantity available for Thread B. If this problem had occurred in a real environment, the client of Thread B would have been left without the product.

Avoiding Race Conditions

Now that we’ve learned how to identify a race condition, let’s understand how to prevent it from happening. There are different strategies to protect ASP.NET Core applications against concurrency issues, and choosing the most appropriate approach depends on the scenario.

The main point is to understand that any concurrent operation involving shared state needs to be handled with care.

Understanding the Concept of Thread Safety

Thread safety is the ability of code or a resource to function correctly even when accessed simultaneously by multiple threads.

We can say that thread-safe code means that data is not corrupted, the state remains valid, and the behavior does not depend on the order of execution of the threads.

1. Using Locks

A lock is a mechanism used to make an operation thread-safe. It allows only one thread to execute a given piece of code at a time.

Consider the code below:

using System;
using System.Threading;
using System.Threading.Tasks;

public class ProductService
{
    private static readonly object _lock = new();

    // Simulating a stock quantity
    private int _stock = 1;

    public void Purchase(string customer)
    {
        Console.WriteLine($"{customer} is waiting to enter the critical section...");

        lock (_lock)
        {
            Console.WriteLine($"{customer} entered the critical section.");

            if (_stock <= 0)
            {
                Console.WriteLine($"{customer} could not complete the purchase. Product out of stock.");
                return;
            }

            Console.WriteLine($"{customer} is processing the purchase...");

            // Simulating a slow operation
            Thread.Sleep(3000);

            _stock--;

            Console.WriteLine($"{customer} completed the purchase.");
            Console.WriteLine($"Remaining stock: {_stock}");
        }

        Console.WriteLine($"{customer} left the critical section.");
    }
}

public class Program
{
    public static async Task Main()
    {
        var service = new ProductService();

        var task1 = Task.Run(() => service.Purchase("Customer A"));
        var task2 = Task.Run(() => service.Purchase("Customer B"));

        await Task.WhenAll(task1, task2);
    }
}

You can run this code in Fiddle and get the following result:

The idea here is to simulate a scenario where only one unit of stock is available for two customers attempting to make a purchase simultaneously. Note that we declare a static object _lock, which acts as a guardian for the critical section of the code, so only one thread at a time can execute the logic block that checks and decrements the stock.

When the request is triggered, two distinct tasks are initiated in parallel for customers A and B. If we didn’t use the locking structure, both could read the stock value as available at the same time, resulting in a duplicate sale of an item that only exists once, which constitutes a race condition.

However, the use of the lock instruction forces a waiting queue. While the first customer processes their purchase and the system waits (Thread.Sleep), the second customer remains held at the entrance of the critical section.

Only after the first customer’s transaction is completed and the stock is updated to zero is the lock released for the next customer. Upon entering the critical section, the second client performs a logical security check, realizes that the stock has been depleted by the previous processing and ends the purchase attempt without causing data inconsistencies.

The end result is a predictable execution flow, where we guarantee data integrity in a critical scenario under concurrent demand.

2. Using SemaphoreSlim

As we saw above, a lock blocks the current thread until the critical region is released. This may not always be a good strategy, as in some cases it can reduce the scalability of the application. In these cases, SemaphoreSlim may be a more suitable alternative.

In ASP.NET Core, SemaphoreSlim is a built-in class used to limit the number of threads that can access a resource or a section of code simultaneously. When set to 1, it works similarly to a lock, allowing only one execution at a time. Consider the example below:

using System;
using System.Threading;
using System.Threading.Tasks;

public class Program
{
    public static async Task Main()
    {
        var service = new ProductService();

        var task1 = Task.Run(() => service.PurchaseAsync("Customer A"));
        var task2 = Task.Run(() => service.PurchaseAsync("Customer B"));

        await Task.WhenAll(task1, task2);

        Console.WriteLine("Finished.");
    }
}

public class ProductService
{
    private readonly SemaphoreSlim _semaphore = new(1, 1);
    private int _stock = 1;

    public async Task PurchaseAsync(string customer)
    {
        Console.WriteLine($"{customer} is waiting to enter the critical section...");

        await _semaphore.WaitAsync();

        try
        {
            Console.WriteLine($"{customer} entered the critical section.");

            if (_stock <= 0)
            {
                Console.WriteLine($"{customer} could not complete the purchase. Product out of stock.");
                return;
            }

            Console.WriteLine($"{customer} is processing the purchase...");

            // Simulates an asynchronous operation
            await Task.Delay(3000);

            _stock--;

            Console.WriteLine($"{customer} completed the purchase.");
            Console.WriteLine($"Remaining stock: {_stock}");
        }
        finally
        {
            _semaphore.Release();

            Console.WriteLine($"{customer} left the critical section.");
        }
    }
}

You can run this code in Fiddle and get the following result:

In this code, we create an instance of SemaphoreSlim, passing an initial and maximum value of 1 as a parameter. Thus, when two threads attempt to execute PurchaseAsync simultaneously, the first thread enters SemaphoreSlim while the second waits.
After the first operation is completed, the semaphore is released and the second thread can finally continue.

As in the example with lock, this prevents two operations from altering the stock at the same time. Tthe difference here is that the threads are asynchronous, and we also have the possibility of configuring an initial and maximum value for the number of simultaneous threads.

3. Using Thread-Safe Collections

Another scenario prone to race condition problems is using collections shared between multiple threads. Structures such as List<T>, Dictionary<TKey, TValue> and HashSet<T> were not designed for concurrent access. This means that collections of these types allow multiple threads to read and modify their data, generating inconsistent data and unpredictable behavior.

Consider the example below:

   private readonly Dictionary<Guid, Product> _products = new();

    public void AddProduct(Product product)
    {
        _products.Add(product.Id, product);
    }

If multiple requests attempt to add or update items at the same time, the application may throw exceptions or even corrupt the internal state of the collection. The problem occurs because Dictionary<TKey, TValue> is not prepared for synchronization.

For concurrent scenarios, .NET provides thread-safe collections through the namespace System.Collections.Concurrent, one of the most commonly used being ConcurrentDictionary<TKey, TValue>. Thus, we can use ConcurrentDictionary with safe concurrent access between multiple threads:

   private readonly ConcurrentDictionary<Guid, Product> _concurrentProducts = new();

    public void AddConcurrentProduct(Product product)
    {
        _concurrentProducts.TryAdd(product.Id, product);
    }

    public Product? GetProduct(Guid id)
    {
        _concurrentProducts.TryGetValue(id, out var product);

        return product;
    }

Now multiple threads can read _concurrentProducts at the same time, and concurrent operations are handled internally.

4. Using Optimistic Concurrency

Optimistic concurrency is another option for avoiding race conditions, especially in modern applications.

Unlike previously seen approaches such as locking or SemaphoreSlim, it does not attempt to prevent simultaneous accesses. Instead, it assumes that conflicts are rare and only detected when they occur.

Imagine that multiple operations can read the same data simultaneously. The first update happens normally, but subsequent updates fail if the data has been changed in the middle of the process. This prevents silent overwrites and provides consistency.

Consider the image below:

Note that both threads read the value at the same time (stock = 10, version 1), but Thread A was faster and updated the value first (stock = 9, version 2). When Thread B tries to update the value, an exception is generated because version 2 already exists. This verifies the consistency of the object’s initial state; in this case, the stock quantity does not receive an invalid state.

Implementing Optimistic Concurrency with EF Core

Entity Framework Core has a mechanism for using Optimistic Concurrency. To implement it, in an entity class we define a Version column as follows:

using System.ComponentModel.DataAnnotations;

namespace PracticingRaceConditions.Models;

public class Product
{
    public Guid Id { get; internal set; }
    public string Name { get; set; } = string.Empty;

    public int Stock { get; set; }

    [Timestamp]
    public byte[] Version { get; set; } = default!;
}

This Version column informs EF Core that it will be used by the Optimistic Concurrency mechanism, and when two threads attempt to update the same record with the same version, an exception will be thrown.

To simulate the error, we can do the following:

public async Task SimulatingPurchaseAsync()
{
    var options = new DbContextOptionsBuilder<ProductDbContext>()
        .UseSqlite("Data Source=productsDb")
        .Options;

    // Request A
    using var contextA = new ProductDbContext(options);

    // Request B
    using var contextB = new ProductDbContext(options);

    var productA = await contextB.Products.FirstOrDefaultAsync();

    var productB = await contextB.Products.FirstOrDefaultAsync();

    productA.Stock--;
    productB.Stock--;

    // Request A saves first
    await contextA.SaveChangesAsync();

    try
    {
        // Request B attempts to save using an outdated version
        await contextB.SaveChangesAsync();
    }
    catch (DbUpdateConcurrencyException)
    {
        Console.WriteLine("Concurrency conflict detected!");
    }
}

If we execute the SimulatingPurchaseAsync() method, we will get the following output in the console:

Note that when executing the SimulatingPurchaseAsync() method, we simulate two stock changes at the same time. When saving the result of Thread A, execution occurs normally because a version 2 of the product did not yet exist. But when trying to save the result of Thread B, a DbUpdateConcurrencyException exception is thrown, because EF Core detected that a version 2 was again trying to update the record.

In this way, we can use the EF Core’s Optimistic Concurrency mechanism to prevent the race condition problem.

Conclusion

The race condition problem occurs when two threads access and modify the same resource at the same time, which can result in an invalid state depending on the order in which the operations are performed.

In this post, we’ve seen common examples where race conditions can occur, and learned how protect our code from these problems through approaches like Locks, SemaphoreSlim, Thread-Safe Collections and Optimistic Concurrency with EF Core. I hope this post has helped you understand what race conditions are and how to protect your applications from errors resulting from this type of problem.

In this post, you’ll learn how to structure an ASP.NET Core project following CRUD best practices, even when the premise is simple. The idea here is to build something you can actually use as a portfolio.

In addition, we’ll focus on decisions that experienced developers make daily: how to avoid unnecessary coupling, how to better model the domain, and how to prepare your application to grow without becoming chaotic.

By the end of the post, you’ll have a solid foundation on how to create a CRUD application ready to evolve into something bigger, maybe with authentication, messaging, caching, or even an event-driven architecture.

The Problem with Generic CRUDs

You’ve probably faced a requirement like this at some point: Create a simple, straightforward CRUD that only performs the basic operations of Create, Read, Update and Delete, with entities representing tables, and everything working in a few minutes. And that’s not wrong. The problem starts when this same model, designed for prototyping, is taken to production without being prepared for future evolution.

One of the clearest signs of a basic CRUD is the use of anemic entities, classes that only have properties, without any behavior:

public class User
{
    public string Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

Here, the entity does not protect its own state. Therefore, it can be created with an empty name, it can have an invalid email, it can be changed from anywhere. In other words, there is no business rule, just a simple data structure.

Another classic symptom of a prematurely scaled CRUD is having rules and validations scattered throughout the code. In basic CRUDs, when rules appear, they are scattered a bit in the Controller class, a bit in the Service class, and in the worst cases they don’t even exist.

Consider the example below:

   if (string.IsNullOrWhiteSpace(user.Name))
        return Results.BadRequest();

This solves the immediate problem, but creates a bigger one: the rule doesn’t belong to the domain, it’s loose in the system. Therefore, as the system grows, validations can be duplicated, lose consistency and become harder to find everywhere because they are scattered.

The biggest problem here is that you’ve only modeled the data, not the system. Basic CRUDs focus on basic operations: creating, reading, updating and deleting data. But real systems are about behavior: A user can register, they can deactivate their account, they can change their email based on internal validations, they can have a preferred name, they can change their address …

When you only model data, the system loses meaning and becomes just a data handling tool, which can easily be replaced by anything else, like a simple Excel spreadsheet for example.

The opposite of this are applications that, despite using only basic operations, are prepared for new features that will likely be needed. The image below illustrates the main points of both approaches:

Creating a CRUD Ready for Production

Now that we’ve reviewed some examples to avoid, let’s see how to create a complete CRUD application, organizing each part of the code according to best practices and preparing the project for evolution. You can access the complete project code in this GitHub repository: Campus Hub source code.

Architecture and Basic Structure

The application will be a CRUD to manage university courses, which can be registered, updated and deactivated. We will use the principles of Clean Architecture combined with tactical Domain-Driven Design (DDD) to create the basic structure of the project. Thus, the application will have the following project organization:

src/

• Presentation -> CampusHub.Api
• Application -> CampusHub.Application
• Domain -> CampusHub.Domain
• Infrastructure -> CampusHub.Infrastructure

Let’s run the .NET commands to create the projects. In a terminal, execute the command below:

dotnet new sln -n CampusHub

This will create a new solution (CampusHub.sln). Then, to create the projects within the src directory, run the following command:

dotnet new webapi -n CampusHub.Api -o src/CampusHub.Api
dotnet new classlib -n CampusHub.Application -o src/CampusHub.Application
dotnet new classlib -n CampusHub.Domain -o src/CampusHub.Domain
dotnet new classlib -n CampusHub.Infrastructure -o src/CampusHub.Infrastructure

Now, to add the projects to the solution, run the following command:

dotnet sln add src/CampusHub.Api/CampusHub.Api.csproj
dotnet sln add src/CampusHub.Application/CampusHub.Application.csproj
dotnet sln add src/CampusHub.Domain/CampusHub.Domain.csproj
dotnet sln add src/CampusHub.Infrastructure/CampusHub.Infrastructure.csproj

Finally, run the following commands to add the dependencies between the projects:

dotnet add src/CampusHub.Application reference src/CampusHub.Domain
dotnet add src/CampusHub.Infrastructure reference src/CampusHub.Domain
dotnet add src/CampusHub.Infrastructure reference src/CampusHub.Application
dotnet add src/CampusHub.Api reference src/CampusHub.Application
dotnet add src/CampusHub.Api reference src/CampusHub.Infrastructure

Then, in the CampusHub.Infrastructure.cs add the following NuGet packages:

  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="8.0.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="8.0.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="8.0.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="Pomelo.EntityFrameworkCore.MySql" Version="8.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="8.0.0" />
  </ItemGroup>

Domain Layer

In the domain layer, we will place the project’s entities and enums. Therefore, we will have a class to represent the Course entity and an enum to represent the course statuses. So, within the CampusHub.Domain project, create a folder called Entities and add the following class inside it:

using CampusHub.Domain.Enums;

namespace CampusHub.Domain.Entities;

public class Course
{
    private const int MinNameLength = 3;
    private const int MaxNameLength = 200;
    private const int MinWorkload = 1;

    public Guid Id { get; private set; }
    public string Code { get; private set; } = string.Empty;
    public string Name { get; private set; } = string.Empty;
    public int WorkloadHours { get; private set; }
    public int MaxStudents { get; private set; }
    public CourseStatus Status { get; private set; }

    // EF Core requirement
    private Course() { }

    private Course(string code, string name, int workloadHours, int maxStudents)
    {
        Id = Guid.NewGuid();
        SetCode(code);
        SetName(name);
        SetWorkload(workloadHours);
        SetMaxStudents(maxStudents);

        Status = CourseStatus.Draft;
    }

    public static Course Create(string code, string name, int workloadHours, int maxStudents)
    {
        return new Course(code, name, workloadHours, maxStudents);
    }

    // Behavior methods
    public void UpdateDetails(string name, int workloadHours, int maxStudents)
    {
        EnsureNotArchived();

        SetName(name);
        SetWorkload(workloadHours);
        SetMaxStudents(maxStudents);
    }

    public void ChangeCapacity(int maxStudents)
    {
        EnsureNotArchived();

        SetMaxStudents(maxStudents);
    }

    public void Activate()
    {
        if (Status == CourseStatus.Active)
            throw new InvalidOperationException("Course is already active.");

        Status = CourseStatus.Active;
    }

    public void Archive()
    {
        if (Status == CourseStatus.Archived)
            throw new InvalidOperationException("Course is already archived.");

        Status = CourseStatus.Archived;
    }


    // Private validation logic
    private void SetCode(string code)
    {
        if (string.IsNullOrWhiteSpace(code))
            throw new ArgumentException("Course code cannot be empty.");

        Code = code.Trim().ToUpper();
    }

    private void SetName(string name)
    {
        if (string.IsNullOrWhiteSpace(name))
            throw new ArgumentException("Course name cannot be empty.");

        if (name.Length < MinNameLength || name.Length > MaxNameLength)
            throw new ArgumentException($"Course name must be between {MinNameLength} and {MaxNameLength} characters.");

        Name = name.Trim();
    }

    private void SetWorkload(int workloadHours)
    {
        if (workloadHours < MinWorkload)
            throw new ArgumentException("Workload must be greater than zero.");

        WorkloadHours = workloadHours;
    }

    private void SetMaxStudents(int maxStudents)
    {
        if (maxStudents <= 0)
            throw new ArgumentException("Max students must be greater than zero.");

        MaxStudents = maxStudents;
    }

    private void EnsureNotArchived()
    {
        if (Status == CourseStatus.Archived)
            throw new InvalidOperationException("Archived courses cannot be modified.");
    }
}

Note that this entity has an excellent structure. It is not anemic, meaning it has behaviors such as the Activate(), Archive() and UpdateDetails() methods.

Furthermore, you can never create an invalid Course because the verification methods protect against creating an invalid state. For example, an archived course cannot be modified, and an active course cannot be reactivated.

Now, create a new folder called Enums and add the following enum to it:

namespace CampusHub.Domain.Enums;

public enum CourseStatus
{
    Draft = 0,
    Active = 1,
    Archived = 2
}

Application Layer

The application layer is where we will configure the service classes with CRUD methods and Data Transfer Objects (DTOs). So, within the CampusHub.Application project, create a new folder called DTOs and create the following records inside it:

namespace CampusHub.Application.DTOs;

public record CourseResponseDto(
    Guid Id,
    string Code,
    string Name,
    int WorkloadHours,
    int MaxStudents,
    string Status
);

namespace CampusHub.Application.DTOs;

public record CreateCourseDto(
    string Code,
    string Name,
    int WorkloadHours,
    int MaxStudents
);

namespace CampusHub.Application.DTOs;

public record UpdateCourseDto(
    string Name,
    int WorkloadHours,
    int MaxStudents
);

Then, create a new folder called Interfaces and add the following interfaces to it:

using CampusHub.Domain.Entities;

namespace CampusHub.Application.Interfaces;

public interface ICourseRepository
{
    Task AddAsync(Course course);
    Task<Course?> GetByIdAsync(Guid id);
    Task<List<Course>> GetAllAsync();
    Task Update(Course course);
    Task<bool> ExistsByCodeAsync(string code);
}

using CampusHub.Application.DTOs;

namespace CampusHub.Application.Interfaces;

public interface ICourseService
{
    Task<Guid> CreateAsync(CreateCourseDto dto);
    Task UpdateAsync(Guid id, UpdateCourseDto dto);
    Task ActivateAsync(Guid id);
    Task ArchiveAsync(Guid id);
    Task<CourseResponseDto?> GetByIdAsync(Guid id);
    Task<List<CourseResponseDto>> GetAllAsync();
}

Finally, create a new folder called Services and add the class below to it:

using CampusHub.Application.Interfaces;
using CampusHub.Domain.Entities;
using CampusHub.Application.DTOs;

namespace CampusHub.Application.Services;

public class CourseService : ICourseService
{
    private readonly ICourseRepository _repository;

    public CourseService(ICourseRepository repository)
    {
        _repository = repository;
    }

    public async Task<Guid> CreateAsync(CreateCourseDto dto)
    {
        var exists = await _repository.ExistsByCodeAsync(dto.Code);
        if (exists)
            throw new InvalidOperationException("Course code already exists.");

        var course = Course.Create(
            dto.Code,
            dto.Name,
            dto.WorkloadHours,
            dto.MaxStudents
        );

        await _repository.AddAsync(course);

        return course.Id;
    }

    public async Task UpdateAsync(Guid id, UpdateCourseDto dto)
    {
        var course = await _repository.GetByIdAsync(id)
            ?? throw new InvalidOperationException("Course not found.");

        course.UpdateDetails(dto.Name, dto.WorkloadHours, dto.MaxStudents);

        await _repository.Update(course);
    }

    public async Task ActivateAsync(Guid id)
    {
        var course = await _repository.GetByIdAsync(id)
            ?? throw new InvalidOperationException("Course not found.");

        course.Activate();

        await _repository.Update(course);
    }

    public async Task ArchiveAsync(Guid id)
    {
        var course = await _repository.GetByIdAsync(id)
            ?? throw new InvalidOperationException("Course not found.");

        course.Archive();

        await _repository.Update(course);
    }

    public async Task<CourseResponseDto?> GetByIdAsync(Guid id)
    {
        var course = await _repository.GetByIdAsync(id);

        if (course is null)
            return null;

        return MapToResponse(course);
    }

    public async Task<List<CourseResponseDto>> GetAllAsync()
    {
        var courses = await _repository.GetAllAsync();

        return courses.Select(MapToResponse).ToList();
    }

    private static CourseResponseDto MapToResponse(Course course)
    {
        return new CourseResponseDto(
            course.Id,
            course.Code,
            course.Name,
            course.WorkloadHours,
            course.MaxStudents,
            course.Status.ToString()
        );
    }
}

Here we have all the methods we need to execute the CRUD functions. Note that to modify the state of the objects we use the methods created in the domain class.

Infrastructure Layer

Now let’s create the infrastructure layer, used for communication with external parts of the application such as external APIs and databases. Within the CampusHub.Infrastructure project, create a new folder called Data and add the following classes to it:

using CampusHub.Domain.Entities;
using Microsoft.EntityFrameworkCore;

namespace CampusHub.src.CampusHub.Infrastructure.Data;

public class AppDbContext : DbContext
{
    public DbSet<Course> Courses => Set<Course>();

    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
    {
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.ApplyConfigurationsFromAssembly(typeof(AppDbContext).Assembly);

        base.OnModelCreating(modelBuilder);
    }
}

using CampusHub.Domain.Entities;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;

namespace CampusHub.src.CampusHub.Infrastructure.Data;

public class CourseConfiguration : IEntityTypeConfiguration<Course>
{
    public void Configure(EntityTypeBuilder<Course> builder)
    {
        builder.ToTable("Courses");

        builder.HasKey(c => c.Id);

        builder.Property(c => c.Code)
            .IsRequired()
            .HasMaxLength(20);

        builder.HasIndex(c => c.Code)
            .IsUnique();

        builder.Property(c => c.Name)
            .IsRequired()
            .HasMaxLength(200);

        builder.Property(c => c.WorkloadHours)
            .IsRequired();

        builder.Property(c => c.MaxStudents)
            .IsRequired();

        builder.Property(c => c.Status)
            .IsRequired()
            .HasConversion<int>(); // Enum -> int

        builder.Property(c => c.Id)
            .ValueGeneratedNever();
    }
}

Here we made the necessary configurations for the EF Core implementation, defining database details such as the table name, maximum number of characters for the Name property and others.

Next, create a new folder called Repositories and add the following class to it:

using CampusHub.Application.Interfaces;
using CampusHub.Domain.Entities;
using CampusHub.src.CampusHub.Infrastructure.Data;
using Microsoft.EntityFrameworkCore;

namespace CampusHub.Infrastructure.Repositories;

public class CourseRepository : ICourseRepository
{
    private readonly AppDbContext _context;

    public CourseRepository(AppDbContext context)
    {
        _context = context;
    }

    public async Task AddAsync(Course course)
    {
        await _context.Courses.AddAsync(course);
        await _context.SaveChangesAsync();
    }

    public async Task<Course?> GetByIdAsync(Guid id)
    {
        return await _context.Courses.FirstOrDefaultAsync(c => c.Id == id);
    }

    public async Task<List<Course>> GetAllAsync()
    {
        return await _context.Courses.ToListAsync();
    }

    public async Task<bool> ExistsByCodeAsync(string code)
    {
        var normalizedCode = code.Trim().ToUpper();

        return await _context.Courses
            .AnyAsync(c => c.Code == normalizedCode);
    }

    public async Task Update(Course course)
    {
        _context.Courses.Update(course);
        await _context.SaveChangesAsync();
    }
}

In the repository class, we create the implementation of the CRUD methods that execute the operations on the database.

The last class in the infrastructure layer will be used to configure the dependency injection and define the connection string. So, inside the project add the class below:

using CampusHub.Application.Interfaces;
using CampusHub.Infrastructure.Repositories;
using CampusHub.src.CampusHub.Infrastructure.Data;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;

namespace CampusHub.Infrastructure;

public static class DependencyInjection
{
    public static IServiceCollection AddInfrastructure(this IServiceCollection services, IConfiguration configuration)
    {
        services.AddDbContext<AppDbContext>(options =>
        options.UseMySql(
            configuration.GetConnectionString("DefaultConnection"),
            ServerVersion.AutoDetect(configuration.GetConnectionString("DefaultConnection"))
        ));

        services.AddScoped<ICourseRepository, CourseRepository>();

        return services;
    }
}

API Layer

The API is the final layer of the application, here we will define the controller classes and other settings such as the database connection string. Inside the Controllers folder, add the following controller:

using CampusHub.Application.DTOs;
using CampusHub.Application.Interfaces;
using Microsoft.AspNetCore.Mvc;

namespace CampusHub.Api.Controllers;

[ApiController]
[Route("api/[controller]")]
public class CoursesController : ControllerBase
{
    private readonly ICourseService _service;

    public CoursesController(ICourseService service)
    {
        _service = service;
    }

    [HttpPost]
    public async Task<IActionResult> Create(CreateCourseDto dto)
    {
        var id = await _service.CreateAsync(dto);

        return CreatedAtAction(nameof(GetById), new { id }, null);
    }

    [HttpGet("{id:guid}")]
    public async Task<IActionResult> GetById(Guid id)
    {
        var course = await _service.GetByIdAsync(id);

        if (course is null)
            return NotFound();

        return Ok(course);
    }

    [HttpGet]
    public async Task<IActionResult> GetAll()
    {
        var courses = await _service.GetAllAsync();

        return Ok(courses);
    }

    [HttpPut("{id:guid}")]
    public async Task<IActionResult> Update(Guid id, UpdateCourseDto dto)
    {
        await _service.UpdateAsync(id, dto);

        return NoContent();
    }

    [HttpPost("{id:guid}/activate")]
    public async Task<IActionResult> Activate(Guid id)
    {
        await _service.ActivateAsync(id);

        return NoContent();
    }

    [HttpPost("{id:guid}/archive")]
    public async Task<IActionResult> Archive(Guid id)
    {
        await _service.ArchiveAsync(id);

        return NoContent();
    }
}