LangGraph is a framework for building AI agents and workflows as stateful graphs. Each step in the workflow is represented as a node. Edges define how execution flows between nodes, and state acts as shared memory throughout the graph.

Built on top of LangChain, LangGraph provides explicit and debuggable control over multi-step LLM applications such as chatbots, tool-calling agents and automated pipelines.

In this article, we will use TypeScript to build a simple LangGraph application from scratch and explore the core concepts, APIs and execution model that form the foundation of more advanced agentic workflows.

LangGraph has three building blocks.

1. State
2. Node
3. Edges

State represents data that is shared by every node. A node represents a function that takes a state as input and returns an updated value for the state. Edges are control flow, which can be serial, parallel or conditional.

To understand how graphs work, we’ll start with a simple counter application that does not require a model. This example will introduce the core concepts of state and node, and by the end of the section, you’ll understand how they form the foundation of a graph.

At the end of the article, we will create a FIFA chatbot using an OpenAI model and LangGraph using nodes, states and edges.

What Is a State?

In LangGraph, a state is a data structure that serves as a shared memory layer that connects the graphs. Nodes consume state, produce incremental updates and rely on it for conditional routing.

Every node in the graph depends on the state. Nodes read data from the state and write partial updates back to it. And conditional edges use the state to determine the next path in the workflow.

StateSchema is the contract that defines the structure and behavior of a state in LangGraph. More than just a TypeScript type, it serves as a runtime specification that determines:

• Which fields exist in the state
• Their types and default values (defined with Zod)
• How updates are merged (reducers vs. last-write-wins)
• Which data nodes can read from and write to

You can create a state using the StateSchema as shown below:

counter-state.schema.ts

import { ReducedValue, StateSchema } from "@langchain/langgraph";
import { z } from "zod";

export const CounterStateSchema = new StateSchema({
  count: new ReducedValue(z.number().default(0), {
    inputSchema: z.number(),
    reducer: (current, next) => current + next,
  }),
});

Every key in a StateSchema can be one of the following:

1. Zod Field – A standard state field defined with Zod. Updates follow a last-write-wins strategy, meaning the most recent value replaces the previous one.
2. ReducedValue – A field that updates by combining the new value with the existing value instead of replacing it. In the example above, count is a ReducedValue, so each update is merged with the current count rather than overwriting it.
3. MessageValue – A specialized form of ReducedValue designed for chat applications. Instead of replacing existing messages, new messages are automatically appended to the conversation history.

Once state is defined using the StateSchema, you can work with the three derived types:

1. State – Full object during the execution
2. Update – Partial object a node may return
3. Node – Function signature

counter-state.types.ts

export type CounterState = typeof CounterStateSchema.State;
export type CounterUpdate = typeof CounterStateSchema.Update;
export type CounterNode = typeof CounterStateSchema.Node;

For this example, we will mostly work with the CounterNode. Also, the CounterStateSchema has:

1. Initial value set to 0
2. Each nodes return the updated value
3. Reducer adds current value to the previous value

What Is a Reducer?

Before we move further, let’s discuss the reducer function. It is a simple function that decides how a state field changes when a node returns an update. Multiple nodes can update the same field during a graph execution. Instead of overwriting the existing value, the reducer merges each partial update into the current state.

As nodes returns partial updates, LangGraph would need a rule for conflicting updates. That merge rule is written inside the the reducer function.

reducer: (current, next) => current + next,

The signature of the reducer:

• current – value in state before this update
• next – what the node returned for this field
• return value – new stored value

Use a reducer only when values need to be combined or accumulated. If each update should simply replace the previous value, a standard field is all you need. As shown in below state schema, each time state will be updated with the last returned value from the node.

lastcount-state.schema.ts

export const LastCountStateSchema = new StateSchema({
  count: z.number().default(0),
});

For LastCountState, derived states can be exported as shown below:

lastcount-state.types.ts

export type LastCountState = typeof LastCountStateSchema.State;
export type LastCountUpdate = typeof LastCountStateSchema.Update;
export type LastCountNode = typeof LastCountStateSchema.Node;

So far, we have defined two state schemas and exported their corresponding TypeScript types. The CounterState uses a reducer to accumulate new values with the existing value, while the LastCountState follows a last-write-wins approach and always stores the most recent value. Next, let’s create the nodes that will operate on these states.

Creating Nodes

In LangGraph, a node is the fundamental building block of a graph. It is usually implemented as a function that takes the current state as input, performs some computation or action, and returns a partial update to the state.

Depending on how the state schema is defined, LangGraph either merges the returned update into the existing state using the configured reducer or replaces the current value with the latest one before passing the updated state to the next step in the workflow.

You can create nodes to increment a counter state by 1 and 2 like below:

counter.node.ts

export const incrementNode: CounterNode = () => ({
  count: 1,
});

export const incrementTwiceNode: CounterNode = () => ({
  count: 2,
});

After each node runs, LangGraph:

• Receives the partial state update returned by the node
• Merges the update into the current state using the rules defined in the StateSchema
• Passes the resulting state to the next node, or terminates the graph if execution is complete

For LastCountState, a node can be created as shown below:

export const setOneNode: LastCountNode = () => ({
  count: 1,
});

export const setFiveNode: LastCountNode = () => ({
  count: 5,
});

export const setNineNode: LastCountNode = () => ({
  count: 9,
});

Because LastCountState stores only the latest value, every node overwrites the previous value, and the next node receives the most recent state update.

As we discussed earlier, a node only returns a partial state update. How that update is applied to the state is determined by the StateSchema through its merge strategy (reducers or last-write-wins), not by the node’s implementation.

Also, nodes do not decide where execution goes next; edges do. Nodes only read state and write updates.

There are four types of nodes:

1. Synchronous node – Returns an object immediately
2. Asynchronous node – Returns a promise
3. Stateless node – Ignores the state value and always returns the same value
4. Stateful node – Reads the fields from the state and computes the new value from them

All the nodes we have created so far for both CounterState and LastCountState are synchronous and stateless.

We can create a stateful node on CounterState as shown below:

export const doubleCountNode: CounterNode = (state) => ({
  count: state.count,
});

We have created nodes; now see how they are connected using edges.

Creating an Edge

An edge connects two nodes and determines the control flow by specifying which node executes after the current node completes.

An edge can be of two types:

1. Fixed edge – Always goes to the same next node
2. Conditional edge – Next node depends on state or routing function

To work with nodes and edges, LangGraph provides two special nodes:

1. START – Entry node, and it contains no custom code
2. END – Exit node, and it also contains no custom code

Building the Graph

The LangGraph graph is where you assemble everything. A graph brings together the state schema, nodes and edges into an executable workflow. You create and run a graph following the steps:

• Create a StateGraph using your state schema.
• Add nodes with addNode() to define the tasks in the workflow.
• Connect nodes with addEdge() to specify the execution order.
• Compile the graph using compile() to generate a runnable workflow.
• Invoke the graph with invoke(), which starts execution at START.
• Execute nodes in the order defined by the graph’s edges.
• Apply reducers after each node runs to update the shared state.
• Continue execution until the graph reaches the END node.
• Return the final state as the workflow’s output.

Think of the graph as the orchestrator, the nodes as workers performing tasks, and the state as the shared memory that connects them.

There are three steps to build the graph:

1. Create a StateGraph with your schema
2. Register nodes and edges
3. Call .compile() to get a runnable graph

We can create a graph for CounterState as shown below:

counter.graph.ts

export function buildCounterGraph() {
  return new StateGraph(CounterStateSchema)
    .addNode("increment", incrementNode)
    .addNode("incrementTwice", incrementTwiceNode)
    .addNode("doubleCount", doubleCountNode)
    .addEdge(START, "increment")
    .addEdge("increment", "incrementTwice")
    .addEdge("incrementTwice", "doubleCount")
    .addEdge("doubleCount", END)
    .compile();
}

As you can see:

• addNode() adds a node to the graph. Each node is a step.
• addEdge() is used to add an edge to the graph. Edges know the step by the string name, not the node function name.
• new StateGraph() creates a graph bound to the state schema definition.
• .compile() validates the graph. It checks for:
         a. Is there any path from START to END
         b. Do node name edge exist
         c. Is the schema wired correctly
         d. Then returns a compiled graph

In the same way, you can create a graph for LastCountState:

lastcount.graph.ts

export function buildLastCountGraph() {
  return new StateGraph(LastCountStateSchema)
    .addNode("setOne", setOneNode)
    .addNode("setFive", setFiveNode)
    .addNode("setNine", setNineNode)
    .addEdge(START, "setOne")
    .addEdge("setOne", "setFive")
    .addEdge("setFive", "setNine")
    .addEdge("setNine", END)
    .compile();
}

We use addEdge() to connect nodes and define the execution flow within the graph. Key characteristics of addEdge() are:

• The addEdge(startKey, endKey) creates an unconditional edge.
• Once the startKey node completes, execution always proceeds to the endKey node.
• Possible values of startKey are START or node name or node name [].
• Possible values of endKey are END or node name.

In the count graph, we start at the increment node and create a linear chain to the doubleCount node.

    .addEdge(START, "increment")
    .addEdge("increment", "incrementTwice")
    .addEdge("incrementTwice", "doubleCount")
    .addEdge("doubleCount", END)

This is a linear chain.

Graph Rules to Remember

When building a LangGraph workflow, keep the following rules in mind:

1. Node names must be valid.
   Every node referenced in an edge must either be a registered node name or one of the special nodes: START or END.


2. Use the graph node name, not the function name.
   When creating edges, refer to the string name assigned in addNode(), not the underlying function name.


3. A graph must have a starting path.
   Every runnable graph must contain at least one edge originating from START.


4. A graph must have a termination path.
   Every runnable graph must contain at least one edge leading to END.


5. Unreachable nodes are dead code.
   If a node cannot be reached from START, it will never execute and is effectively dead code within the graph.


6. addEdge() creates unconditional transitions.
   addEdge() does not evaluate the graph state or any conditions. Execution always follows the defined path. If you need conditional routing (for example, “if count > 5 go here, otherwise go there”), use addConditionalEdges(). We’ll explore conditional routing in the next article.

Invoking the Graph

We can invoke the graph using the invoke() method.

const graph = buildCounterGraph();
const result = await graph.invoke({});
console.log(result);

The invoke method returns the final state, and you should see output {count: 6}. There is another method, stream(), to read the state after each node’s execution, and we will cover it in the next article.

In the same way, you can invoke LastCountGraph as shown below:

const graph1 = buildLastCountGraph();
const result1 = await graph1.invoke({});
console.log(result1);

You should get the result {count: 9}.

In this way, you can create a basic LangGraph graph using state, state schema, edges and nodes.

The following diagram brings together all the concepts we have learned so far and illustrates the main building blocks of a LangGraph.

FIFA Chat Example

Now that we’ve covered the core LangGraph concepts, let’s put them into practice by building a chat application that answers questions about the FIFA World Cup.

Let us start by defining the state with MessageValue.

const schema = new StateSchema({ messages: MessagesValue });

Next, create the language model for our FIFA World Cup chatbot using OpenAI’s GPT. Before initializing the model, add your OpenAI API key to the .env file.

const model = new ChatOpenAI({ model: "gpt-4o-mini", temperature: 0 });

Next, set the system prompt such that the model only answers about FIFA and does not answer on other topics.

const SYSTEM = `You are a FIFA World Cup expert. ONLY answer questions about the FIFA World Cup (1930–present): winners, hosts, matches, records, players in World Cup context.
For anything else, reply exactly: "I can only help with FIFA World Cup questions."`;

Next, create the node that acts as an agent. It will read messages, call the models and return the model’s new reply. The MessageValue reducer will append the message to the message history.

const agent: typeof schema.Node = async (state) => ({
  messages: [await model.invoke(state.messages)],
});

Next, let’s build the graph. In this example, the graph consists of a single node with an incoming START edge and an outgoing END edge.

const graph = new StateGraph(schema)
  .addNode("agent", agent)
  .addEdge(START, "agent")
  .addEdge("agent", END)
  .compile();

Then, we seed the state with the SystemMessage:

let state: typeof schema.State = { messages: [new SystemMessage(SYSTEM)] };

Finally, inside the loop, we invoke the graph as below:

  state = await graph.invoke({
    ...state,
    messages: [...state.messages, new HumanMessage(question)],
  });

Here we are using schema.state, which is the full state graph read and write. Putting everything together, FIFA Chat Bot should look like below:

import { stdin as input, stdout as output } from "node:process";
import * as readline from "node:readline/promises";

import { HumanMessage, SystemMessage } from "@langchain/core/messages";
import { ChatOpenAI } from "@langchain/openai";
import { END, MessagesValue, START, StateGraph, StateSchema } from "@langchain/langgraph";
import "dotenv/config";

const schema = new StateSchema({ messages: MessagesValue });

const model = new ChatOpenAI({ model: "gpt-4o-mini", temperature: 0 });

const SYSTEM = `You are a FIFA World Cup expert. ONLY answer questions about the FIFA World Cup (1930–present): winners, hosts, matches, records, players in World Cup context.
For anything else, reply exactly: "I can only help with FIFA World Cup questions."`;

  const agent: typeof schema.Node = async (state) => ({
    messages: [await model.invoke(state.messages)],
  });

const graph = new StateGraph(schema)
  .addNode("agent", agent)
  .addEdge(START, "agent")
  .addEdge("agent", END)
  .compile();

let state: typeof schema.State = { messages: [new SystemMessage(SYSTEM)] };

const rl = readline.createInterface({ input, output });

console.log("⚽ FIFA World Cup Chat — type 'exit' to quit\n");

while (true) {
  const question = (await rl.question("You: ")).trim();
  if (!question) continue;
  if (question === "exit" || question === "quit") break;

  state = await graph.invoke({
    ...state,
    messages: [...state.messages, new HumanMessage(question)],
  });

  console.log(`\nAssistant: ${state.messages.at(-1)?.content}\n`);
}

rl.close();

You have created a FIFA chatbot using Graph, which uses nodes, state and edges. In further articles, we go deeper into creating agents using LangGraph. I hope you find this article useful. Thanks for reading.

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();
    }
}

Then, in the Program class, replace the existing code with the code below:

using CampusHub.Application.Services;
using CampusHub.Application.Interfaces;
using CampusHub.Infrastructure;

var builder = WebApplication.CreateBuilder(args);

// Services

builder.Services.AddControllers();

builder.Services.AddEndpointsApiExplorer();

// Application

builder.Services.AddScoped<ICourseService, CourseService>();

// Infrastructure

builder.Services.AddInfrastructure(builder.Configuration);

// Build

var app = builder.Build();

// Middleware

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

Finally, in the file appsettings.json, add the following configuration. (Don’t forget to add your credentials!):

 "ConnectionStrings": {
    "DefaultConnection": "server=localhost;port=3306;database=campushub;user=YOUR_USER;password=YOUR_PASSWORD;"
  }
,

Running EF Core Commands

To apply the migration commands, in the project root, open a new terminal and run the commands below.

Creating the Migration Files

dotnet ef migrations add InitialCreate --project src/CampusHub.Infrastructure --startup-project src/CampusHub.Api --output-dir Data/Migrations

Applying the Migration Commands

dotnet ef database update --project src/CampusHub.Infrastructure --startup-project src/CampusHub.Api

What Does the Final Structure Look Like?

After implementing all the steps above, the project will have the following structure:

When Does a Complete CRUD Not Pay Off?

In this post, we created a complete CRUD, with all the necessary elements for its evolution. However, this complexity can exponentially increase development time and the level of knowledge required to maintain the project.

With this in mind, in some scenarios, simplicity is preferable. For example, when the system basically stores and retrieves data without relevant business rules. In scenarios such as basic registrations, auxiliary tables or internal administrative panels, adding layers such as services, rich entities and DDD patterns tends to generate more complexity than value, making the code more difficult to maintain without a justified need.

It is also not worthwhile to invest in a sophisticated architecture in the initial phases of a product, such as MVPs or systems still in validation. In these cases, the priority is speed and adaptation to frequent changes, and a simple structure allows for faster evolution without the burden of unnecessary abstractions.

On the other hand, a more elaborate CRUD makes sense when the domain has important rules, states, complex validations or when errors can have a significant impact. In these scenarios, a more structured architecture, as demonstrated in the post, helps protect the domain, maintain consistency and facilitate the system’s evolution over time (all parts are in their proper places).

The final decision of whether or not to use a complete and evolve-ready CRUD should therefore always take into account the level of complexity of the problem.

Conclusion and Next Steps

Knowing the best approach when creating new web applications is always a challenge, but we must keep in mind that if the project requires complex business rules, validations and errors that can have a significant impact, this is a strong indication that the application should not be a simple and generic CRUD.

In this post, we learned how to create a complete CRUD, with each layer representing a part of Clean Architecture, and using DDD development principles to implement a well-structured domain with private properties and behaviors.

But far beyond the basic structure presented in this post, a complete CRUD also involves unit tests, complex validations (FluentValidation), authentication and authorization with modern methods (JW Tokens for example), and many other elements. I hope this post serves as a starting point and helps you create CRUD applications that are not only ready to function, but also to evolve with quality over time.

Hierarchical data is everywhere. Product catalogs, organizational structures, file systems, geographical regions and permission models all rely on parent-child relationships to help users understand and navigate information.

The challenge appears when users need to select something from that hierarchy.

A traditional dropdown works well for flat lists, but once the number of items grows, users lose important context. A product category called “Gaming Laptops” means much more when users can see that it belongs under “Electronics → Computers → Laptops.”

A TreeView solves the navigation problem, but it is not always the right fit inside a form. Keeping a large hierarchy permanently visible can consume valuable screen space.

This is where the Progress Telerik UI for Blazor DropDownTree comes in.

The DropDownTree combines the compact experience of a dropdown with the navigation capabilities of a TreeView, allowing users to browse, search and select hierarchical data without overwhelming the UI.

In this article, we will explore how to use the DropDownTree to:

• Display hierarchical data
• Help users quickly find items
• Make working with hierarchical data more intuitive
• Customize the appearance of nodes
• Customize the selected value display

Why Choose a DropDownTree?

When working with hierarchical data, choosing the right component can make a significant difference in the user experience.

A standard dropdown or ComboBox is ideal for flat data, but it does not provide context about how items relate to each other. A TreeView preserves the hierarchy, but it is always visible and may not fit well inside forms where space is limited.

The DropDownTree combines the best of both approaches.

If your users need to select something from a hierarchy but don’t need the hierarchy visible all the time, the DropDownTree is often the right choice.

How Can You Display Hierarchical Data?

Let’s start with a common scenario: a product catalog.

Imagine an inventory application with categories like:

Electronics
  Computers
    Laptops
      Gaming
      Business
    Phones
Furniture
  Bedroom
  Living Room

Displaying this structure in a flat dropdown would quickly become difficult to use. The DropDownTree allows you to bind directly to hierarchical data, including data that comes from a database through a service.

The Data Model

The component works with a recursive DTO where each node holds its own children:

public class HierarchicalTreeItemDto
{
    public int TreeItemId { get; set; }
    public string Text { get; set; }
    public bool HasChildren => Items?.Count > 0;
    public List<HierarchicalTreeItemDto> Items { get; set; } = new();
}

HasChildren is computed from Items.Count, so it never goes out of sync with the actual data.

The Component and Binding

@inject HierarchicalTreeItemService HierarchicalTreeItemService

<TelerikDropDownTree Data="@DropDownTreeData"
                     @bind-Value="@DropDownTreeValue"
                     @bind-ExpandedItems="@DropDownTreeExpandedItems"
                     ValueField="TreeItemId"
                     Filterable="true"
                     FilterOperator="@StringFilterOperator.Contains"
                     FilterPlaceholder="Search by name">

    <DropDownTreeBindings>
        <DropDownTreeBinding TextField="Text" ItemsField="Items" />
    </DropDownTreeBindings>

</TelerikDropDownTree>

@code {
    private List<HierarchicalTreeItemDto> DropDownTreeData { get; set; }
    private int DropDownTreeValue { get; set; }
    private IEnumerable<object> DropDownTreeExpandedItems { get; set; } = new List<object>();

    protected override void OnInitialized()
    {
        DropDownTreeData = HierarchicalTreeItemService.GetHierarchicalTreeItems().ToList();
        DropDownTreeExpandedItems = DropDownTreeData.Where(x => x.HasChildren).ToList<object>();
    }
}

• Data – The root-level collection. The component recursively reads ItemsField to build the full tree; it never calls the service itself.
• @bind-Value – Two-way binding for the selected node’s key. Updates DropDownTreeValue with the chosen TreeItemId.
• @bind-ExpandedItems – Controls which nodes are open. Prepopulating it with the root nodes that have children means users see the top-level structure the moment they open the dropdown.
• DropDownTreeBinding – Tells the component which property is the display label (TextField) and which holds the children (ItemsField). These match the DTO property names exactly.

GetHierarchicalTreeItems() is where your data-access logic lives. It queries the database and maps the results into the HierarchicalTreeItemDto hierarchy. The component receives a ready-made tree; it has no knowledge of where the data came from.

An exemplary Product category hierarchy displayed inside the DropDownTree:

Tip: If your application already uses hierarchical DTOs, you can often bind them directly without flattening or restructuring your data.

How Can Users Find Items Faster?

Large hierarchies can quickly become difficult to navigate manually. Imagine a catalog containing thousands of products organized across multiple category levels.

Instead of expanding nodes one by one, users can search directly. Filtering is enabled with a single parameter:

<TelerikDropDownTree Data="@CatalogData"
                     @bind-Value="@SelectedValue"
                     @bind-ExpandedItems="@ExpandedItems"
                     ValueField="@nameof(CategoryItem.Id)"
                     Filterable="true"
                     FilterOperator="@StringFilterOperator.Contains"
                     FilterPlaceholder="Search by name…">
    <DropDownTreeBindings>
        <DropDownTreeBinding TextField="@nameof(CategoryItem.Name)"
                             ItemsField="@nameof(CategoryItem.Children)" />
    </DropDownTreeBindings>
</TelerikDropDownTree>

Setting Filterable="true" adds a search box at the top of the popup. FilterOperator controls the matching strategy. Contains is the most user-friendly choice. FilterPlaceholder sets the hint text inside the search field.

Now users can quickly locate deeply nested items. For example, searching for a specific laptop brand, e.g., “Asus,” can immediately reveal:

 Electronics
  Computers
   Laptops
    Gaming
     Asus ROG Strix G16

How Can You Make Navigation More Intuitive?

Sometimes the best experience is to show users the available structure immediately. Displaying top-level product categories expanded when the popup opens makes it easier to understand what options are available.

The DropDownTree lets you control which nodes are expanded through @bind-ExpandedItems. You can initialize the expanded set programmatically in OnInitialized:

protected override void OnInitialized()
{
    // Expand all root-level categories on load
    ExpandedItems = CatalogData
        .Where(item => item.Children?.Count > 0)
        .Cast<object>()
        .ToList();
}

You can also include buttons that let users expand or collapse all nodes at once:

<TelerikButton OnClick="@ExpandRoots" ThemeColor="@ThemeConstants.Button.ThemeColor.Primary">
    Expand Root Categories
</TelerikButton>
<TelerikButton OnClick="@CollapseAll">
    Collapse All
</TelerikButton>
private void ExpandRoots()
{
    ExpandedItems = CatalogData
        .Where(item => item.Children?.Count > 0)
        .Cast<object>()
        .ToList();
}

private void CollapseAll()
{
    ExpandedItems = new List<object>();
}

This gives users immediate context while keeping the dropdown compact.

All nodes collapsed vs. expanded root nodes:

How Can You Make Hierarchies Easier to Scan?

Hierarchical data often contains different types of items. A department may contain employees. A folder may contain documents. A product category may contain products.

Displaying everything as plain text makes the hierarchy harder to understand.

The DropDownTree supports ItemTemplate inside DropDownTreeBinding, allowing you to fully customize how each node renders. The template receives the data item as context.

Start with an enriched data model that carries everything the template needs:

public class OrgNode
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Role { get; set; } = string.Empty;
    public EmployeeStatus Status { get; set; } = EmployeeStatus.Available;
    public ISvgIcon? Icon { get; set; }
    public List<OrgNode>? Children { get; set; }
}

public enum EmployeeStatus { Available, Busy, Away }

Each department gets a contextual icon—a gear for Engineering, a dollar sign for Finance and so on. Each employee carries a job title and an availability status.

Wire up the template:

<TelerikDropDownTree Data="@OrgData"
                     @bind-Value="@SelectedValue"
                     @bind-ExpandedItems="@ExpandedItems"
                     ValueField="@nameof(OrgNode.Id)"
                     Width="340px">

    <DropDownTreeBindings>
        <DropDownTreeBinding TextField="@nameof(OrgNode.Name)"
                             ItemsField="@nameof(OrgNode.Children)">
            <ItemTemplate>
                @{
                    var node = (OrgNode)context;
                    var isLeaf = !(node.Children?.Count > 0);
                }
                @if (!isLeaf)
                {
                    <!-- Department node: contextual icon + name -->
                    <TelerikSvgIcon Icon="@node.Icon" />
                    <span>&nbsp;@node.Name</span>
                }
                else
                {
                    <!-- Employee node: status dot + person icon + name and role -->
                    <span class="node-status node-status--@node.Status.ToString().ToLower()"></span>
                    <TelerikSvgIcon Icon="@SvgIcon.User" />
                    <span class="node-employee">
                        <span class="node-employee-name">@node.Name</span>
                        <span class="node-employee-role">@node.Role</span>
                    </span>
                }
            </ItemTemplate>
        </DropDownTreeBinding>
    </DropDownTreeBindings>

</TelerikDropDownTree>

A few CSS rules complete the effect:

.node-status {
    display: inline-block;
    width: 8px;
    height: 8px;
    border-radius: 50%;
    margin-right: 5px;
}

.node-status--available { background: #4caf50; }
.node-status--busy      { background: #ff9800; }
.node-status--away      { background: #9e9e9e; }

.node-employee {
    display: inline-flex;
    flex-direction: column;
    line-height: 1.2;
    vertical-align: middle;
}

.node-employee-name { font-size: 0.875rem; }
.node-employee-role { font-size: 0.75rem; color: #6c757d; }

The result: department nodes render with their domain icon, while employees show a colored availability dot, their name and their role—all inside the same compact dropdown:

How Can You Customize the Selected Value Display?

By default the DropDownTree shows the selected item’s text in the input. With ValueTemplate you can replace that with any markup you like.

A useful pattern is showing the selected item together with its breadcrumb path, giving users instant context about where the selection sits in the hierarchy:

<TelerikDropDownTree Data="@CatalogData"
                     @bind-Value="@SelectedValue"
                     @bind-ExpandedItems="@ExpandedItems"
                     ValueField="@nameof(CategoryItem.Id)"
                     Width="380px">

    <DropDownTreeBindings>
        <DropDownTreeBinding TextField="@nameof(CategoryItem.Name)"
                             ItemsField="@nameof(CategoryItem.Children)" />
    </DropDownTreeBindings>

    <ValueTemplate>
        @{
            // context is the selected data item
            var item = context as CategoryItem;
            var breadcrumb = item != null ? GetBreadcrumb(item.Id) : string.Empty;
            var isCategory = item?.Children?.Count > 0;
        }
        <span title="@breadcrumb">
            <TelerikSvgIcon Icon="@(isCategory ? SvgIcon.Folder : SvgIcon.Star)" />
            &nbsp;<strong>@item?.Name</strong>
            @if (!string.IsNullOrEmpty(breadcrumb))
            {
                <span style="font-size:0.85em; color:#6c757d;">
                    &nbsp;— @breadcrumb
                </span>
            }
        </span>
    </ValueTemplate>

</TelerikDropDownTree>

The GetBreadcrumb helper walks the tree and builds the ancestor path:

private string GetBreadcrumb(int id)
{
    var path = new List<string>();
    BuildPath(CatalogData, id, path);
    if (path.Count > 1) path.RemoveAt(path.Count - 1); // remove leaf, keep ancestors
    return string.Join(" › ", path);
}

private bool BuildPath(List<CategoryItem> nodes, int id, List<string> path)
{
    foreach (var node in nodes)
    {
        path.Add(node.Name);
        if (node.Id == id) return true;
        if (node.Children != null && BuildPath(node.Children, id, path)) return true;
        path.RemoveAt(path.Count - 1);
    }
    return false;
}

Selecting “Gaming” now shows Gaming — Electronics › Computers › Laptops in the input, making the choice self-explanatory without any extra UI:

When Should You Use a DropDownTree?

The DropDownTree is useful whenever users need to select items from nested data.

Common scenarios include:

• Product catalogs – Browse categories and subcategories while preserving their relationships.
• Organization structures – Select employees, teams or departments.
• Document management – Choose folders and files from nested structures.
• Geographic selection – Navigate countries, regions, cities and locations.
• Permission management – Assign roles or resources organized into security hierarchies.
• Content management – Select pages, sections or navigation items.

Whenever hierarchy provides useful context, the DropDownTree helps users make better selections.

Try the Telerik UI for Blazor DropDownTree Today

The DropDownTree brings a long-requested hierarchical selection experience to Telerik UI for Blazor applications.

With built-in filtering, flexible data binding, templates, adaptive rendering, and accessibility support, it provides everything needed to create intuitive hierarchical selection workflows.

Explore these resources to learn more:

• REPL Examples – Experiment with the code directly in your browser
• Live Demos – See the component in action
• Documentation – Explore configuration options and API

Whether you are building an inventory system, HR portal, document manager or administrative application, the Telerik UI for Blazor DropDownTree can help users find and select hierarchical data quickly and naturally.

Try Now

Throughout this TanStack Query series (including the posts on data fetching, mutations, optimistic updates and pagination), we’ve been writing query keys as plain inline arrays: ['users'], ['user', userId], ['posts']. That works perfectly fine when you have three or four queries in a small app. It starts to fall apart somewhere between 50 and 100 queries, which is a number you reach faster than you’d think.

Today I want to walk through what I’ve found to be the cleanest way to manage query keys at scale, the patterns I reach for, and why I think this is one of the most underrated parts of using TanStack Query well.

Why Query Keys Matter More Than You Think

Let’s start with the why. A query key is the unique address of a piece of cached data, and it’s also the handle you use for everything you do to that piece of data: refetching, invalidating, prefetching, reading directly from the cache.

When your keys are scattered around as inline arrays, a few things tend to happen:

• You misspell a key in an invalidateQueries call and silently nothing happens. The list doesn’t refresh, you don’t see an error, you just see stale data.
• You change the shape of a key (say, from ['user', id] to ['users', 'detail', id]) and now have to track down every single place that referenced the old shape.
• You can’t tell at a glance which queries are related to which entity, so invalidation strategies become guesswork.
• New developers on the team have no central place to look up: “how do we cache users in this app?”