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

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

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

Now, at this point we’re clear on scope and UI/UX, and we have a first thin slice (tracer bullet) to build.

But this first feature is where all those little niggly decisions show up. We’re using Blazor, but which version, render mode, CSS framework?

First we need to get clear on those:

We want to build 0001-open-existing-astro-draft-and-save-edits.md. Let’s start by planning this - grill me on every key technical choice needed to get this built, include your recommended answer for each question, ask me one thing at a time until you have enough to proceed with the build of this tracer bullet.

Time for some more back and forth with the GPT 5.5.

Including some key decisions around making sure we don’t lose changes:

Notice how we’re now firmly into implementation details.

Every step before this was about the requirement, the overall business goal we’re reaching for, the headline feature(s) that help us meet those goals. Now we’re getting into the core details about how we implement this (where do we store data, what do we store, how do we handle concurrency).

Again, this is not a linear process. Technical limitations here could mean the original feature is compromised and needs to be rethought.

Ultimately you—the human developer—are the key to unlocking this feature. When you decide you’ve got enough detail, the problem scope is clear and the key implementation decisions have been made, you can instruct AI to start building.

Smaller Slices

AI works best when you give it less to think about in one go. In this case, our tracer bullet is arguably quite large still (there are a few moving parts and it arguably does more than one thing).

This is entirely subjective, but I decided to have it break the work down into slightly smaller steps.

I want to create tasks for this, rather than just go ahead. Given the context of the tracer bullet, and the technical decisions, let’s create one or more tasks. Propose how we can slice this work up, then get my approval before writing the individual tasks. They key is to keep each individual task so it delivers a vertical slice through the app, and value that could be shipped.

Ensure we use the visual prototype we created, and match that for this implementation

This resulted in a few separate tasks:

• 0002 Boot Local Blazor Workspace With Validated Config
• 0003 Discover And Open Existing Astro Draft
• 0004 Save Draft Body Back To Astro File
• 0005 Restore Last Active Draft
• 0006 Protect Against External File Changes

Here’s part of 002:

# Task 0002: Boot Local Blazor Workspace With Validated Config

## Goal

Create the first runnable Article Workspace app shell as a .NET 10 Blazor Web App and validate that it can be configured to point at the Astro repository.

This is the first vertical slice of [Task 0001](0001-open-existing-astro-draft-and-save-edits.md). It should not read or edit article files yet; it should prove the app can launch and clearly report whether the local workspace is configured.

## User Story

As the writer, I want to open Article Workspace and know whether it is connected to my Astro repository, so I can fix setup problems before the app reads or writes content.

## Technical Decisions
...

## Scope
...

## Visual Reference
Use `prototypes/article-workspace/index.html` as the visual reference for layout, spacing, typography, colors, and overall product feel.

This slice should adapt the prototype to a narrow setup/connected-workspace screen. It should not look like the default Blazor template.

## Acceptance Criteria
...

## Non-Goals
...

## Implementation Notes
...

You Can Still Do Things Manually

This may come as a surprise, but sometimes it’s still better to do things yourself!

Every time I create a new Blazor project with AI, it seems to overreach and/or get itself into a muddle trying to set the project up, configure Tailwind CSS, etc.

So I opted to spin up the new project myself and check it all worked first. Then I added my Tailwind NuGet package, which I tend to use for integrating Tailwind with Blazor.

I did get AI to help with parts of this (like then migrating from Bootstrap to Tailwind), but it’s worth noting that sometimes it’s still quicker to do things yourself (rather than burn AI tokens looping around to get their in eight steps when you can do it in one or two).

With the new project set up, AI was able to work through the first task (now confusingly numbered 0002).

let’s implement the next available task

With this, we ended up with a simple screen that showed the app was configured (if we remove the config, it shows a warning and instructions to configure the paths to Astro, etc.).

Now at this point, I was tempted to just open up a new session (important, for keeping that context down) and tell it to start Task 2. But there’s an issue with that approach.

Keep Tabs on Your Progress

If I just say “implement the next feature,” the LLM has to trawl through the code and the tasks list (which it won’t know about, so has to look for), see what’s already been built and figure out which task to handle next.

This is an expensive way to figure something out that we already know. We already know we just did feature 0002 and just need to tell the LLM where we got to and how to take the next step.

Knowing we’re going to be doing this a lot, I asked the LLM to create a skill for implementing tasks that also keeps a lightweight progress log that new LLM chats can reference when they come to pick up new tasks.

let’s create a skill to implement each task. It should ensure we write a simple progress log so the next session knows (roughly) what’s been done, and potential next tasks to pick up. So the flow will be to check progress, identify next task to work on, then set to work on that task until its acceptance criteria are met

This resulted in a task-runner Codex skill.

With that in place, I opened up a new chat and asked it to implement the next feature.

I’ll use the task-runner skill to find the local backlog, identify the next pending task, and carry it through implementation and verification.

I found a Blazor solution with a numbered task backlog and an existing progress log. I’m reading the task state and the next task’s criteria before touching code.

Task 0003 is next. Its slice is read-only: scan configured Astro content, parse draft frontmatter, list drafts, and load the selected body without modifying source files.

The existing UI is still the setup screen from 0002, and the code has no draft discovery layer yet. I’m going to add a small read-only workspace service, then adapt the home page into the prototype-style sidebar plus editor once config is valid.

From here, I kept going, starting new chats for each task, and Codex kept using the new skill to execute that task (and update the progress log).

Here’s part of the running progress log.

# Progress

## Status

| Task | State | Notes |
| --- | --- | --- |
| 0001 | Done | Umbrella tracer bullet is covered by tasks 0002 through 0006: configure, discover, edit, preview, save, restore last active draft, startup reload, and stale-save protection. |
| 0002 | Done | Local Blazor setup screen validates Astro repository config and shows connected/blocking states. |
| 0003 | Done | Discovers configured Astro draft files and opens the selected body read-only. |
| 0004 | Done | Saves the selected draft body back to disk, tracks dirty state, supports save shortcut, and renders sanitized Markdown preview. |
| 0005 | Done | Persists the last selected draft in Astro repo metadata and restores it on startup with fallback handling. |
| 0006 | Done | Blocks stale saves when the selected draft changed on disk and exposes reload before saving. |

## Task Session Convention

- Before working on a task, check whether the app is already listening on `http://localhost:5012/`.
- If it is not running, start it from `src/DevWriter/DevWriter` with `dotnet watch run --urls http://localhost:5012`.
- Keep a single app instance running during task work; if another process is already listening on `5012`, reuse it rather than starting a second instance.
- If the watched app crashes during a task, restart the same `dotnet watch` command and continue verification in the browser.

## Latest Session

- Date: 2026-05-07
- Task: 0001 - Open Existing Astro Draft And Save Edits
- Result: Done
- Changed:
  - Marked the umbrella tracer bullet complete after checking its acceptance criteria against completed slices 0002 through 0006.
- Verified:
  - Reviewed `tasks/0001-open-existing-astro-draft-and-save-edits.md` against the implemented code paths and previous verification from tasks 0002 through 0006.
  - Confirmed the app has no commit, push, publish, or newsletter code paths in the tracer bullet implementation.
- Notes:
  - `0001` is an umbrella task; no code changes were needed for this check.
  - Remaining work should be captured as new backlog slices rather than keeping `0001` open.

Did AI Get Everything Right? Not Exactly

LLMs rarely get everything “right.”

For most of the work, it did a good job. But occasionally the UI was a bit “off” (part of the screen overlapping another part, superfluous elements that didn’t really do anything).

Overall, it created a functional (and visually faithful to the prototype) app that satisfied everything we’d agreed for the initial feature.

There was just one step left to do. GPT had put all the markup and UI logic for this feature in one file. I don’t mind this as a first step, but would always opt to then break that down into smaller components (each with their own data, parameters, logic).

You can see from this code, we’ve a few different concerns muddled up in one component.

Time to get the LLM to clean up its mess with a quick refactor.

The home component in this project is now doing too much. Can we refactor it, specifically looking for seams, so we can identify potential components to extract - suggest refactorings as you go and I will approve or course correct

It proposed several refactoring steps, all of which looked reasonable to me.

We stepped through those (and one or two more that I identified after this was done) and, with that, we had our V1 of a functional app for easily managing and capturing blog/newsletter ideas via an Astro blog.

Fun fact, it also surfaced a number of draft blog posts I apparently never finished.

In Summary

Software design is a messy, iterative affair where you often go round in circles, moving from the fuzzy to the concrete.

AI can help you with this. It works best when you keep things relatively fluid (grill me on requirements, now let’s prototype that part of the UI, perhaps we need a technical spike for this part).

Once you reach a shared understanding of what you’re building (and ideally why), it’s time to slice that work up. LLMs work best with small amounts of context, so these slices want to reflect that, but still deliver value. The litmus test is: what’s small enough to build quickly, which is technically shippable (doesn’t mean you have to ship it, but you could).

If you find yourself doing something more than once, get the LLM to turn it into a skill (as we did here, with the task-runner skill).

Finally, where possible, leave some breadcrumbs so the LLM doesn’t have to start over each time (ADRs, progress log). It saves tokens, and context, and means you can pick up where you left off for every new chat session.

That app that surfaced a pile of forgotten draft posts? It’s already doing its job. Now over to me to commit to that weekly cadence. (There’s some things AI can’t do, like provide the willpower to build good habits!)

In modern web development, page rendering speed is crucial. We render pages as quickly as possible and asynchronously load data from the server. Once the data arrives on the client, we update the web application and integrate the data into the existing page.

Therefore, modern data-driven applications are rarely in a stable state. Data might still be loading from the server, the request might fail or the server might return an empty data set.

Handling different application states is essential for creating responsive and user-friendly web applications.

In this article, we will learn how to professionally handle success, loading, empty and error states in Blazor web applications.

You can access the code used in this example on GitHub.

Basic Loading State Handling

When creating a Blazor Web App based on the .NET 10 project template, you’ll see code like this in the generated Weather page.

@foreach (var forecast in forecasts)
{
    <tr>
        <td>@forecast.Date.ToShortDateString()</td>
        <td>@forecast.TemperatureC</td>
        <td>@forecast.TemperatureF</td>
        <td>@forecast.Summary</td>
    </tr>
}

There is a forecasts field in the @code section of the component of type WeatherForecast[]?.

In the OnInitializedAsync lifecycle method, the forecasts field gets populated with the Weather data.

But what about the initial page render when the forecasts field is null?

If we use the foreach iteration statement on a null value, we’ll get a NullReferenceException during runtime. To prevent that from happening, the default project template wraps the above code in an if-else statement:

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else 
{
  // additional code omitted for simplicity
  @foreach (var forecast in forecasts)
  {
      <tr>
          <td>@forecast.Date.ToShortDateString()</td>
          <td>@forecast.TemperatureC</td>
          <td>@forecast.TemperatureF</td>
          <td>@forecast.Summary</td>
      </tr>
  }
}

As long as the value of the forecasts field is null, the Loading… text is shown on the page. When the forecasts field is populated during page initialization, the page rerenders and the else block is executed, which contains a foreachstatement that iterates over each element of the forecasts array.

While this basic setup works, it has some flaws.

1. First of all, it’s cumbersome to wrap the whole page code inside a large if-else block.
2. Next, the Loading… text is a lot smaller than the actual data rendering. That leads to vertical content shift during page load. Assume a button is below the forecast items. The user might want to click the button at the same time the list appears, moving the button away from their cursor.
3. This basic implementation also doesn’t handle the error case. Let’s say the data doesn’t load from the server for various reasons; the Loading… text will forever be visible. It’s not possible to distinguish between the null value from the page initialization and the null value from a failed data loading attempt.

The goal of this article is to show you how to do a better job handling the empty, loading and error states of Blazor components.

Handling Empty Result Sets

Sometimes the HTTP requests to the server succeeds but returns no items.

In the previous example, we would show an empty list, since the foreach statement will not be executed because the returned list does not contain any items.

A better solution is to explicitly communicate the empty result set to the user. The following code properly differentiates the loading from the empty result set state.

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else if (!forecasts.Any())
{
    <p>No weather information available.</p>
}
else 
{
  // additional code omitted for simplicity
  @foreach (var forecast in forecasts)
  {
      <tr>
          <td>@forecast.Date.ToShortDateString()</td>
          <td>@forecast.TemperatureC</td>
          <td>@forecast.TemperatureF</td>
          <td>@forecast.Summary</td>
      </tr>
  }
}

This solution clearly communicates the three different UI states: Loading, empty result set and weather information available.

Handling Errors During Data Loading

Another often-overlooked case is when an HTTP request to the server fails.

With the previous implementation, the forecasts field will remain null or set to an empty list (depending on the implementation). Both options are wrong.

It’s best practice to show an error to the user to let them know that something didn’t work properly. Otherwise, they might think that the request returned an empty result set (meaning, no weather data is available).

Consider the following data loading implementation in the OnInitializedAsync lifecycle method:

private List<WeatherForecast>? forecasts;
private string? errorMessage;

protected override async Task OnInitializedAsync()
{
    try
    {
        forecasts = await weatherService.GetWeatherDataAsync();
    }
    catch (Exception ex)
    {
        errorMessage = ex.Message;
    }
}

We use a try-catch statement to catch exceptions and store the exception message in the errorMessage field.

Hint: It’s best practice to catch and properly handle different exception types. If we cannot recover from a specific exception type, it doesn’t make sense to catch it.

In the component template, we can now show the error message to the user:

@if (errorMessage != null) 
{
    <p class="text-danger">Error: @errorMessage</p>
}
else if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else if (!forecasts.Any())
{
    <p>No weather information available.</p>
}
else 
{
  // additional code omitted for simplicity
  @foreach (var forecast in forecasts)
  {
      <tr>
          <td>@forecast.Date.ToShortDateString()</td>
          <td>@forecast.TemperatureC</td>
          <td>@forecast.TemperatureF</td>
          <td>@forecast.Summary</td>
      </tr>
  }
}

We first handle the error case before considering the error, loading, empty and success states, using an extended if-else statement with four cases.

A Cleaner State Handling Pattern with Explicit State

Let’s look at a more scalable and less cumbersome approach to handling different loading states using an explicit state enum.

First, we implement a LoadingStates enum with four states: Loading, Success, Empty and Error:

public enum LoadingStates
{
    Loading,
    Success,
    Empty,
    Error
}

Next, we add a LoadingState component:

@if (State == LoadingStates.Loading)
{
    @Loading
}
else if (State == LoadingStates.Success)
{
    @Success
}
else if (State == LoadingStates.Empty)
{
    @Empty
}
else if (State == LoadingStates.Error)
{
    @Error
}

@code {
    [Parameter, EditorRequired]
    public LoadingStates State { get; set; }

    [Parameter]
    public RenderFragment? Loading { get; set; }

    [Parameter]
    public RenderFragment? Success { get; set; }

    [Parameter]
    public RenderFragment? Empty { get; set; }

    [Parameter]
    public RenderFragment? Error { get; set; }
}

We have a required State parameter of type LoadingStates, which will receive the current state of the parent component.

The Loading, Success, Empty and Error properties provide an optional parameter of type RenderFragment. Those properties are then used depending on the state of the parent component.

Hint: You can learn more about templating Blazor components with RenderFragements.

Next, we use the LoadingState component inside the Weather component:

<LoadingState State="@_loadingState">
    <Loading>
        <p><em>Loading...</em></p>
    </Loading>
    <Empty>
        <p>No weather information available.</p>
    </Empty>
    <Success>
        <table class="table">
            <thead>
                <tr>
                    <th>Date</th>
                    <th aria-label="Temperature in Celsius">Temp. (C)</th>
                    <th aria-label="Temperature in Fahrenheit">Temp. (F)</th>
                    <th>Summary</th>
                </tr>
            </thead>
            <tbody>
                @foreach (var forecast in forecasts)
                {
                    <tr>
                        <td>@forecast.Date.ToShortDateString()</td>
                        <td>@forecast.TemperatureC</td>
                        <td>@forecast.TemperatureF</td>
                        <td>@forecast.Summary</td>
                    </tr>
                }
            </tbody>
        </table>
    </Success>
    <Error>
        <p class="text-danger">Error: @errorMessage</p>
    </Error>
</LoadingState>

Instead of the if-else statement, we use the LoadingState component and provide the loading state of the Weather component as its State parameter.

We can now provide HTML definitions for each of the four loading states. For example, we move the table rendering the weather information into the Success child element.

The code section looks like this:

@code {
    private IEnumerable<WeatherForecast> forecasts = [];
    private LoadingStates _loadingState = LoadingStates.Loading;
    private string? errorMessage;

    protected override async Task OnInitializedAsync()
    {
        _loadingState = LoadingStates.Loading;

        try
        {
            forecasts = await WeatherService.GetWeatherDataAsync();
            _loadingState = forecasts.Any() ? 
                LoadingStates.Success : 
                LoadingStates.Empty;
        }
        catch (Exception ex)
        {
            errorMessage = ex.Message;
            _loadingState = LoadingStates.Error;
        }
    }
}

In addition to the forecasts field, we have a _loadingState field and an errorMessage field.

In the OnInitializedAsync method, we first set the loading state to Loading. This allows the Blazor application to communicate that it’s loading data by rendering the Loading state fragment defined in the component template.

Next, we use a try-catch statement to handle unexpected exceptions. In the try clause, we use the WeatherService to fetch the data from the server and set the _loadingState field to Success or Empty depending on the data received.

In case of an exception, we set the error message to the errorMessage field in the catch block and set the _loadingState field to Error.

Hint: You can test the error state by voluntarily throwing an exception inside the WeatherService implementation.

Improved Developer Experience

Optional: You could implement default behavior inside the LoadingState component for the loading and error cases.

That way, you maintain consistency throughout the application and can override the default implementation in specific cases. And you shorten the component template for most components, such as the Weather component in this example.

@if (State == LoadingStateEnum.Loading)
{
    @Loading ?? <p>Loading...</p>
}

In the LoadingState component, we use the ?? operator to render the provided render fragment or the default template.

You could do the same for the Error state or maybe even the Empty state.

Conclusion

In data-driven applications, handling states such as loading, error, empty and success is crucial for providing a modern user experience.

The default project template doesn’t provide a solution to handle all of them. It focuses on the happy path while neglecting other cases.

In this article, we learned two ways to properly handle the four loading states. The second approach, using a dedicated LoadingState component, is more reusable and clearly differentiates between all the states.

If you want to learn more about Blazor development, watch my free Blazor Crash Course on YouTube. And stay tuned to the Telerik blog for more Blazor Basics.

In Parts 1 and 2, we used AI to help us get clear about what we’re building and why. We scoped it down and were explicit about what’s not in scope. This left us with some decisions made and a starting point for the next step.

But what is that step? Well that depends slightly on what you’re trying to do.

In Part 1, we identified that software design is messy. Reaching a shared understanding about what you’re building (shared with other humans or AI) is a challenge. What we definitely don’t want to do is give AI a giant spec and tell it to “go build it.” There are too many unknowns and opportunities for AI to drift from what we really wanted in the first place.

So how do we break this down into smaller steps and stay agile so we can react to reality when it hits us in the face and demands we change direction?

It turns out there are answers to be found in the classic software development texts. The Pragmatic Programmer (a book you absolutely should read, especially if you’re using AI for coding) talks about tracer bullets and prototypes. They are two different tools for slightly different purposes.

Tracer Bullets

A tracer bullet is a bullet that’s loaded at intervals alongside regular bullets and leaves a trace when fired. The idea is it helps you locate the target (if you see the tracer bullets hitting a target, so are the other bullets).

In coding terms, we can use this to build something that gives you early feedback that you’re aiming at the right target.

In a project like this, a useful tracer bullet might be a minimal feature that exercises the entire stack (UI to backend to persistent storage). Or maybe that first stage of setting up the web project, running it and checking it loads in the browser.

The key with the tracer bullet is that it’s production code, built vertically, to verify your basic premise holds up.

Prototypes

Prototypes are different. They’re useful for testing out UI designs or spiking technical choices that you haven’t used before. You can use them for everything from generating multiple versions of a screen (UI only, no backend) to settle on a design/UX, to spiking out how Claude’s Agent SDK could work to give your app AI capabilities.

The big difference between prototypes and tracer bullets is that prototypes are throwaway. Once you’ve used them to clarify an aspect of your project, you chuck them in the bin. Tracer bullets, on the other hand, are small vertical slices of your app that you then keep and build on over time.

So Which Is It to Be?

In this case, I wanted to think through the UI and UX for this new app. Specifically to figure out the ergonomics of everything we decided was in scope (in Part 2).

Now I want to prototype this. To be clear, this prototype is for deciding on the rough shape of the UI for this feature. I would like to see a rough mockup (not over-designed) of how this article workspace could look. This is prototype code which will be thrown away, so does not need to be functional beyond showing me potential UI/UX

Again, we’re starting with a prompt to see how Codex (GPT 5.5) handles this. From that prompt, it created a basic V1, which was surprisingly functional but had a few issues.

The issues here include:

• The “Quick Capture” is too small to be useful (top-left).
• The newsletter showing on the right (or underneath on smaller screens) feels a bit sidelined over there (again, too small).
• Overall, this is trying to do much on one screen.

But the markdown editor works, as does the left-hand nav, and I liked the idea of the publish checks (which we had surfaced in earlier conversations with the AI).

So, over a few messages, we iterated this prototype:

Capture an idea that is way too small to be useful. I think I’d be tempted to have that as a button, and a modal in this case (not always a fan of a modal, but seems OK here)

It then built a new modal for capturing an idea, but it added more fields. This is a trap with LLMs trying to be helpful (drifting from the brief), so I brought it back.

we’ve drifted from the brief there, we agreed to simply capture a rough idea/title and also optionally why it matters. So the idea should be a text area (rough idea) too and we don’t need additional fields

After a few more back-and-forths, we arrived at a better version, but I wanted to check we’d met the requirements listed in the most recent ADR (created in the last step).

if you review the ADR, what does this screen not meet (in terms of the requirements we landed on)

After a couple more iterations we landed here:

Key features that came out of this process:

• “Capture idea” button (opens modal)
• Shared “editor pane” for both Article and Newsletter (with tabs)
• Consistent UI/UX across both tabs (with publish checks on right)
• Same markdown editor used on both tabs
• AI functionality on the newsletter tab (to generate hook and subject line ideas)

The key thing that jumped out for me here was the realization that, although the ADR captured the details of what we were aiming for, it was only during this “mockup” stage that some key design decisions were made. It’s another example of using AI to help you, the human, think.

Because this is throwaway code, it’s cheap to iterate, throw ideas around and think through the ergonomics of this feature. This is not 1:1 production code, but it helped us arrive at some key UI/UX decisions, and we can always use this as a reference point when we come to build the real thing. It will be up to us how closely we want the AI to stick to this “design.”

Now for the Tracer Bullet

With that UI sorted, the next step is to make this something that runs in the browser, and as quickly as possible. A perfect case for tracer bullets!

using the prototype we settled on, please identify candidates for our first tracer bullet and present them to me. This should be a tracer bullet as in the Pragmatic Programmer, something we can build that’s real, and will be the basis of our app

At this point, GPT gave me a few options:

• Capture Idea To Real Draft
• Article Plus Companion Newsletter Draft
• Publish Draft To Blog
• Open Existing Draft and Save Edits

As this new UI will need to work with MDX files in my Astro blog as the source of truth, I figured “Open Existing Draft and Save Edits” was a good first step (proves the architecture and immediately gives me a new editor for existing content).

GPT suggested this acceptance test:

Given an existing Astro MDX draft, I can open the app, edit the article body in a comfortable editor, save it, close the app, reopen it, and see the same edited draft loaded from the real Astro source file.

At this stage, we need something to build from (which is a little more detailed than that acceptance test).

Ok great let’s capture that. I feel like we should create a task/ticket/issue for this.

With that GPT created a task md file. Here’s part of it:

This is all about context. We want to give AI enough context to do the work, but not so much it has to start guessing and interpreting mountains of detail to find the parts it needs.

This is a good first step. Next time, we’ll build that tracer bullet for real.

AI will build whatever you ask it to, so you’d better ask for the right thing.

Last time, we saw how to use AI to dig into a problem and define the rough shape of a viable solution. By the end of that session, we’d decided to keep things simple: a markdown editor that works directly with MDX files, a way to draft the corresponding newsletter emails and a publishing workflow to make the article live on the web.

We’d avoided heavy technical discussions, UI design or carving out specific features, and ended up with a number of decision records (markdown) which captured the decisions we made along the way. Now we needed to get more specific and figure out which feature to build first.

Here’s the prompt I tried this time (using GPT 5.5).

We previously worked through an ideation process for this new project and captured key decisions as ADRs on disk. Please now work with me to carve out the headline feature we want to build first, that we think has the best chance of delivering the value we carved out in phase 1. We know what we’re trying to build and why, now we want to make this concrete by figuring out what this core feature is. Do not get into specific implementation details here. The goal is to shape the feature (mapping to the decisions we’ve already made).

Ask me questions, one at a time, to flesh this out enough that we can later define our first behavioural tests, which will then drive implementation.

For each question, include your recommended answer.

By no means is this a perfect prompt, but the key thing I wanted was for GPT to focus on the headline feature—the thing we can build that will deliver the greatest value (to address the problem we identified in Part 1).

To avoid getting into the technical weeds at this stage, the instructions are to stay firmly in “what can the user do, and what does it achieve” territory. Just as with Part 1, this flushed out some crucial details.

For example, GPT asked how I wanted the flow between writing an article and then drafting its related newsletter to work.

I realized I didn’t want this to be a linear process (write article, prepare newsletter) but more of an editing surface where I could jump between the two.

I’d say the prepare newsletter can happen any time, I might potentially work on the article, then mid-writing realise I’ve got the hook for the newsletter and decide to jump over there to draft that (or at least capture it). So it’s not linear

To which GPT responded:

That’s a useful constraint: the headline feature is not a linear wizard. It’s an article workspace with a linked newsletter draft available at any time, plus a deliberate publish action when the blog post is ready.

Recommended shape: every article has a companion newsletter area that can be opened whenever inspiration hits. It can hold rough notes, hooks, or a near-final email. Publishing the blog post later gives that newsletter draft the final URL it needs.

We dug into details around how any AI assistance might work with the newsletter editor. I don’t like the idea of AI writing content for me, but would be happy to use AI for hook and subject line suggestions.

Next question: how should the app present those hook/subject suggestions so they help without taking over?

I answered:

I think maybe options for the user to generate hooks, generate subjects etc. then a way to take one and use it (or get new ones if they’re no good)

GPT:

That gives the assistance a clean role: explicitly requested idea generation for newsletter framing, with user-controlled insertion.

We covered a lot of ground in this chat, including:

• When you mark a finished article as ready to publish, should the feature generate the newsletter draft automatically?
• When you begin the publish article action, what guardrails should the app check before it lets you proceed?
• When the blog post is published, what should happen to the newsletter draft automatically?
• What is the main user-facing promise of this headline feature in one sentence?

AI Recommended Answers

In the prompt, I’d asked the LLM to include its recommended answer when asking questions.

This seems “off” at first (surely that’s your job, as the human!), but it turns out to be quite helpful.

There is a danger that you’ll just start accepting what the AI suggests because it’s the easiest option, so it’s worth thinking carefully about what you really think before blindly accepting its recommendations. But in many cases the AI gets it right, or close enough that you can tweak it and move on.

One of the biggest challenges with defining scope is being clear what not to build.

On this occasion, GPT caught this, finishing with this question:

Before we stop, one final shaping question: what would be explicitly out of scope for the first version of Article Workspace?

• Social posts.
• Newsletter sending/scheduling.
• Full AI article generation.
• Complex idea inbox or content pipeline states.
• Analytics beyond simple publishing visibility.
• Multi-user/productized workflows.
• Deep DevScribe/Bento integration.
• Rigid streak mechanics.
• Implementation-specific Git UI details beyond a deliberate publish action.

It’s tempting to think that, with AI, we could include some of these and let it go at them. But we still care about code quality and building features that work, and the best way to do that with LLMs is to be specific and reduce how many things we ask it to do at a time.

So I agreed with all of these being out of scope and we settled on this shape for the headline feature.

# Headline Feature: Article Workspace

Article Workspace lets you capture an idea, develop it into a Markdown article, prepare a companion newsletter draft, publish the blog post to Astro, and keep the email follow-up visible so the audience receives useful value and the weekly publishing rhythm builds trust over time.

## Core Happy Path

You open the app, capture a useful idea with why it matters, immediately get a draft article workspace, write the Markdown article, optionally draft newsletter hooks, subject, and body alongside it, confirm publish readiness, publish the blog post to Astro by marking it not draft and committing/pushing, then see the final URL available to finish the linked newsletter draft for separate sending.

## Key Boundaries

- Idea capture is the earliest form of a draft, not a separate workflow.
- Capture requires the idea plus why it matters / what is at stake / angle.
- The “why it matters” note stays visible near the editor, not inside the published article by default.
- Newsletter writing can happen at any time, not only after the article is finished.
- AI assistance is limited to optional hooks and subject-line suggestions.
- Blog publishing and newsletter sending remain separate deliberate actions.
- Blog success means the article is in Astro source, marked not draft, committed, and pushed.
- Newsletter success means subject/body are ready, reviewed, and have access to the final article URL unless sending the full article verbatim.

## Out of Scope For First Version

Social posts, newsletter sending/scheduling, full AI article generation, complex idea inbox or pipeline states, broad analytics, multi-user workflows, deep DevScribe/Bento integration, rigid streak mechanics, and implementation-specific Git UI detail beyond a deliberate publish action.

One last step, I asked GPT to capture this and it chose to record a new ADR.

It could be that ADRs aren’t the right tool here (using them for everything feels like we might be over-simplifying how we capture requirement details), but in the interest of pragmatism I chose to accept it and move on to the next stage.

Measure Twice, Cut Once?

Let’s address the elephant in the room. When you work through a process like this (with or without AI), it can feel like a lot of effort up front. The temptation is to bypass this stage. Wouldn’t it be quicker to simply throw a prompt at Codex and hope it sorts it out for us?!

In short, not really.

With the prompt-and-pray approach, you might feel like you’re going faster, but this thinking, scoping and being clear about what you’re building is going to happen somewhere.

The danger of jumping straight to prompt is you’ll end up with something that doesn’t solve the problem. Or you’ll spend much, much longer iterating to the solution because the thinking is happening as new code is written.

LLMs work best with smaller amounts of information in their context window (fewer tokens). If you can break the work down ahead of time, you can keep your context minimal for each small step.

If you start with wide-open scope, you’ll find yourself throwing more and more features at the problem (because building stuff is fun!). But the real goal here is to take the smallest step, in order to get feedback (from real users).

I’ve found this up-front thinking work pays dividends down the road.

But rather than take my word for it, give it a go for yourself. Get that impulsive part of your brain to take a back seat for an hour or so while you work with AI to get clear about what you’re building.

Then, when you’re ready, move on to the next step: figuring out what to build first and what that should actually look like. We’ll get into that in Part 3.

We’ll also discover how some old techniques, borrowed from a classic software development playbook, make AI work better too.

How do you go from idea to working software? That’s the challenge we face as software developers.

While AI feels like it’s changed everything, it hasn’t changed that fundamental problem.

It’s not a question of how quickly AI can write code (answer: very quickly), but rather how soon can we find out if our assumptions are correct and if we’re building the right thing to move the needle.

Do we even know what needle we’re trying to move in the first place?

In this short series, we’ll explore how we can use AI to build the right things, to solve the most urgent problems, without shipping substandard code.

• We’ll start with a vague premise and see if AI can help us sharpen our understanding of what we’re building (and why).
• Then we’ll move on to working with AI to carve out the headline feature we want to build first.
• We’ll remove ambiguity (and reach a shared understanding of what we’re building) using prototypes and tracer bullets.
• Then we’ll establish the architecture of what we’re building (including key technology choices), break the work down into smaller steps and build it.

First, we need to get clear about what we’re building.

A Journey of a Thousand Miles Begins with a Single Step

If you’ve been experimenting with AI, you already know the big AI trap. The temptation to just throw a vague prompt its way, cross your fingers and hope it magically builds the perfect web application (while you sleep).

In reality it’s not that simple.

AI will happily run off and build whatever you ask it to, which is problematic if you ask it to build the wrong thing, start with fuzzy requirements or give it too much to do in one step.

So, the first task is the same as it’s always been: get clear about the problem you’re solving.

In this case, I started with a simple problem to solve. I have a goal of writing at least one article a week for my personal blog and also an email to my newsletter audience (based on the same blog post). In reality, that cadence is rarely once a week, and often drifts to once a month or, in the worst case, once “every now and then.”

So starting with that problem, I gave this prompt to GPT 5.5 (via the Codex GUI):

I want to build a new web application using .NET 10 and Blazor. Please grill me on the idea, what it’s for, key technology choices, and help me scope out a reasonable first version so we can get user feedback as soon as possible

This did not go well.

GPT 5.5 responded with a giant wall of text and lots of questions. It started diving into implementation details about Blazor (which render mode to use, etc.) and essentially skipped the part where it finds out what I’m trying to build before focusing on those implementation details.

I started over, and tried different variations of the same prompt.

First I got it to ask me one question at a time, which worked better, but I realized it was still jumping to technical details. I wanted to keep it focused on problems and ideal outcomes, not technical matters or even defining the feature details at this stage.

After a few iterations we arrived at this:

I want to build a new web application using .NET 10 and Blazor.

Please grill me on the idea.

Ask me one question at a time, and include your brief recommendation for each question.

Dig into each answer until that thread is clear, then move on to the next question.

For notable decisions (anything fundamental, or where the reasoning for which can’t be deduced from implementation), capture that decision as an ADR in a decisions folder.

Help me explore the problem space, and the core outcomes we want this application to achieve.

Do not scope features at this point, that will come next.

This worked better.

Over the course of a 45-minute back-and-forth, we fleshed out the problem I was trying to solve, and the rough shape of any potential solution. I won’t include the entire conversation here, but here are some highlights.

It asked:

Where do ideas currently appear first: while at your computer, on your phone, in notes, in code/projects, from conversations, or somewhere else?

The answer I gave included this phrase: “Could be anywhere really.”

GPT 5.5 wasn’t having that.

This one isn’t quite a decision yet, because “could be anywhere” can lead to a lot of product surface.

Follow-up question:

For the first version, is it acceptable if mobile capture is only a lightweight inbox, with real writing/editing still expected to happen at a keyboard?

In my experience, AI shines with this kind of process, digging into answers you give it and getting clear so you can make concrete decisions, not just hand-wavey “ideas.”

Some more questions it posed:

What would make this application feel like a calm writing system rather than another obligation to maintain?

What is the smallest publishing rhythm that would still feel successful: exactly one post/email every week, or a sustainable average with occasional skips and catch-ups?

What would make you stop using this app, even if it technically worked?

Notice how GPT 5.5 stayed on task here, exploring the problem and not getting into feature design, or technical choices.

Eventually we arrived at this summary:

The core shape is now clear: a local-first, single-user Blazor/.NET app that helps you maintain a weekly blog-plus-newsletter rhythm, with the Astro repo as source of truth, a calm Markdown writing experience, lightweight AI assistance, and explicit publishing/Git steps.

The main technical decision made was the one I started with (that we’d be using Blazor to build it) and some high level thoughts around source of truth, and the existing systems (like my blog).

We also ended up with a number of architecture decision records (ADRs) captured in markdown documents. ADRs are typically used to capture technical decisions, but were also useful here for capturing the decisions we arrived at around the problem and solution itself.

Here’s one example:

# ADR 0028: Slug Generation
Status
Accepted

## Context
Blog posts need a final URL slug. The slug should usually be short, readable, and aligned with the article's content or main takeaway.

Manual override is sometimes needed.

## Decision
The application should generate slugs automatically from the article title or main takeaway, while allowing the user to override them.

Slugs should be treated as stable after publication unless deliberately changed.

## Consequences
Slug generation should optimize for short, meaningful URLs rather than blindly mirroring the full title.
The user must retain control over the final slug.
Published slug changes should be treated as deliberate edits, not incidental metadata updates.

Whenever I work through an AI interview like this, I find I emerge with a much clearer picture of what I’m building (and why). The LLM’s questions force me to think and often surface angles I hadn’t previously considered. In some cases I’ve gone on to realize building a feature is actually unnecessary (a change to existing habits or processes would achieve the same result).

In this case, though, we’re on the right track and have a clearly scoped brief for an editor to capture ideas and author content.

Make It Work for You

When you try to use AI to build something like this, you might feel like there should be some simple streamlined process you can work through. A clean process where you feed a feature idea in, AI gives you perfect code out and you ride off into the sunset.

Alas, software design is anything but streamlined, and no AI tool is going to take the chaos of defining and refining an idea and handle it in a nice straight line.

In this case, getting AI to grill you about the idea is one part of the design process, but there are others, which we’ll come to shortly. We started high-level here because this was an embryonic idea and a greenfield application. But if you already had an app and were adding a feature, you might skip this step and jump straight into designing a specific feature/requirement.

Iterate Your Prompts

But what about the prompt itself? Did I happen upon some perfect, fully formed prompt that made AI work perfectly? In short, no!

Prompts rarely arrive fully formed. In this case, I started with a vague prompt, then refined and tested it until I found one that worked better for my needs. This is a key difference I’ve noticed between people who get good results from an LLM and those who feel frustrated.

It’s useful to learn how to write effective prompts, or “meta prompts” (where you get AI to write the prompt for you), and run rapid iterations so you can get something that works for you. Here it took around five minutes to get to a prompt that worked well for this exercise.

You can also turn to examples published online (Matt Pocock’s skills are a clear standout), but it’s useful to learn how to create your own skills/prompts, based on your own unique workflow and preferences.

With that said, we’ve carved out our idea: a simple “surface” for capturing ideas and turning those into articles (with the source of truth being an MDX in an Astro blog).

Now to define the headline features. That’s next, in Part 2.

In data-driven applications, it is common to want to display information dynamically and visually. However, there are times when we have doubts about which type of chart to use in our applications.

Choosing the wrong type of chart can cause users to become confused or even distort the information by displaying it incompletely or with a layout that doesn’t make much sense.

That is why this article is a roundup of the types of charts available in the Progress Telerik UI suite for Blazor and when to use each. Let’s get to it!

Chart Types in Telerik UI for Blazor

Let’s analyze the different types of charts available in Telerik UI for Blazor, as well as when to use them.

Column Chart

The first type of chart, column, is perhaps the simplest. With this chart we can display vertical bars in which the height represents the value of each category. It’s a quite versatile chart type, which is why it’s very common to see it in applications and elsewhere. The chart looks like the following:

This type of chart is useful when we want to compare values across categories, show rankings or classifications, and visualize data where order does matter.

Bar Chart

The bar chart is the equivalent of the column chart but in a horizontal format. In the Telerik component ChartSeriesType.Bar is used and the category axis is on the vertical axis instead of horizontal:

This chart can be used when category names are long and you need more space to display them, when you want to show a horizontal comparison between values, and when you want to emphasize the difference in values between categories.

Line Chart

The line chart displays a graph with connected points, which makes this chart ideal for showing trends over time. In the Telerik component it supports normal, step and smooth lines:

This chart is suitable when we want to visualize temporal trends, compare different evolutions within the same period and when continuity between data points is relevant.

Area Chart

This type of chart is similar to the line chart, with the difference that the space beneath the lines is filled with a semi-transparent color. This gives greater emphasis to the volume or magnitude of the data. In the Telerik component we can control the opacity using the Opacity property.

You can use this chart when you want to emphasize the volume of the data, their trend or when you want to show how different series overlap.

Pie Chart

The pie chart displays a circle divided into proportional slices for each value specified in the category. It only supports a single series, which makes it an ideal chart for showing the composition of a whole:

Some examples of when to use this type of chart are when you want to show a percentage distribution of data, while being mindful of the maximum number of slices so as not to overcrowd the chart. Likewise, when you want users to quickly understand portions of a whole and when you require the values to add up to 100%.

Donut Chart

This type of chart is similar to a pie chart but with a hole in the center. This hole can be used to display a highlighted data point or, as the Progress Telerik team has done, allow multiple series to be shown:

This chart is recommended for showing, in addition to the pie-chart scenarios, hierarchical relationships between data sets.

Scatter Chart

The scatter chart displays a series of points defined by the x and y axes, with these being numeric data:

This type of chart is ideal when you want to show a correlation between two numeric variables, such as the relationship between users connected in an application and a website’s load time. It is also useful for identifying patterns, clusters, scientific data, among others.

Bubble Chart

This chart is similar to the scatter chart in how it works, but adds a third dimension, which is the size of the bubble:

The third dimension is useful for comparing entities with multiple metrics simultaneously.

Scatter Line Chart

The scatter line chart is similar to the scatter chart, except that in this case the points are connected by lines:

This chart is convenient to use when you want to show the relationship between two variables while maintaining continuity in the data or trend.

Candlestick Chart

This candlestick-style chart is widely used in the financial sector, as it allows showing four values for a period: open, close, high and low. If we are talking about stocks in the securities market, the body of the candle represents the price from open to close, while the wicks, which are the thin lines above and below, show the period’s high and low:

This chart is suitable for showing financial movements or when you want to identify trading patterns.

OHLC Chart (Open-High-Low-Close)

This chart shows the same four values as the candlestick chart, but instead of using candle bodies, it uses horizontal marks. In this chart the horizontal values represent the open and close, while the lower and upper extremes show the maximum and minimum:

The use cases for this chart are the same as for the candlestick chart, but when you want a cleaner visualization. It is also ideal when you want to show many time periods, in which a candlestick chart would overlap the values.

Heatmap Chart

The heatmap displays a grid where color intensity represents the magnitude of a value across two dimensions:

If you are a software developer, you will surely recognize the image above, since GitHub shows a similar chart to display the commits you have made on an account. This demonstrates that the chart is ideal for showing an activity density in two dimensions and when you want to show behavior patterns across intersecting categories.

Radar Line Chart

This chart starts from a common center from which several axes radiate. Each axis represents a specific value, which are then connected to form a closed shape:

It is very useful when you want to make profile comparisons, such as variables between LLM models or when you want to make before/after comparisons.

Radar Area Chart

This radar area chart is similar to the radar line chart, with the difference that the space of the formed shape is filled with a color:

This chart works well to understand how different profiles overlap on the chart quickly.

Radar Column Chart

The radar column chart follows the same principle as the radar line and radar area charts, with the difference that it shows diagonal bars extending from the center:

By showing bars instead of connecting points, this chart is excellent for comparing individual values across categories and when an overlap in the radar area could make reading values difficult.

Range Area Chart

The range area chart shows an area defined between two continuous lines defining the range between a minimum and a maximum value, similar to the area chart but not starting from zero:

By displaying ranges, it is ideal in scenarios such as temperature ranges, error margins and when you need to emphasize a difference between continuous sequences of values.

Range Bar Chart

This chart lets you display ranges of values over a period of time using horizontal bars, whose position and length vary according to a from value and a to value:

This chart can help you show time ranges or durations, or compare ranges between categories or groups.

Range Column Chart

It is the vertical version of the range bar chart. In this chart vertical bars are displayed, which vary according to the from and to values:

This chart could be useful to show ranges of scores between periods or when you need to emphasize both the minimum and the maximum of each category.

Waterfall Chart

This chart is based on a series of bars that show a cumulative value of sequential positive and negative values. Each bar starts where the previous one ended, which allows you to see the value’s behavior after a period. In the Telerik component it is also possible to display columns with total or partial values:

Use cases for this chart include when you need to analyze cash flow over months, for budget and profitability analysis, among others.

Sankey Chart

This Telerik component TelerikSankey displays a set of entities and links to represent the flow between them. In addition, the thickness of each link shows the value, allowing users to easily see the entity-to-value flow:

Because of its flexibility, the Sankey chart is ideal for analyzing traffic distributions, breaking down budgets or redistributing resources.

Stock Chart

To use a stock chart, you should use the TelerikStockChart component, which is part of the Telerik UI for Blazor suite. This component is specifically designed for financial time series data. It supports types we’ve already covered such as candlestick and OHLC, with the difference that it includes a navigator to select a specific time period:

This component is useful when you need to navigate time periods in financial data or to create trading dashboards or investment analysis.

Trendline Chart

The last chart type we’ll analyze is the trendline type. This chart isn’t really a chart type where you define its own data; rather, it takes the data from an existing chart to reveal the trend of the data. The component supports several trend types: linear, average, exponential, logarithmic, among others:

Some use cases for this chart type include revealing the overall direction of the data, smoothing fluctuations, performing forecasts, as well as conducting statistical analyses and validating patterns over time.

Decision Tree for Selecting the Best Chart

After having analyzed the different types of charts that we can find in the Telerik UI for Blazor suite, I want to leave you a decision list that can help you select the best chart for your use case:

Comparison & Trends
- If there is time or continuity -> Use a line, area or scatter line chart
- If there are simple categories -> Use a column or bar chart
- If there are long category names -> Use a bar chart
- If you want to show underlying trends -> Add a trendline

Composition (Parts of a Whole)
- For a single series -> Use a pie or donut chart
- For multiple series -> Use a donut chart
- For flows between domains -> Use a Sankey diagram

Relationships & Distribution
- With 2 variables -> Use a scatter plot
- With 3 variables -> Use a bubble chart
- For 2D density -> Use a heatmap
- For multidimensional profiles -> Use a radar chart (area, column or line)

Ranges & Cumulative Changes
- To show the effect of changes -> Use a waterfall chart
- For continuous ranges -> Use a range area chart
- For time durations -> Use a range bar chart
- For vertical ranges -> Use a range column chart

Specialized Data
- For financial/price movement -> Use a candlestick or stock chart

This list should help you make a better decision about when to use each type of chart.

Conclusion

Throughout this article, we have taken a tour of the different types of charts that we can find in the Telerik suite for Blazor. This was aimed at understanding the structure of each one, how it looks and which are the best scenarios for their use. After this information, it’s your turn to present your users’ data in different ways, always keeping in mind that their interpretation should be as simple as possible.

Ready to experiment with all these chart types? Telerik UI for Blazor comes with a free 30-day trial:

Try Now

In modern web development, we often asynchronously load data from the server. Blazor is no different. To let the user know that data is being loaded and the app is working, we should show a busy or loading indicator during such operations.

In this article, we will implement a basic loading indicator in Blazor using CSS and also explore more advanced solutions.

You can access the code used in this example on GitHub.

The Blazor Project Template Approach

Let’s start simple by looking at the loading indicator used in the default Blazor project template.

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
    <!-- code omitted -->
    </table>
}

This very basic approach uses an if-else statement to determine the component state and a simple paragraph HTML element to render a “Loading…” text.

There are a few flaws with this overly simplistic solution:

1. Static text does not provide a modern user experience. In a world where attention spans are short and user experience is important, we should use a spinner animation or another element that conveys the feeling of progress.

2. Static text does not act as a placeholder with the correct size. In the example above from the Weather page of the default Blazor project template, the Loading text has a much lower height compared to the fully rendered table containing the weather information.

3. A code snippet like the Loading text above is not reusable. It doesn’t include a CSS class to make it look consistent across pages, nor is it reusable. Copying the same snippet across multiple pages will yield different user experiences if one of the developers decides to alter its design in the future.

A Basic Reusable Loading Indicator Component

Let’s build a basic reusable LoadingIndicator component. First of all, we want to internalize the loading state.

This helps us get rid of the if-else statement in each page component. We want the code in the page component to look like this:

<LoadingIndicator IsLoading="@(forecasts == null)">
    <table>
    <!-- code omitted -->
</LoadingIndicator>

Let’s start with the component template:

@if (IsLoading)
{
    <div class="loading-indicator" Style="@($"height: {Height}px")">
        <div class="circular-progress" />
        <div class="progress-text">Loading...</div>
    </div>
}
else
{
    @ChildContent
}

We internalized the if-else statement handling the loading state. During loading, we display a loading indicator, which consists of three divs.

We show the child content (in the example above, an HTML table) when the loading state is false.

Now let’s look at the code section:

@code {
    [Parameter]
    public required int Height { get; set; } = 96;

    [Parameter, EditorRequired]
    public required bool IsLoading { get; set; }

    [Parameter, EditorRequired]
    public RenderFragment? ChildContent { get; set; }
}

Here, we have three component parameters. Let’s go through them one by one.

The Height parameter is optional (notice the absence of the EditorRequired attribute). By default, the height of our loading indicator is 96 pixels. However, we can provide a custom value to this property for each instance on a page component.

The IsLoading parameter decides whether the loading indicator or its children are rendered.

The ChildContent parameter of type RenderFragement allows us to wrap the content of the page into the LoadingIndicator for a good developer experience.

Now that we have the component template and its behavior, we need the CSS styling:

.loading-indicator {
    display: flex;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    width: 100%;
    gap: 8px;
}

.circular-progress {
    width: 32px;
    height: 32px;
    border: 3px solid rgba(0, 0, 0, 0.1);
    border-top: 3px solid #3b82f6;
    border-radius: 50%;
    animation: spin 0.8s linear infinite;
}

.progress-text {
    font-size: 1rem;
}

/* Spinner animation */
@keyframes spin {
    0% {
        transform: rotate(0deg);
    }

    100% {
        transform: rotate(360deg);
    }
}

CSS, unfortunately, most of the time requires a lot of code to implement rather simple things.

For example, here, we have the loading-indicator class, which contains a flex layout and its layout properties. It basically takes up the entire available width and places its children one below the other.

Next, we have the circular-progress class, which defines the circle’s layout. It’s the base of our animation.

The progress-text class is simple for now and only sets the font-size.

Last but not least, we have an animation definition using keyframes. We use the named animation in the circular-progress class’s animation property.

Let’s see how it works in action.

I set the delay in the Weather page component to 2 seconds so that I can see the full loading animation for testing.

// Simulate asynchronous loading to demonstrate a loading indicator
await Task.Delay(2000);

As soon as the data is loaded from the screen, the IsLoading property of the LoadingIndicator component will return false. Therefore, instead of the circular progress animation, we will see the pages’ content.

Hint: One of the advantages of component-oriented web frameworks such as Blazor is that we can reuse this LoadingIndicator component and therefore hide the large CSS definition and the component behavior behind this LoadingIndicator component.

Professional Integrated Solutions

While we definitely provided a more useful component and a better user experience with our reusable LoadingIndicator component, there is still room for improvement.

As application developers, we want to provide the best solutions for business problems while providing the best possible user experience.

We should focus on delivering value to our business rather than wasting time implementing generic components. Standing on the shoulders of giants is the right call.

There are professional user interface libraries, such as Progress Telerik UI for Blazor. Developers of those libraries invest much more time into building those reusable components than we are able to spend in our projects.

Component libraries like Telerik UI for Blazor integrate sophisticated loading indicators and loading state handling into higher-level components, such as AutoComplete fields, Grid layouts and ListViews, and more advanced components like TreeList and TreeView.

Conclusion

Handling the loading state and providing a good user experience during asynchronous data fetching operations is crucial in modern web development.

The default Blazor web application project template provides a simple solution that lacks in multiple regards.

We implement a custom LoadingIndicator component, which improves the solution from the default project template by extracting logic and behavior into a reusable component. Using its Height property, we can make the loading indicator take the same space as the rendered elements, thus preventing layout shifts. It’s a step in the right direction.

However, if possible, I usually prefer using one of the brilliant, existing solutions over my handmade approach. For example, the Loader and LoaderContainer components provide a great developer and user experience for building modern Blazor web applications.

Telerik UI for Blazor comes with a free 30-day trial, so you can explore these plus 120 other components for yourself.

Try Now

Imagine this: instead of clicking through a travel app—picking dates, applying filters, scrolling results, opening tabs to compare—you type one sentence:

“I want to get a flight from London to New York. Give me a plan as a dashboard with important data about the flight.”

What comes back is more than a paragraph explaining the basics. It’s a whole interface with a structured results grid showing airline, price, duration and departure time. It’s a comparison view so you can weigh your options, all assembled on the spot. No predefined screen needed. Just intent and a UI that responds to it.

That is the experience shift A2UI creates. And it is coming to Progress Telerik UI for Blazor.

Don’t miss the live demo! Register for the Telerik and Kendo UI 2026 Q2 release webinar on June 16 to see A2UI transforming intent into interactive Blazor UI in real time.

What Is A2UI?

A2UI (Agent-to-User Interface) is an open protocol introduced by Google that defines a standard way for AI agents to communicate their intent to generate a user interface. Think of it as a universal UI language that agents can speak to any client application.

Rather than describing insights, AI describes interfaces. The application then renders those interfaces using its own UI framework, styling and interaction model.

In this model:

• AI facilitates the UI composition layer. It reasons over context and emits a structured definition—a declarative JSON format describing which components to render and what data to populate them with.
• The application remains the source of truth for rendering and behavior. The client maintains a catalog of pre-approved components.
• The user experiences fully interactive interfaces generated from intent. Not static mockups. Not screenshots. Real components with real data.

A2UI effectively shifts AI from being a narrator to being a composer of user experiences.

A2UI in Telerik UI for Blazor

Within Telerik UI for Blazor, A2UI introduces an additional layer on top of the existing component ecosystem. Components are no longer only developer-defined. They become composable primitives available for AI-driven interface construction.

In effect, the library becomes a structured palette for dynamic interface generation. Your design system stays intact. Your business logic does not move.

Why A2UI Makes Sense: Agents Think in Text; Users Work in Interfaces

AI is rapidly reshaping how software is built and consumed. Over the past year, we have seen an acceleration of copilots, agents and large language models capable of reasoning over data, executing workflows and assisting users in ways that were previously out of reach.

Yet, one fundamental limitation remains.

AI is exceptionally good at producing text. But applications are not built around text. They are built around interfaces.

People perceive and interact more easily through visuals—dashboards, forms, grids, charts, filters, and workflows they can interact with directly. They want to see, explore and act. This is why A2UI has so much potential.

Modern enterprise applications have long assumed that UI is static. Developers define screens. Users adapt to them. AI, when introduced, typically sits alongside the application as a conversational layer rather than becoming part of the interface itself.

A2UI introduces the possibility to change that. When AI systems generate structured UI definitions that adapt to context and data, rather than just a block of text, we aren’t just enabling what the system says, but what the user sees.

A single request like “analyze my sales performance this quarter” can translate into multiple valid experiences depending on who is asking and why—an executive KPI dashboard, a detailed filterable data grid, a chart-centric exploratory view or a hybrid analytical workspace. The underlying data is the same, but the intent is different. And AI is uniquely positioned to interpret it.

A2UI in Practice

Use cases for A2UI implementation are as myriad as you can imagine.

Let’s go back to the example of booking a flight. Instead of tedious stepping through pages, one by one, filling and selecting values, you can type: “I want to fill a form for booking a flight from London to New York.”

The AI interprets that intent and emits a UI definition—a JSON description of a data form (pre-filled with data where possible and using the right components), a results grid (columns: airline, price, departure, duration, stops) and a comparison chart with the top options.

The Blazor renderer receives that definition and displays the interface using real Telerik UI for Blazor components. The Grid, the Form, the Charts—all themed and all enabling you to interpret and visualize data as naturally as possible.

Different users expressing the same intent might receive different representations depending on context, preferences or available data. Maybe one person gets a chart-first view and another gets a table. That is dynamic UI generation in practice.

A Step Further: Building on an Emerging AI Ecosystem

The flight-booking scenario reflects a much broader shift happening across the AI ecosystem. Applications are moving from static interactions toward dynamic, personalized, agent-driven experiences where intent, reasoning and UI composition are tightly connected.

This is where the A2UI approach becomes part of a larger architecture rather than a standalone concept.

In the current implementation, the demo builds on complementary layers that are increasingly relevant in modern AI systems:

• AI interprets user intent, translating natural language into structured goals and constraints.
• The Microsoft Agent Framework orchestrates reasoning and execution, coordinating tools, workflows and multi-step decision-making across systems.
• AG-UI provides the interaction contract for agent-driven interfaces, so UI intent and structure are expressed in a consistent, agent- and renderer-agnostic way.
• The A2UI layer for Telerik components for Blazor defines the structure of the user experience, describing how the outcome of that reasoning should be expressed as a dynamic, interactive UI rather than plain text.
• Telerik UI for Blazor renders the final experience, materializing that structure using enterprise-grade components such as grids, forms and charts with full theming, interactivity and performance.

Together, these components enable AI systems to move beyond conversational output and participate directly in application workflows. Instead of producing text responses, agents can reason over data and shape the user experience itself.

Telerik A2UI Renderer for Blazor—Availability: Preview

A2UI is still an emerging concept and ecosystem. Standards, protocols, component contracts and implementation patterns are actively evolving as the industry explores what dynamic UI generation should look like in production applications.

We are approaching A2UI with the same mindset. The feature is still experimental. As the implementation is evolving, feedback is actively shaping its direction.

During this phase, we are actively observing real-world usage patterns, gathering feedback from early adopters and refining how intent translates into UI structure. Specifically, we are exploring where AI-generated UI delivers real value and how much control users need to retain over generated interfaces.

The A2UI specification itself is at v0.8 stable, and the ecosystem around it—transport layers like AG-UI, Agent Frameworks from Microsoft (hint: we are exploring those too) and others and renderers for different frameworks—is all moving quickly. This is the right moment to explore the pattern, give us feedback and understand how the renderer model fits your architecture. And get to the next level of creating great UI and UX experience.

The current A2UI Preview for Telerik UI for Blazor focuses on a constrained but high-impact set of building blocks:

• Input components – text fields, date pickers, numeric inputs, dropdowns
• Data Grid – data exploration, visualization and comparison
• Charts – visual representations that adapt to what the data warrants

These are intentionally chosen because they represent the backbone of most business applications. This Preview is opinionated by design. Rather than attempting to support every UI pattern, it focuses on exploring how intent can reliably map to structured, usable interfaces. Go straight to the demo, click and prompt around on an easy-to-follow use case and get in touch with feedback.

If your organization is exploring AI-powered applications in 2026, this is the ideal time to start a pilot. Use our Support system to tell us more about your use case or drop us a line in our Blazor Feedback Portal or in the Telerik Forums.

The goal isn’t to replace your existing application. The goal is to explore how AI can augment it through interfaces that adapt to the user, the context and the task at hand.

WebMCP vs. A2UI: What’s the Difference?

If you’ve been following our recent AI initiatives, you may have also seen our Preview support for WebMCP, which enables AI agents to interact with applications through standardized tools and capabilities.

While both WebMCP and A2UI are part of the broader movement toward AI-native applications, they address different parts of the big picture.

You can think of them as complementary layers: WebMCP focuses on how AI agents interact with applications. A2UI focuses on how applications interact with users through AI-generated experiences.

Together, they create a powerful foundation for AI-native applications and are an extension of our commitment to great UI and UX.

With WebMCP, an AI agent can discover available actions, execute workflows, retrieve data and interact with business functionality exposed by an application.

With A2UI, that same agent can dynamically generate forms, grids, charts, dashboards and other user experiences that help users understand, validate and act on the results.

An AI agent can use WebMCP to retrieve information, execute actions and understand business capabilities, while A2UI can transform those results into dynamic user experiences built with Telerik UI for Blazor components.

To learn more about our WebMCP Preview support, check out our blog post: Telerik and Kendo UI Meet WebMCP.

The current capabilities represent only the beginning. The beauty of dynamic UI generation is that the number of possible use cases is virtually unlimited. AI maps context and intent, while Telerik UI for Blazor provides the components that bring those experiences to life.

Want to shape how A2UI support for Telerik UI for Blazor develops? Share your thoughts on the Blazor Feedback Portal or in the Telerik forums. We are reading everything.

And don’t forget to join the webinar for a live demo of A2UI.

If you’ve worked with .NET for any length of time, you’ve made peace with the .sln file. Not because it’s good (it isn’t) but because it’s the format we have. It’s verbose, GUID-laden and a reliable source of merge conflicts on Friday afternoons. It’s the format we tolerate, not the one we’d choose.

The good news is there’s a new format in town. The .slnx format is Microsoft’s XML-based replacement for the venerable .sln file, and it has been steadily gaining first-class support across Visual Studio, the .NET CLI, MSBuild and Rider over the last year. As of .NET 9.0.200 and Visual Studio 17.13+, you can use it for real projects without crossing your fingers. And as of .NET 10, dotnet new sln defaults to .slnx.

In this post, let’s talk about what .slnx is, why it exists, what it gets right and where you might get tripped up.

A Quick SLN Retrospective

To appreciate why we’re getting a new format, let’s remember what we’ve been working with. Here’s a typical fragment of an .sln file.

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.10.34804.81
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MyApi", "MyApi\MyApi.csproj", "{F95781B3-A973-4D19-9585-974DA143E6A1}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution Items", "{8FC526EA-218B-4615-8410-4E1850611F38}"
ProjectSection(SolutionItems) = preProject
Directory.Build.props = Directory.Build.props
EndProjectSection
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Any CPU = Debug|Any CPU
Release|Any CPU = Release|Any CPU
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{F95781B3-A973-4D19-9585-974DA143E6A1}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{F95781B3-A973-4D19-9585-974DA143E6A1}.Debug|Any CPU.Build.0 = Debug|Any CPU
{F95781B3-A973-4D19-9585-974DA143E6A1}.Release|Any CPU.ActiveCfg = Release|Any CPU
{F95781B3-A973-4D19-9585-974DA143E6A1}.Release|Any CPU.Build.0 = Release|Any CPU
EndGlobalSection
EndGlobal

Oof. The SLN format is a custom Microsoft format that has some weird quirks. Every project gets a GUID. Solution folders are themselves projects with their own GUIDs. Configuration combinations even get cross-multiplied so a four-project solution with two configurations and two platforms produces 16 lines of nearly identical setup.

The pain points are well known to us all. If even two developers add a project at the same time, both edit GlobalSection(ProjectConfigurationPlatforms), and Git throws its hands up.

GUIDs, bless their hearts, are not for human eyes. It’s a nightmare trying to figure out which project owns which configuration block. And outside of Visual Studio, generating or modifying .sln files reliably often requires a tool like slngen because no one wants to write the parser themselves.

This is what the .slnx tries to fix.

Looking Inside the .slnx

Here’s the same project, but expressed as .slnx.

<Solution>
  <Folder Name="/Solution Items/">
    <File Path="Directory.Build.props" />
  </Folder>
  <Project Path="MyApi/MyApi.csproj" />
</Solution>

Notice how we have no GUIDs, no cross-multiplied configuration table and no EndGlobalSection markers. Even a developer who is foreign to the .slnx format can read it and immediately understand it.

Expanding a little, here’s an example from a layered solution.

<Solution>
  <Folder Name="/Solution Items/">
    <File Path=".editorconfig" />
    <File Path="Directory.Build.props" />
    <File Path="Directory.Packages.props" />
  </Folder>
  <Folder Name="/src/">
    <Project Path="src/Application/Application.csproj" />
    <Project Path="src/Domain/Domain.csproj" />
    <Project Path="src/Infrastructure/Infrastructure.csproj" />
    <Project Path="src/Web.Api/Web.Api.csproj" />
  </Folder>
  <Folder Name="/tests/">
    <Project Path="tests/UnitTests/UnitTests.csproj" />
    <Project Path="tests/IntegrationTests/IntegrationTests.csproj" />
  </Folder>
</Solution>

If you compare this to the equivalent .sln, you’re looking at maybe a third of the lines, with none of the GUID overhead. If you need to override configurations for a specific project (like, say your test project shouldn’t build in Release mode) you can express that with a Configurations element on the project. In reality, most projects won’t need it at all. If you do, you can review examples in microsoft/vs-solutionpersistence and its samples wiki.

If the .slnx looks similar to a .csproj, that’s intentional. Microsoft’s reasoning is that XML is already the format the rest of MSBuild speaks, the team already had a parser for it, and features like comments and attributes are first-class citizens. A JSON or YAML format might have been trendier, but it would have forced the team to invent semantics for things .csproj already has solved problems for.

Migrating Existing Projects

Existing projects are a different conversation. Here’s what you get by migrating, and how to do it cleanly.

• Merge conflicts are more manageable. Because there are no GUIDs that change every time you touch a project, the diffs you see in PRs are meaningful. If you add a project, you see one line added. Move a project to a different folder, and you see the path change. Nobody has to play GUID detective.
• You can reasonably edit by hand. You’ll never want to hand-edit a .sln unless it’s an emergency. With .slnx, opening it in your editor of choice is perfectly reasonable. I’ve fixed broken solution layouts in a text editor faster than Visual Studio would have let me click through the dialogs.
• Tooling has standardized what a solution is. Microsoft has open-sourced the parser as the Microsoft.VisualStudio.SolutionPersistence NuGet package. This means MSBuild, the .NET CLI and third-party tools are all reading the same file the same way.

Based on the official dotnet sln reference, the actual conversion is one command.

dotnet sln migrate

If you run this in a directory with an .sln file, you’ll get an .slnx file beside it. From Visual Studio, you can also use File -> Save Solution As… and pick XML Solution File (.slnx) from the dropdown. Rider supports a similar flow.

You don’t want to keep both files in the repository. The dotnet sln commands don’t reliably pick the right one when you have both, and it’s easy for the two to get out of sync as people add or remove projects. Pick when to cut over, delete the old file and move on. While there is a community tool called dotnet-sln-sync that helps, that should only be used temporarily and not long term.

As you convert over, here’s a quick checklist to avoid any headaches:

• Verify your global.json allows the right SDK. You need at least .NET 9.0.200 for full CLI support. If your global.json pins to something older, the migrate command won’t work.
• Check your CI build agents. If you’re on self-hosted Azure DevOps agents, for example, confirm they’re running an SDK new enough to handle .slnx.
• Audit your pipelines. Anywhere you have references directly to .sln, update the path. Wildcard references like **/*.sln will miss the new file. If you are using templates where you have a mix of .sln and .slnx, a pattern like **/*.sln* will be useful.
• Look out for dependent tools. Tools like slngen don’t yet support .slnx at the time of this post (you can track the issue here). If you’re reliant on a tool outside of the Microsoft umbrella, check before you migrate.

Some Rough Edges

The .slnx format is no longer “preview” in any practical sense, but the ecosystem around it is still catching up.

• Visual Studio file association. Double-clicking a .slnx file doesn’t open Visual Studio by default. You can fix this with a file association or just open it from inside the IDE.
• C# Dev Kit in VS Code. It works, but you may need to set dotnet.defaultSolution to the path of your .slnx if it isn’t auto-detected.
• Globbing. You can’t write <Project Path="src/**/*.csproj" /> and have it discover projects automatically. The team’s reasoning, captured in the globbing feature request, is that globbing slows down solution loading on large repos because Visual Studio has to scan the file system before it can render anything. That makes sense, but I think plenty of us would happily trade a slower cold load for never having to add another project entry by hand.
• Third-party tools. Anything that parses .sln directly needs to update. Hopefully the open-source parser library accelerates that, but you’ll find holdouts.

None of these are dealbreakers for new projects. For older codebases with a lot of tooling baked in, it’s worth doing a small pilot before flipping the whole repo.

Wrapping Up

The .slnx format isn’t a revolutionary feature. It doesn’t change how you write code, it doesn’t add new build capabilities, and it doesn’t speed up your application. It is, however, one of those quality-of-life upgrades that quietly results in fewer merge conflicts, less time staring at GUIDs, less friction in your CI pipelines once they’re set up.

If you’re starting a new .NET solution, just use .slnx from day one. And with .NET 10, you’ll get it without lifting a finger. If you’re maintaining an existing .sln file, plan a migration when you have a slow week, audit your tooling and cut over cleanly. The format isn’t going anywhere, and getting ahead of the transition is easier than waiting for some downstream tool to force your hand.

Thanks for reading, and happy coding!

Further Reading

• New, simpler solution file format
• Introducing support for SLNX in the .NET CLI
• microsoft/vs-solutionpersistence
• dotnet sln command reference
• .NET 10 breaking change: dotnet new sln defaults to SLNX

I remember exactly where I was when Visual Studio 2026 dropped back in November: at my desk, watching the Microsoft launch event with one eye and refactoring an IDataReader implementation with the other.

The keynote was typical Microsoft. There was a lot of “reimagining how developers work.” There was, of course, a slide with the word “intelligent” on it at least eight times. And the word “Copilot” appeared on screen so many times I started to wonder if Microsoft’s marketing team had been replaced by an infinite loop that just prints Copilot forever.

Then I installed the thing.

The first week with VS 2026 was the most disoriented I’ve felt in a Visual Studio release since the menu bar went all-caps in 2012 and I spent a month reading angry forum threads about it.

In 2026, I was tripped up by the just-slightly different Solution Explorer, the Copilot panel that lives where my Test Explorer used to live, the general Copilot onslaught and the interesting design choices. I felt like everything on my desk had been moved slightly to the left.

That was temporary. As with most new technology, eventually things felt normal again. I was finding workflows that genuinely beat my old ones and I stopped noticing the cosmetic changes. So here’s where I am six months later … same machine, same kind of solution I work in every day, just a different IDE around it.

We meet again, old friend. At least the menu bar isn't in caps.

Six months in, I feel comfortable. Six months is long enough to live with the rough edges, and find what’s genuinely useful. So I’m here to share them with you.

As an aside: to keep my sanity intact, I’m going to use the word “Copilot” only when I absolutely have to. Microsoft has decided that every feature in Visual Studio is now Copilot-something … Copilot Chat, Copilot Edits, Copilot Agent, Copilot Workspaces, GitHub Copilot, Copilot for Azure, Copilot for Pull Requests and so on. So when I say “the agent” or “the AI thing in the sidebar,” you’ll know what I mean.

The Performance Story Is Real

I’ll lead with this, mostly because it was the thing I was most skeptical about. Every Visual Studio release for the past decade has touted “X% faster solution load!” and, to me, every Visual Studio release for the last decade has felt (roughly) the same speed once you test it with your beefy codebase.

VS 2026 is genuinely faster. Not “marketing-faster” … actually faster. The 64-bit-everywhere story that started with VS 2022 has matured into something that handles large solutions without the periodic “please hold” pauses we’re all familiar with. In Microsoft’s VS2026 launch post, they say they cut hangs by over 50%.

The IntelliSense responsiveness is the part I notice most. Typing a . after an object now produces suggestions roughly when I expect them to appear. A low bar? Definitely, but previous versions frequently limboed under it.

Agent Mode Is Useful, When You Pick the Right Job

GitHub Copilot’s agent mode in Visual Studio 2026—or, as Microsoft prefers, GitHub Copilot Agent Mode powered by Copilot in Visual Studio with Copilot—has improved tremendously since Visual Studio 2022. Six months in, I think it’s genuinely useful, but for a specific set of tasks.

In my experience, it works well with scoped, well-defined refactors. If I want to ask: Hey Copilot, add a new health check for this Cosmos container and follow the pattern in my existing health checks. (Yes, I sometimes talk to Copilot like a home assistant.) Or: Take my new controller and add the same logging pattern as the others in this project. And, after discovering some methods in a codebase with 11 nested if statements: Convert this for loop to a LINQ expression but keep it readable. It’s effective enough that I’ve stopped writing this kind of code by hand.

In my experience, things get harder when the agent needs to understand why something exists. The agent will happily refactor a piece of code that only exists because of, say, a weird third-party integration constraint from 2018, and the resulting code will be cleaner, more maintainable … and broken in production. Did I actually break something in production? Not this time. But I would have.

To be fair to the agent, this is exactly where it needs context. It doesn’t read minds (although it sure does try). Here’s a pattern I’ve leaned on.

// AGENT NOTES:
// - This service must remain synchronous; the upstream caller cannot
//   be made async without a contract change.
// - The string "PRIME" is required by the third-party integration. 
//   I don't like it but they won't change it. Do not "improve" it 
//   to PersonType.Prime.ToString().
// - Cancellation tokens must be forwarded; do NOT pass `default`.

When the agent has clear context like this, it really delivers. Below is the agent producing two new health check files plus a registration update in Program.cs, all from one prompt asking it to mirror an existing pattern. The result is a careful refactoring with the right substitutions swapped in. That’s exactly the kind of work I’m happy to hand off.

The agent panel and one of the two generated files. Three files changed, zero hand-written by me. (My team is thankful for the latter.)

This sounds like babysitting, and it is. Welcome to AI-driven development, my friends. The 10 seconds of setup saves me from a 10-minute cleanup later. When the prep is solid, the result is solid.

For more information on custom instructions, check out the Microsoft documentation.

Test Explorer Isn’t Frustrating

In my experience, the Test Explorer seems to be much improved in Visual Studio 2026. If I had to sum it up in previous versions, I’d say “it’s fine” … after all, do we ever get jazzed about tests? In previous releases, I kept saying “it’s fine” until I had a few thousand tests, at which point it started getting opinionated about which tests to run.

The new version is faster, the filtering predictably works, and it doesn’t lose track of which tests are running when you switch branches mid-execution. Try it yourself. Run your full test suite and watch the Test Explorer not embarrass itself. It’s a small joy.

One of those things you don't notice until it stops getting in your way.

Better Git Integration

Visual Studio’s Git tooling has historically been one of the IDE’s more underwhelming features. Until recently, my workflow was:

1. Make code changes in Visual Studio.
2. Run Git commands in my terminal (or a third-party tool like GitHub Desktop)
3. Ignore the IDE’s Git panel entirely.

With VS 2026, I’m finally doing real Git work inside the tool. The new staging interface is better. The conflict resolution UI is also better than it used to be. The “please show me an actual diff and not a vague summary” feature is good.

Now, it’s no GitKraken and it doesn’t try to be. But it’s good enough that I no longer switch over to a terminal for routine operations, and that works for me.

Three-way merge view, in the IDE I'm already in. Rejoice!

Hot Reload That Reloads More Often

Hot Reload has been one of those features that worked on Friday afternoons if I said “please work” (especially for ASP.NET Core). Any other time, I’d change a method body, save, watch the IDE think very hard about it, and then get: “Hot Reload was unable to apply your changes. Restart the application?”

The “hot” in “Hot Reload” was stretching the truth at times (with the understanding that getting it right isn’t as simple in .NET as it is for languages like JavaScript).

With VS 2026, I now reach for it instinctively instead of cynically. Method-body edits in controllers, services and Razor pages just apply. You change a string in a controller, hit Save and see the change. You know, the way it was supposed to work in 2021. The way it kind of worked in 2023. The way it now actually works in 2026.

When Hot Reload can’t apply a change (because the change requires a metadata update or you’ve added a field or whatever the actual reason is), the IDE now tells me clearly why instead of vaguely throwing up its hands. That alone goes a long way. I know whether to keep iterating or to just restart the host.

Debugger Improvements (Especially with Async Traces)

Have you ever stared at an async stack trace and felt your soul leave your body? Just me?

Historically, when an exception bubbled up from somewhere deep in an async/await chain, the stack trace was a wall of MoveNext calls and state machine internals. It was tremendously useful if you wanted to learn about the C# compiler, but not great if you wanted to know which of your methods actually threw.

Things are looking better in Visual Studio 2026. The debugger now stitches together async call chains into something that reads like the call graph you actually wrote. The MoveNext noise is collapsed by default. The original calling method is shown as the parent frame and not buried six levels down. When an exception is thrown inside a Task.WhenAll, you can see which task threw without reverse-engineering the parallel structure.

An async exception, with the actual call chain visible. No MoveNext translation required.

On top of that, conditional breakpoints feel faster to evaluate, and the tracepoints (where you can log a message without breaking) is a one-click affair instead of a buried right-click option.

Small wins. But debugging is the thing I do every day, and small wins on the thing you do every day add up fast.

The Verdict

Look, the Copilot stuff is genuinely impressive. The agent demos at the keynote were the kind of thing that makes you want to fire up the installer immediately. And after six months, I’ll admit that I use it every day.

But Visual Studio 2026 is a genuine step forward for the boring reasons. The performance is real. The Test Explorer doesn’t stress me out. The debugger provides stack traces a human can read. The agent mode handles the kind of work I’d previously do by hand. Those are the wins that show up in my daily work, not the ones that show up in keynote demos.

If you’re on Visual Studio 2022 and wondering whether to upgrade: yes. Ignore the marketing, and let the unglamorous improvements do their job. Six months later, you won’t be excited about Visual Studio 2026 … and that’s exactly the point. You’ll just be working faster.

Form validation is essential when working with data in Blazor applications. Before .NET 10, if you wanted to perform validation of nested objects, you had to take a series of additional steps that could add complexity to your projects. In this article, we will examine the improvements and new features in .NET 10 to solve this problem through a practical exercise. Let’s go!

Understanding the Problem of Nested Validations Before .NET 10

To see the problem when working with nested objects and their validation, let’s create a sample Blazor project. For this demonstration, I am working with a project using the Blazor Web App template configured with Interactive Server rendering globally.

Immediately after creating the project, perform the installation and configuration steps for the Progress Telerik UI for Blazor controls, as we will use them to quickly build modern interfaces.

Creating Models in the Application

Suppose we are building an attendee registration application for a technical event. As a first step, I have defined a class EventRegistration with the following structure:

public class EventRegistration
{
    public Attendee Attendee { get; set; } = new();
    public BillingAddress BillingAddress { get; set; } = new();
    public List<SessionSelection> Sessions { get; set; } = [];

    [Range(typeof(bool), "true", "true", ErrorMessage = "You must accept the terms and conditions.")]
    public bool AcceptTerms { get; set; }
}

The model above has some nested objects, both single objects such as Attendee and a list of type SessionSelection. Likewise, there is a validation on the property AcceptTerms of type Range, which verifies that the value is true.

The model of a Attendee looks as follows:

public class Attendee
{
    [Required(ErrorMessage = "Full name is required.")]
    [StringLength(100, ErrorMessage = "Name cannot exceed 100 characters.")]
    public string? FullName { get; set; }

    [Required(ErrorMessage = "Email is required.")]
    [EmailAddress(ErrorMessage = "Invalid email format.")]
    public string? Email { get; set; }

    [Required(ErrorMessage = "Phone number is required.")]
    [Phone(ErrorMessage = "Invalid phone number format.")]
    public string? Phone { get; set; }

    [Required(ErrorMessage = "Company name is required.")]
    public string? Company { get; set; }

    [Required(ErrorMessage = "Job title is required.")]
    public string? JobTitle { get; set; }
}

The Attendee model has more validation annotations per property, which allow validating each attendee’s information. The project also includes the BillingAddress model to store address information, also featuring validation attributes:

public class BillingAddress
{
    [Required(ErrorMessage = "Street address is required.")]
    public string? Street { get; set; }

    [Required(ErrorMessage = "City is required.")]
    public string? City { get; set; }

    [Required(ErrorMessage = "State/Province is required.")]
    public string? State { get; set; }

    [Required(ErrorMessage = "Postal code is required.")]
    public string? PostalCode { get; set; }

    [Required(ErrorMessage = "Country is required.")]
    public string? Country { get; set; }
}

Finally, the SessionSelection model defines the structure of each session selected by an attendee:

public class SessionSelection
{
    [Required(ErrorMessage = "Session name is required.")]
    public string? SessionName { get; set; }

    [Required(ErrorMessage = "Preference level is required.")]
    public string? Preference { get; set; }
}

The complexity among the previous models will allow us to test the new validation features included in .NET 10.

Initializing Project Data Using a Session Catalog Service

To display mock data in the application, let’s create a SessionCatalog service, where we’ll define a list of sessions:

public class SessionCatalog
{
    public List<string> GetAvailableSessions() =>
    [
        "Keynote: The Future of .NET",
        "Workshop: Blazor Advanced Patterns",
        "Talk: SignalR Real-Time Communication",
        "Workshop: Minimal APIs Deep Dive",
        "Talk: Cloud-Native .NET Applications",
        "Workshop: AI Integration with .NET"
    ];

    public List<string> GetPreferenceLevels() =>
    [
        "High",
        "Medium",
        "Low"
    ];
}

We will register this service in Program.cs as follows:

var builder = WebApplication.CreateBuilder(args);
...
builder.Services.AddSingleton<SessionCatalog>();

var app = builder.Build();

Creating the Graphical Interface

To perform various checks, let’s create a graphical interface using the TelerikForm component. This will enable generating and customizing model-based forms and with many configuration parameters, making it a powerful and useful component for our example. The resulting code looks like this:

@page "/registration"
@rendermode InteractiveServer
@using FormValidationNET10.Models
@using FormValidationNET10.Services
@inject SessionCatalog SessionCatalog

<PageTitle>Event Registration</PageTitle>

<h1 class="mb-4">Event Registration</h1>

<TelerikForm EditContext="editContext"
             OnValidSubmit="HandleValidSubmit">
    <FormValidation>
        <DataAnnotationsValidator />
        <TelerikValidationSummary />
    </FormValidation>
    <FormItems>
        <FormItem Field="Attendee.FullName" LabelText="Full Name" />
        <FormItem Field="Attendee.Email" LabelText="Email" />
        <FormItem Field="Attendee.Phone" LabelText="Phone" />
        <FormItem Field="Attendee.Company" LabelText="Company" />
        <FormItem Field="Attendee.JobTitle" LabelText="Job Title" />
        <FormItem Field="BillingAddress.Street" LabelText="Street" />
        <FormItem Field="BillingAddress.City" LabelText="City" />
        <FormItem Field="BillingAddress.State" LabelText="State / Province" />
        <FormItem Field="BillingAddress.PostalCode" LabelText="Postal Code" />
        <FormItem Field="BillingAddress.Country">
            <Template>
                <label for="country-editor" class="k-label k-form-label">Country</label>
                <div class="k-form-field-wrap">
                    <TelerikDropDownList @bind-Value="registration.BillingAddress.Country"
                                         Data="@countries"
                                         DefaultText="Select a country..."
                                         Id="country-editor" />
                    <TelerikValidationMessage For="@(() => registration.BillingAddress.Country)" />
                </div>
            </Template>
        </FormItem>
        <FormItem Field="AcceptTerms">
            <Template>
                <div class="k-form-field-wrap">
                    <TelerikCheckBox @bind-Value="registration.AcceptTerms" Id="acceptTerms" />
                    <label for="acceptTerms" class="ms-2">I accept the terms and conditions</label>
                    <div>
                        <TelerikValidationMessage For="@(() => registration.AcceptTerms)" />
                    </div>
                </div>
            </Template>
        </FormItem>
    </FormItems>
    <FormItemsTemplate Context="formContext">
        @{
            var items = formContext.Items.OfType<IFormItem>().ToList();
        }

        <div class="card shadow-sm mb-4">
            <div class="card-header bg-primary text-white">
                <h5 class="mb-0">Attendee Information</h5>
            </div>
            <div class="card-body">
                <div class="row g-3">
                    <div class="col-md-6">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "Attendee.FullName"))" />
                    </div>
                    <div class="col-md-6">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "Attendee.Email"))" />
                    </div>
                    <div class="col-md-4">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "Attendee.Phone"))" />
                    </div>
                    <div class="col-md-4">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "Attendee.Company"))" />
                    </div>
                    <div class="col-md-4">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "Attendee.JobTitle"))" />
                    </div>
                </div>
            </div>
        </div>

        <div class="card shadow-sm mb-4">
            <div class="card-header bg-primary text-white">
                <h5 class="mb-0">Billing Address</h5>
            </div>
            <div class="card-body">
                <div class="row g-3">
                    <div class="col-12">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "BillingAddress.Street"))" />
                    </div>
                    <div class="col-md-4">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "BillingAddress.City"))" />
                    </div>
                    <div class="col-md-4">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "BillingAddress.State"))" />
                    </div>
                    <div class="col-md-4">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "BillingAddress.PostalCode"))" />
                    </div>
                    <div class="col-md-12">
                        <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "BillingAddress.Country"))" />
                    </div>
                </div>
            </div>
        </div>

        <div class="card shadow-sm mb-4">
            <div class="card-header bg-primary text-white d-flex justify-content-between align-items-center">
                <h5 class="mb-0">Session Selection</h5>
                <TelerikButton OnClick="@AddSession"
                               ThemeColor="@ThemeConstants.Button.ThemeColor.Light"
                               ButtonType="@ButtonType.Button">
                    + Add Session
                </TelerikButton>
            </div>
            <div class="card-body">
                @if (registration.Sessions.Count == 0)
                {
                    <div class="alert alert-info mb-0">
                        No sessions added yet. Click "Add Session" to select the sessions you'd like to attend.
                    </div>
                }
                else
                {
                    @for (int i = 0; i < registration.Sessions.Count; i++)
                    {
                        var index = i;
                        <div class="row g-3 mb-3 align-items-end">
                            <div class="col-md-5">
                                <label class="k-label k-form-label">Session</label>
                                <TelerikDropDownList @bind-Value="registration.Sessions[index].SessionName"
                                                     Data="@availableSessions"
                                                     DefaultText="Select a session..." />
                                <TelerikValidationMessage For="@(() => registration.Sessions[index].SessionName)" />
                            </div>
                            <div class="col-md-4">
                                <label class="k-label k-form-label">Preference</label>
                                <TelerikDropDownList @bind-Value="registration.Sessions[index].Preference"
                                                     Data="@preferenceLevels"
                                                     DefaultText="Select preference..." />
                                <TelerikValidationMessage For="@(() => registration.Sessions[index].Preference)" />
                            </div>
                            <div class="col-md-3">
                                <TelerikButton OnClick="@(() => RemoveSession(index))"
                                               ThemeColor="@ThemeConstants.Button.ThemeColor.Error"
                                               ButtonType="@ButtonType.Button">
                                    Remove
                                </TelerikButton>
                            </div>
                        </div>
                    }
                }
                <TelerikValidationMessage For="@(() => registration.Sessions)" />
            </div>
        </div>

        <div class="card shadow-sm mb-4">
            <div class="card-body">
                <TelerikFormItemRenderer Item="@(items.First(x => x.Field == "AcceptTerms"))" />
            </div>
        </div>
    </FormItemsTemplate>
    <FormButtons>
        <TelerikButton ButtonType="@ButtonType.Submit"
                       ThemeColor="@ThemeConstants.Button.ThemeColor.Primary">
            Submit Registration
        </TelerikButton>
    </FormButtons>
</TelerikForm>

@if (isSubmitted)
{
    <div class="alert alert-success mt-4">
        <h5>Registration Successful!</h5>
        <p>Thank you, <strong>@registration.Attendee.FullName</strong>! Your registration for @registration.Sessions.Count session(s) has been submitted.</p>
    </div>
}

@code {
    private EventRegistration registration = new();
    private EditContext editContext = default!;
    private List<string> availableSessions = [];
    private List<string> preferenceLevels = [];
    private List<string> countries = ["United States", "Canada", "Mexico", "United Kingdom", "Germany", "France", "Spain"];
    private bool isSubmitted;

    protected override void OnInitialized()
    {
        editContext = new EditContext(registration);
        
        availableSessions = SessionCatalog.GetAvailableSessions();
        preferenceLevels = SessionCatalog.GetPreferenceLevels();
    }

    private void AddSession()
    {
        registration.Sessions.Add(new SessionSelection());
    }

    private void RemoveSession(int index)
    {
        registration.Sessions.RemoveAt(index);
    }

    private void HandleValidSubmit(EditContext context)
    {
        isSubmitted = true;
    }
}

Validating Data Before .NET 10

Once we have all the pieces of the project, let’s run it. Let’s do a test by trying to submit the empty form:

In the previous image, you can see that when submitting the form the only error shown is the one indicating that the terms and conditions have not been accepted. However, although all models implement validations, no others are shown.

The reason behind this is that DataAnnotationsValidator in Blazor does not perform validation on nested objects or collections. This has been a known limitation in Blazor since its beginnings, which was addressed using custom recursive validators. Let’s see how .NET 10 helps us solve this problem.

Validating Data Thanks to the New Features in .NET 10

To perform validation of nested objects and collections, the first step you must take is to add in Program.cs a call to the method AddValidation():

var builder = WebApplication.CreateBuilder(args);
...
builder.Services.AddValidation();

var app = builder.Build();

The method AddValidation() registers the services required for the validation system to work.

The next step is to open the main model that contains the hierarchy of submodels and add the attribute [ValidatableType] to the class. In our example, the class is EventRegistration, which will look as follows after the modification:

[ValidatableType]
public class EventRegistration
{
   ...
}

The attribute [ValidatableType] tells the .NET source generator to generate validation logic for the class. Behind the scenes the following steps will be performed:

1. All properties of the decorated class are inspected.
2. Nested objects are detected and the necessary code to recursively validate their validation annotations is generated.
3. Collections are detected and code is generated to iterate through each element, validating their validation annotations.

After applying the previous changes, you will see that now, when submitting the form with empty fields, all errors are displayed correctly:

With these changes, we have correctly enabled full validation of nested objects and collections.

Implementing Cross-field Validation Using IValidatableObject

So far we have been able to apply validation rules at the level of individual properties. However, it is common in complex applications to have rules that involve multiple properties or complex business logic. For these cases, .NET provides the interface IValidatableObject, which in version 10 integrates seamlessly with [ValidatableType].

Let’s perform a check of this type assuming this pair of business rules:

• The user must select at least one session.
• Duplicate sessions are not allowed.

The rules depend on the state of the collection Sessions as a whole. To make it work correctly, let’s modify the class EventRegistration by adding the interface:

[ValidatableType]
public class EventRegistration : IValidatableObject
{
    ...

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
    // 1.
        if (Sessions.Count == 0)
        {
            yield return new ValidationResult(
                "You must select at least one session.",
                [nameof(Sessions)]);
        }
        
        // 2.
        var duplicates = Sessions
            .Where(s => !string.IsNullOrEmpty(s.SessionName))
            .GroupBy(s => s.SessionName)
            .Where(g => g.Count() > 1)
            .Select(g => g.Key)
            .ToList();

        if (duplicates.Count > 0)
        {
            yield return new ValidationResult(
                $"Duplicate sessions are not allowed: {string.Join(", ", duplicates)}",
                [nameof(Sessions)]);
        }
    }
}

In the code above:

1. We validate that at least one session is selected.
2. We look for duplicate sessions.

In case of any error, we return an ValidationResult indicating the error. When running the application, we see the following result if no session is selected:

Now, when duplicate sessions are selected, the following error is shown:

With this, we have created cross-field validation correctly using Blazor.

Improving Validations Using FieldCssClassProvider

At this point we have a project that correctly validates the form information, thanks to the native capabilities of TelerikForm. We can go one step further and modify the project to add visual indicators at the section level that communicate to the user which sections have errors. We can do this thanks to the method EditContext.IsValid(fieldIdentifier) introduced in .NET 10, which allows directly checking whether a field is valid.

To use it, the first thing we will do is create a class that inherits from FieldCssClassProvider. For the demonstration I will create a class called RegistrationFieldClassProvider at the root level of the project that looks as follows:

public class RegistrationFieldClassProvider : FieldCssClassProvider
{
    public override string GetFieldCssClass(EditContext editContext, in FieldIdentifier fieldIdentifier)
    {
        if (!editContext.IsModified(fieldIdentifier))
            return string.Empty;

        var isValid = editContext.IsValid(fieldIdentifier);
        return isValid ? "is-valid" : "is-invalid";
    }
}

In the code above, it checks whether the field has been modified. Next IsValid() is used inside the method GetFieldCssClass to check if the field has associated validation messages. Finally, Bootstrap classes are returned that will provide feedback to the user about the validity of the sections.

To achieve this, we will make the card headers change color according to the state of their fields by modifying Registration.razor as follows:

1. Add the event OnValidSubmit to TelerikForm:

<TelerikForm EditContext="editContext"
             OnValidSubmit="HandleValidSubmit"
             OnInvalidSubmit="HandleInvalidSubmit">

2. Find the h5 elements that reference Attendee Information and Billing Address, and modify their container div as follows:

<div class="card-header @GetAttendeeHeaderClass()">
    <h5 class="mb-0">Attendee Information</h5>
</div>
...
<div class="card-header @GetBillingHeaderClass()">
    <h5 class="mb-0">Billing Address</h5>
</div>

3. Modify the code section by adding the following changes:

@code {
   ...
    private bool hasValidated;

    protected override void OnInitialized()
    {
        editContext = new EditContext(registration);
                
        editContext.SetFieldCssClassProvider(new RegistrationFieldClassProvider());
        editContext.OnValidationStateChanged += (_, _) => StateHasChanged();        

        availableSessions = SessionCatalog.GetAvailableSessions();
        preferenceLevels = SessionCatalog.GetPreferenceLevels();
    }
    
    private bool IsFieldValid<T>(Expression<Func<T>> accessor)
       => editContext.IsValid(FieldIdentifier.Create(accessor));

    private string GetAttendeeHeaderClass()
    {
        if (!hasValidated) return "bg-primary text-white";

        bool allValid = IsFieldValid(() => registration.Attendee.FullName)
            && IsFieldValid(() => registration.Attendee.Email)
            && IsFieldValid(() => registration.Attendee.Phone)
            && IsFieldValid(() => registration.Attendee.Company)
            && IsFieldValid(() => registration.Attendee.JobTitle);

        return allValid ? "bg-success text-white" : "bg-danger text-white";
    }

    private string GetBillingHeaderClass()
    {
        if (!hasValidated) return "bg-primary text-white";

        bool allValid = IsFieldValid(() => registration.BillingAddress.Street)
            && IsFieldValid(() => registration.BillingAddress.City)
            && IsFieldValid(() => registration.BillingAddress.State)
            && IsFieldValid(() => registration.BillingAddress.PostalCode)
            && IsFieldValid(() => registration.BillingAddress.Country);

        return allValid ? "bg-success text-white" : "bg-danger text-white";
    }

    ...

    private void HandleValidSubmit(EditContext context)
    {        
        hasValidated = true;        
        isSubmitted = true;
    }
        
    private void HandleInvalidSubmit(EditContext context)
    {
        hasValidated = true;
    }
}

In the code above, I added the field hasValidated to check if the form has been submitted. I also modified OnInitialized by adding the handler for the event OnValidationStateChanged, which allows the UI to update reactively. I also added the helper IsFieldValid<T> and the methods GetAttendeeHeaderClass and GetBillingHeaderClass. This is the result:

With this, we have managed to give the user better feedback about the sections they need to complete before proceeding.

Conclusion

Throughout this article, we have explored the new features available in .NET 10 that will undoubtedly help you manage forms with nested objects and lists. We’ve also looked at how to perform cross-validations and, finally, the process of carrying out more complex validations by checking data in sections.

Now it’s your time to implement these new features in your own projects and provide better feedback to your users.

In the world of web development, there are scenarios where you need to receive real-time information, such as notifications about an event, server metrics or live logs. One possible solution to achieve this is the use of Server-Sent Events (SSE). With the arrival of .NET 10, implementing this type of solution has become much easier, so let’s see how to integrate this web standard into your projects.

What Are Server-Sent Events?

The Server-Sent Events (SSE) are not a new technology. Their origins date back to around 2006, and they are a web standard that allows data to be sent to clients continuously using a persistent HTTP connection.

If you wonder the difference compared to other similar technologies, we can make a comparison:

• SSE vs. Polling: In the case of polling, the direction goes from the client to the server, using the HTTP protocol. We can see it as a client asking the server if there are updates at certain intervals. It involves low implementation complexity.

• SSE vs. WebSockets: With WebSockets there is bidirectional communication. It involves high complexity and is ideal for scenarios like video games, chats, etc. It works over the WS protocol.

• SSE vs. SignalR: SignalR also establishes bidirectional communication, with medium implementation complexity. It allows the use of binary protocols, which makes it a very good option for scalable enterprise apps. It uses variable protocols.

Analyzing the above, we can conclude that SSE is ideal when the data flow is unidirectional, you need it to work over the HTTP protocol and it must be easy to implement.

How Does the SSE Protocol Work?

The workings behind the scenes of the SSE protocol, in broad terms, are as follows: a server SSE endpoint needs to send an HTTP response of the type Content-Type: text/event-stream. The response looks similar to the following:

event: app-event
data: {"id":1,"time":"10:30:45","level":"Info","source":"OrderService","message":"Order #1234 placed successfully"}

In the code above, there are some fields we should pay attention to:

• event: Specifies the name of the event
• data: Is the content of the message
• id: Identifier used to perform a reconnection if needed

What’s New in .NET 10 for SSE

The most important update in .NET 10 for working with SSE is that the ability to return a ServerSentEvents using the API TypedResults.ServerSentEvents has been implemented. This means that the method TypedResults.ServerSentEvents<T>() allows converting any IAsyncEnumerable<T> into a formatted SSE stream without needing to do anything else. Tasks like JSON serialization, HTTP headers, connection closing, etc. are handled automatically.

To better understand how it works, let’s create a project using the SSE standard with ASP.NET 10.

Building an SSE Project Using ASP.NET 10

To practice the theoretical concepts covered so far, we’ll create a page that shows a simulation of receiving events from backend services in real time. Using a Progress Telerik UI for Blazor Grid, we’ll perform tasks like filtering, grouping and analysis quickly.

Creating and Configuring the Project

The first thing we’ll do is create a project using the Blazor Web App template, selecting an Interactive render mode of Server and Interactivity location of Global. Next, we’ll follow the official installation guide for Telerik UI for Blazor to configure the project and be able to use the Telerik components.

Creating an EventBroadcaster

For our project, we’ll create an event broadcaster, which in simple terms will be a bus that SSE clients can connect to to consume events, while backend services will use it to publish events. First, we’ll create a record that represents a system event:

namespace SSEDemo.Services
{
    public record AppEvent(int Id, string Time, string Level, string Source, string Message);
}

Next, we will create the class EventBroadcaster which will have the following definition:

public class EventBroadcaster
{
    //1.
    private readonly Channel<AppEvent> _channel = Channel.CreateBounded<AppEvent>(
    new BoundedChannelOptions(100) { FullMode = BoundedChannelFullMode.DropOldest });

    private int _nextId;

    // 2.
    public void Publish(string level, string source, string message)
    {
        var id = Interlocked.Increment(ref _nextId);
        var evt = new AppEvent(id, DateTime.Now.ToString("HH:mm:ss"), level, source, message);
        _channel.Writer.TryWrite(evt);
    }

    // 3.
    public async IAsyncEnumerable<AppEvent> Subscribe(
        [System.Runtime.CompilerServices.EnumeratorCancellation] CancellationToken ct)
    {
        while (!ct.IsCancellationRequested)
        {
            bool hasData;
            try
            {
                hasData = await _channel.Reader.WaitToReadAsync(ct);
            }
            catch (OperationCanceledException)
            {
                yield break;
            }

            if (!hasData) yield break;

            while (_channel.Reader.TryRead(out var evt))
            {
                yield return evt;
            }
        }
    }
}

In the code above, we have the following sections:

1. Sets up the channel where events will be passed, with a queue limit of 100 messages. FullMode = BoundedChannelFullMode.DropOldest allows that if the queue fills up and a new message arrives, the oldest one is removed to make room for the new message.

2. The method Publish is the one that will be used to emit events. Interlocked.Increment allows generating sequential IDs in a safe manner, while AppEvent packages the received data together with the obtained id. Finally the method TryWrite() attempts to write the event to the channel asynchronously.

3. On the other hand, the method Subscribe returns a continuous stream of asynchronous data through the use of IAsyncEnumerable<AppEvent>. Inside its implementation an infinite loop is created that waits for data to be available in the channel. Once an event enters the channel, it is emitted to the consumer. This will happen until the CancellationToken called ct is canceled.

Generating Test Events

To test the bus defined above, we’ll create a service that simulates the activity of multiple services:

public class DemoEventGenerator(EventBroadcaster broadcaster) : BackgroundService
{
    private static readonly string[] Levels = ["Info", "Warning", "Error", "Success"];
    private static readonly string[] Sources =
        ["OrderService", "PaymentService", "InventoryService", "AuthService", "ShippingService"];
    private static readonly string[][] Messages =
    [
        ["Order #{0} placed successfully", "New customer registered", "Product viewed: SKU-{0}"],
        ["High latency detected: {0}ms", "Retry attempt #{0}", "Queue depth above threshold"],
        ["Payment failed for order #{0}", "Database timeout after {0}ms", "Service unreachable"],
        ["Deployment completed v2.{0}", "Health check passed", "Cache refreshed ({0} items)"]
    ];

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        var rng = new Random();

        while (!stoppingToken.IsCancellationRequested)
        {            
            await Task.Delay(rng.Next(1500, 4000), stoppingToken);

            var levelIdx = rng.Next(Levels.Length);
            var level = Levels[levelIdx];
            var source = Sources[rng.Next(Sources.Length)];
            var templates = Messages[levelIdx];
            var message = string.Format(templates[rng.Next(templates.Length)], rng.Next(1000, 9999));

            broadcaster.Publish(level, source, message);
        }
    }
}

The previous class is a random event generator, taking a random value from the arrays Levels, Sources and Messages. In addition, through the parameter broadcaster, the new event is published to the bus.

Creating the SSE Endpoint

Now it’s time to create the SSE endpoint, which will consume the shared EventBroadcaster, with the purpose of creating the Event Feed so clients can connect to receive events:

public static class SseEndpoints
{
    public static void MapSseEndpoints(this WebApplication app)
    {        
        app.MapGet("/sse/events", (EventBroadcaster broadcaster, CancellationToken ct) =>
            TypedResults.ServerSentEvents(broadcaster.Subscribe(ct), eventType: "app-event"));
    }
}

In the code above you can notice how EventBroadcaster is injected as a parameter of MapGet. Likewise, TypedResults.ServerSentEvent is executed, which serializes the information and sends the correct SSE format to clients.

Registering Services in Program.cs

For everything to work as expected, we must register in Program.cs the different instances that will interact in the Blazor application. This means creating a singleton instance of EventBroadcaster, so that all systems have access to the same bus. Similarly, we will register DemoEventGenerator as a background service, through the method AddHostedService. This will allow simulated events to be generated in the background continuously:

var builder = WebApplication.CreateBuilder(args);
...
builder.Services.AddSingleton<EventBroadcaster>();
builder.Services.AddHostedService<DemoEventGenerator>();

var app = builder.Build();
...

app.MapSseEndpoints();

app.Run();

In the previous code, in addition to registering the services, MapSseEndpoints is invoked to enable SSE communication in the project.

Creating the Blazor Application

Once we have the application infrastructure ready, it’s time to move on to the UI part. At this point, let’s start by creating a JavaScript client, because the standard requires using the browser’s EventSource API. Since the project is configured as InteractiveServer, we cannot add inline script tags. To work around this, I will add a new file inside the wwwroot/js folder called sse-demos.js:

//1.
let eventFeedSource = null;

2.
export function start(dotNetRef) {
    // 3.
    if (eventFeedSource) eventFeedSource.close();

//4.
    const src = new EventSource('/sse/events');

    // 5.
    src.addEventListener('app-event', function (e) {
        dotNetRef.invokeMethodAsync('OnEventReceived', JSON.parse(e.data));
    });

    // 6.
    src.onopen = function () { dotNetRef.invokeMethodAsync('OnConnectionChanged', true); };
    src.onerror = function () { dotNetRef.invokeMethodAsync('OnConnectionChanged', false); };

    eventFeedSource = src;
}

//7.
export function stop() {
    if (eventFeedSource) {
        eventFeedSource.close();
        eventFeedSource = null;
    }
}

The previous code does the following:

1. A variable eventFeedSource is created to keep information about whether there is an active connection with the server.
2. A function named start should be called from C# code when you want to start receiving information…
3. It checks whether there is an open connection, in which case it is closed.
4. It tells the browser to connect to /sse/events and to listen for all events that the server sends.
5. It filters events named app-event.
6. We subscribe to the events onopen and onerror. Each will notify the method OnConnectionChanged about a change in the connection, which will allow showing a different state in the Blazor UI.
7. The function stop should be invoked to clean up memory when we want to close the connection.

With the JS functions ready, the next step is to create the Blazor component. In this new component we will use a Blazor Data Grid type component, because it is a highly configurable component that has built-in options to filter, group, etc., ideal for quickly obtaining information about events in the different systems.

To do the above, we will create a component called EventFeed.razor, which looks as follows:

@page "/events"
@rendermode InteractiveServer
@inject IJSRuntime JS
@implements IAsyncDisposable

<PageTitle>Live Event Feed</PageTitle>

<h1 class="mb-4">Live Event Feed</h1>

<div class="card shadow-sm">
    <div class="card-header d-flex align-items-center justify-content-between py-2">
        <div class="d-flex align-items-center gap-3">
            @if (isStreaming)
            {
                <span class="badge rounded-pill @(isConnected ? "bg-success" : "bg-secondary") fs-6">
                    <span class="me-1">⬤</span>@(isConnected ? "Connected" : "Disconnected")
                </span>
            }
            else
            {
                <span class="badge rounded-pill bg-warning text-dark fs-6">
                    <span class="me-1">⏸</span>Paused
                </span>
            }
            <span class="text-muted">
                Events received: <strong class="text-dark">@totalEventsReceived</strong>
            </span>
        </div>
        <div class="d-flex gap-2">
            <TelerikButton OnClick="ToggleStreaming"
                           ThemeColor="@(isStreaming ? ThemeConstants.Button.ThemeColor.Primary : ThemeConstants.Button.ThemeColor.Success)">
                @(isStreaming ? "⏸ Pause" : "▶ Resume")
            </TelerikButton>
            <TelerikButton OnClick="ClearGrid" ThemeColor="@ThemeConstants.Button.ThemeColor.Light"> Clear</TelerikButton>
        </div>
    </div>
    <div class="card-body p-0">
        <TelerikGrid Data="@events"
                     Height="560px"
                     Sortable="true"
                     Resizable="true"
                     Reorderable="true"
                     Groupable="true"                     
                     ShowColumnMenu="true">
            <GridColumns>
                <GridColumn Field="@nameof(AppEvent.Time)" Title="Time" Width="110px" />
                <GridColumn Field="@nameof(AppEvent.Level)" Title="Level" Width="120px">
                    <Template>
                        @{
                            var item = (AppEvent)context;
                        }
                        <span class="badge rounded-pill @GetBadgeClass(item.Level) px-3 py-2">@item.Level</span>
                    </Template>
                </GridColumn>
                <GridColumn Field="@nameof(AppEvent.Source)" Title="Source" Width="140px" />
                <GridColumn Field="@nameof(AppEvent.Message)" Title="Message" />
            </GridColumns>
        </TelerikGrid>
    </div>
</div>

@code {
    private List<AppEvent> events = new();
    private bool isConnected;
    private bool isStreaming = true;
    private int totalEventsReceived;
    private DotNetObjectReference<EventFeed>? dotNetRef;
    private IJSObjectReference? jsModule;
    private bool _jsInitialized;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            dotNetRef = DotNetObjectReference.Create(this);
                       
            jsModule = await JS.InvokeAsync<IJSObjectReference>("import", "./js/sse-demos.js");
                        
            await jsModule.InvokeVoidAsync("start", dotNetRef);
            
            _jsInitialized = true;
        }
    }

    [JSInvokable]
    public void OnEventReceived(AppEvent appEvent)
    {
        totalEventsReceived++;
        var updated = new List<AppEvent>(events);
        updated.Insert(0, appEvent);
        if (updated.Count > 50)
            updated.RemoveRange(50, updated.Count - 50);
        events = updated;
        InvokeAsync(StateHasChanged);
    }

    [JSInvokable]
    public void OnConnectionChanged(bool connected)
    {
        isConnected = connected;
        InvokeAsync(StateHasChanged);
    }

    private async Task ToggleStreaming()
    {
        isStreaming = !isStreaming;
        
        if (jsModule is not null)
        {
            if (isStreaming)
                await jsModule.InvokeVoidAsync("start", dotNetRef);
            else
                await jsModule.InvokeVoidAsync("stop");
        }
    }

    private void ClearGrid()
    {
        events = new List<AppEvent>();
        StateHasChanged();
    }

    private string GetBadgeClass(string level) => level switch
    {
        "Info" => "bg-info text-dark",
        "Warning" => "bg-warning text-dark",
        "Error" => "bg-danger",
        "Success" => "bg-success",
        _ => "bg-secondary"
    };

    public async ValueTask DisposeAsync()
    {
        if (_jsInitialized && jsModule is not null)
        {
            try
            {                
                await jsModule.InvokeVoidAsync("stop");
                                
                await jsModule.DisposeAsync();
            }
            catch
            {                
            }
        }
        dotNetRef?.Dispose();
    }

    public class AppEvent
    {
        public int Id { get; set; }
        public string Time { get; set; } = string.Empty;
        public string Level { get; set; } = string.Empty;
        public string Source { get; set; } = string.Empty;
        public string Message { get; set; } = string.Empty;
    }
}

In the previous code, there are some points to highlight:

• jsModule dynamically loads the JS module.
• The variable dotNetRef wraps the instance of the Blazor component that we will use inside the JS code.
• The method InvokeVoidAsync is used both to start and to stop the event streaming.
• The method OnEventReceived is invoked from the JS code each time an event is received. This allows updating the list events to show the new information in TelerikGrid.
• The OnConnectionChanged method receives a connection status from the JS code to update the UI according to any change in the connection.

With the new component ready, we can test the application, which looks like the following:

With this, we verify that everything works correctly. Also, thanks to the Blazor DataGrid capabilities, we can perform operations such as monitoring only those high-severity events:

With this we have a nice event viewer that monitors the status of multiple fictitious systems.

Conclusion

Throughout this article you have learned about the SSE standard. You have also seen how changes introduced in .NET 10 help simplify the creation of SSE endpoints, enabling the creation of applications that send real-time events to clients. Now it’s your turn to explore when you might use this web standard in your own projects. See you in the next article!

Try all this yourself with a free 30-day trial of Telerik UI for Blazor.

Try Now