There are currently two ways to load data from the server and hydrate it. Nuxt has Server Components, just like React, as well as fetch mechanisms API route hydration.

TL;DR

This app will load data from the server in a Server Component and using useFetch. Both mechanisms work similarly from the server perspective, but one method hydrates data from the server and sets it as reactive, while the other caches data from the server. Both components can be validated with schema.org to verify the data is properly loaded.

Nuxt Setup

We must properly config the layout and components.

Configure Tailwind

Follow the Nuxt 4 Tailwind Guide for the latest instructions.

Nuxt Config

Make sure to enable component islands with deep selective client. This enables server components and client components inside of them. For more on Nuxt Server Components, see my other article Nuxt 3 Server Components Rock.

import tailwindcss from "@tailwindcss/vite";

export default defineNuxtConfig({
  compatibilityDate: "2025-07-15",
  devtools: { enabled: true },
  css: ['./app/assets/css/main.css'],
  experimental: {
    componentIslands: {
      selectiveClient: 'deep',
    },
  },
  vite: {
    plugins: [
      tailwindcss(),
    ],
  },
});

Configure app/app.vue for Pages and Layouts

<template>
  <NuxtLayout>
    <NuxtPage />
  </NuxtLayout>
</template>

Configure the Layout at app/layouts/default.vue

<template>
  <div class="flex flex-col items-center gap-4 p-10">
    <slot />
    <nav class="flex gap-4">
      <NuxtLink to="/" active-class="font-bold" exact-active-class="font-bold">
        Home
      </NuxtLink>
      <NuxtLink
        to="/server"
        active-class="font-bold"
        exact-active-class="font-bold"
      >
        Server Component
      </NuxtLink>
      <NuxtLink
        to="/fetch"
        active-class="font-bold"
        exact-active-class="font-bold"
      >
        Fetch
      </NuxtLink>
    </nav>
  </div>
</template>

This allows bolded current routes.

Homepage at app/pages/index.vue

<template>
  <div class="border p-4 rounded-xl">
    Welcome to the Server Components VS Fetch demo!
  </div>
</template>

Validate Component at app/components/validate.vue

This is used to create a dynamic link to schema.org.

 <script lang="ts" setup>
const currentUrl = useRequestURL();

const href = computed(
  () =>
    `https://validator.schema.org/#url=${encodeURIComponent(currentUrl.href)}`,
);
</script>

<template>
  <a class="underline hover:no-underline" :href>Test Schema</a>
</template>

Notice useRequestURL() can get the current URL safely.

Meta Data and Schema

Nuxt has a built-in composable, useHead, that allows you to set data directly in the header on the server.

useHead({
  meta: [
    {
      property: "article:modified_time",
      content: modifiedTime.data.value,
    },
    {
      name: "last-modified",
      content: modifiedTime.data.value,
    },
  ],
  script: [
    {
      type: "application/ld+json",
      textContent: () =>
        JSON.stringify({
          "@context": "https://schema.org",
          "@type": "WebPage",
          dateModified: modifiedTime.data.value,
        }),
    },
  ],
});

You can create a meta tag with the meta property, and set the data that you see fit. This is imperative for SEO. Modern search engines group data using JSON-LD and schema.org, which requires a formatted script tag.

The following examples will set the modified date as the fetch date. This is technically incorrect, as you would want this static, but you can see the usefulness of this for dynamically generated pages with good SEO techniques.

Fetch with useAsyncData

You can fetch data with useFetch if you have an endpoint, or useAsyncData if you just want to run a safe function directly on the server.

Basic Fetch Page at app/pages/fetch.vue

<template>Hello World! <Server-Time-Client /></template>

I love not having to manually import components in the components directory!

Here We Create app/components/server-time-client.vue

<script setup lang="ts">
const modifiedTime = await useAsyncData("time", async () => {
  return new Date().toISOString();
});

useHead({
  meta: [
    {
      property: "article:modified_time",
      content: modifiedTime.data.value,
    },
    {
      name: "last-modified",
      content: modifiedTime.data.value,
    },
  ],
  script: [
    {
      type: "application/ld+json",
      textContent: () =>
        JSON.stringify({
          "@context": "https://schema.org",
          "@type": "WebPage",
          dateModified: modifiedTime.data.value,
        }),
    },
  ],
});
</script>

<template>
  <div v-if="modifiedTime.data">Server time: {{ modifiedTime.data.value }}</div>
  <Validate />
</template>

• We don’t have to have client in the name, but it is good to differentiate in this example.
• With useAsyncData, we load data on the server and hydrate it to the browser keeping it reactive. We could have equally created an endpoint at server/api/time.ts and called it with useFetch.
• Your real data will probably be async and will pull from a database.

Server Component

We can also load the data directly in the HTML on the server, similar to PHP. It will NOT be reactive.

Basic Server Page at app/pages/server.vue

<template>Hello World! <Server-Time><Validate /></Server-Time></template>

We are loading a client component, validate, inside a server component. This is reactive and depends on the current URL. It must use a <slot /> to work correctly. This is why we enabled deep in nuxt.config.ts. Again, see Nuxt 3 Server Components Rock.

Server Time Component at app/components/server-time.server.vue

<script setup lang="ts">
const modifiedTime = new Date().toISOString();

useHead({
  meta: [
    {
      property: "article:modified_time",
      content: modifiedTime,
    },
    {
      name: "last-modified",
      content: modifiedTime,
    },
  ],
  script: [
    {
      type: "application/ld+json",
      textContent: () =>
        JSON.stringify({
          "@context": "https://schema.org",
          "@type": "WebPage",
          dateModified: modifiedTime,
        }),
    },
  ],
});
</script>

<template>
  <div class="flex flex-col gap-4 items-center">
    <div>Server time: {{ modifiedTime }}</div>
    <slot />
  </div>
</template>

• A Server Component must have the .server.ts extension to load correctly.
• We can just put our server code directly in the header. None of the JavaScript gets loaded in the browser for this component.

Comparison

So what is the difference?

Generally speaking, Fetch Composables can be reactive and load JavaScript. Server Components just load the data as if it were static HTML. This is clear when you navigate between pages, the Server Component does not reload the date, while the Fetch Component does.

Testing Schema

You can click the test schema button to verify the data is loaded from the server and not client, and that it loads correctly.

If you’re loading something quickly, use Server Components. If you need dynamic data, use Fetch Composables.

That’s a wrap!

Repo: GitHub
Demo: Vercel

We as developers use AI tools like Cursor, Claude Code and Copilot; they have changed how we write code. We delegate entire sections of our applications to an agent, and for many tasks, this works really well.

But when it comes to building user interfaces with a specific framework, things get complicated fast. Results are unpredictable, the code feels incomplete and we end up spending more time fixing than building.

If you have felt that, you are not alone. The good news is that the problem is not the AI. The problem is how we are using it.

We will see why AI struggles with UI development and how a new approach called “component-aware AI” changes everything. But first, let’s understand what is really missing.

The Problem

In the world of AI, we read about context all the time, which is the key problem when things go wrong. When you ask your AI assistant to use a component from a specific framework, it relies on its training data. It does not know:

• The exact version of Angular you are using
• The best practices for your library
• The specific design rules of your organization

Do you want to learn more about the context problem?

So the AI starts guessing. And that guessing creates real problems:

• High costs and effort: We waste many tokens just explaining our UI library to the AI. We end up copying and pasting manuals, providing code examples and fixing mistakes, making the whole process slow and expensive.
• The “fix and repeat” loop: We copy the code, find a small bug, ask the AI to fix it and repeat the cycle.
• Low-quality code: The code the AI gives us is often incomplete or outdated. We spend more time fixing it than it would have taken to write it from scratch.

But we have good news: using a new approach called “component-aware AI” changes everything.

The Shift to MCP

We need a new way for the AI to work. We need “component-aware AI.” This shift is made possible by the Model Context Protocol (MCP). Instead of the AI trying to remember code from its training data, it can read the live documentation of your library in real time.

Think of it like the difference between following a recipe from memory versus using a smart kitchen robot with everything preconfigured. It is automated, precise and much freer from errors.

When you use an MCP like the Progress Kendo UI for Angular MCP, the AI assistant queries the official library data before it writes any code. This verifies that every property and every method is correct.

The best way to understand the difference is to see it in action. I have experienced the shift from working with blind AI to giving agents the right tools to deliver code with confidence and without technical debt. Let’s do it!

Want to build your own MCP server? Check this out: https://www.youtube.com/watch?v=mM8T8bSCTyk

The Traditional Way (The “Blind” AI)

Let’s start with the scenario you probably already know.

Open your terminal and run these two commands to create the project and install the Kendo UI for Angular Grid:

# Create the project
ng new accounting-app --style=scss --ssr=false
 
# Install Kendo UI Grid
ng add @progress/kendo-angular-grid

Then, you ask your AI assistant (without specialized context) to build the interface:

Prompt: “Create a General Ledger grid with Kendo UI for Angular. Show Date, Description, Debit, and Credit. Add footer totals.”

The project compiles and runs, but the result is full of immediate technical debt. Here is what the AI generates:

// ❌ BLIND AI: Ignores Kendo built-in aggregation utilities
export class App {
 protected readonly ledgerItems: LedgerEntry[] = [...];
 
 // Manual logic the developer must maintain forever
 protected get totalDebit(): number {
   return this.ledgerItems.reduce((sum, item) => sum + item.debit, 0);
 }
 
 protected get totalCredit(): number {
   return this.ledgerItems.reduce((sum, item) => sum + item.credit, 0);
 }
}

Let’s look at the problems here. For totalDebit, if you add more columns with totals, you have to manually write a .reduce() for each one. The AI does not know that Kendo UI already has aggregateBy built in.

Another common inconsistency is with colors. Instead of using design tokens, it uses hard-coded values like #f5f7fb, which breaks visual coherence across the app.

The worst part is the lack of accessibility. There are no ARIA attributes or semantic roles, which Kendo UI handles automatically when configured correctly.

<!-- ❌ BLIND AI: Hardcoded color, no accessibility, no built-in features -->
<kendo-grid [data]="ledgerItems">
 <kendo-grid-column color="#f5f7fb" field="debit" title="Debit">
 </kendo-grid-column>
</kendo-grid>

In the end, you spend more time cleaning up AI code than you would have spent writing it from scratch. The real issue is that we are not giving the AI the right tools to perform at its best.

We can fix that, because the solution is simpler than you might think.

The Agentic Way: Using the Power of Kendo UI MCP

Now, let’s move to the productive workflow and combine the power of Kendo UI MCP with our agents.

Instead of the manual configuration and the “blind” approach, we start with a single command. Open your terminal and run:

npx kendo angular setup

Here is where the magic happens. It automatically installs the license and registers the Kendo UI MCP Server across your IDEs and AI agents (VS Code, Cursor, Claude Code). From this point on, your agent has full context and no longer has to guess.

Now we ask the same AI agent to build the same application with the same prompt. This time our agent, thanks to MCP, uses the Kendo UI Generator tool to generate the code.

Let’s look at the generated code and why it is production-ready.

// ✅ COMPONENT-AWARE AI: Uses Signals, Modern Angular Patterns, and Kendo's aggregateBy
import { aggregateBy, AggregateResult } from '@progress/kendo-data-query';
 
export class GeneralLedgerComponent {
 private ledgerService = inject(LedgerService);
 
 // Modern signal-based state
 protected ledgerEntries = signal<LedgerEntry[]>(this.ledgerService.getLedgerEntries());
 
 // Kendo's aggregateBy handles all column totals in one call, no manual .reduce() needed
 protected totals = computed<AggregateResult>(() =>
   aggregateBy(this.ledgerEntries(), [
     { field: 'debit', aggregate: 'sum' },
     { field: 'credit', aggregate: 'sum' },
   ])
 );
}

The AI now uses Signals (signal, computed) and proper dependency injection (inject), which are the recommended modern Angular patterns. And instead of a manual .reduce() per column, it uses Kendo UI aggregateBy. Add a new column with a total, and you just add one line to the array, nothing else.

In the SCSS file, instead of hard-coding colors, it uses official Kendo UI Design Tokens such as var(--kendo-color-surface-alt) and var(--kendo-color-success).

And in the template, the difference is clear:

<!-- ✅ COMPONENT-AWARE AI: Design tokens, accessibility, full features enabled -->
<kendo-grid
   [data]="ledgerEntries()"
   [reorderable]="true"
   [navigable]="true"
   role="table"
   aria-label="General Ledger Entries"
>
</kendo-grid>

That is the key difference. When we use Kendo UI for Angular MCP, our agents do not just generate code. They generate the right code, follow best practices and deliver to a high standard.

Here are the three benefits I value most:

1. Significantly reduced hallucinations: The AI does not guess property names. It reads the actual documentation in real time.
2. Accessible by default: Kendo UI components are built to follow accessibility standards. When the AI uses these components correctly, your app is automatically inclusive.
3. Token efficiency: No more copying large lines of documentation into your chat. The AI fetches only what it needs, saving you tokens and money.

Go deeper and explore everything that Kendo UI MCP can do.

Now that we have seen both worlds side by side, let’s talk about what this really means for how we choose our tools going forward.

Conclusion

Simply using AI is not enough. And simply using a component library is not enough anymore, either.

This is the paradigm shift. We are moving from a world where a library just gives you components to one where a library also provides the context layer that makes modern development possible. Kendo UI MCP is exactly that: it acts as a bridge between your agents and the library so that the AI can do its job properly rather than guessing.

By bridging that context gap, we move from “guessing” to “knowing” and agents stop hallucinating APIs and start delivering production-ready code.

My personal take: Next time you evaluate a UI library, do not just look at the component catalog. Ask if your framework has the tools for the way we build software today. Because that is the question I ask myself now, every time.

BTW, if you want to work less and ship more, it is time to make your agents work for you so you can focus on building what really matters.

Resources

• Kendo UI for Angular
• MCP Protocol: Learn more about MCP

Try Now

Remember, Kendo UI for Angular comes with a free 30-day trial, so you can explore all these goodies yourself.

Try Now

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

TL;DR:

• Free libraries are great early
• They break at scale
• The cost becomes engineering time, not just licensing
• That’s when teams start evaluating alternatives

The challenge isn’t the license cost.

The real cost of free UI libraries shows up later—in engineering time, maintenance overhead, and the effort required to make everything work together at scale.

Free UI libraries work great… until they don’t.

And when they start breaking, it’s rarely obvious at first. Many teams outgrow them without realizing it—until things start slowing down.

Free and open-source UI libraries are a natural starting point for many React projects. They’re familiar, community-driven and come with zero upfront cost. For prototypes, MVPs and simpler applications, they often work exactly as expected.

However, as products grow, their limitations tend to surface gradually. A data grid that handled a few hundred rows starts to slow down at scale. A dependency becomes unmaintained. Different UI pieces begin to behave inconsistently. Similar cracks can appear across other foundational components.

In this article, we’ll explore the signs that your project may have outgrown free UI libraries and how to evaluate whether it’s time to consider a more comprehensive solution.

When Free UI Libraries Make Sense

It’s important to note that free UI libraries can be genuinely useful. Libraries like React Bootstrap, Radix and Headless UI have made it easier for developers to build interfaces quickly. They lower the barrier to entry, provide solid defaults and benefit from large communities of contributors who improve them over time.

For prototyping, MVPs and projects where the component requirements are straightforward, free libraries are often the most practical choice. There’s no procurement process, no license to manage and the ecosystem familiarity means new team members can ramp up quickly.

The challenge arises when the project scales, whether in terms of data volume, feature complexity or team size. The limitations that didn’t matter at 500 users start to surface at 50,000, and at that point we may need to take additional steps to extend or replace UI components rather than expecting them to scale with us.

Performance at Scale

One of the first places teams feel the strain is performance. A table component that renders a few hundred rows without issue can become a bottleneck when the data grows into the thousands or tens of thousands. This is a common scenario in enterprise applications where dashboards, admin panels and reporting tools need to handle very large datasets.

To go into a bit more detail, many free table and grid components render all rows into the DOM at once. When the dataset is small, this is fine, but with very large datasets, users can experience noticeable lag and slow scroll performance.

// A basic table rendering all rows directly
const BasicTable = ({ data }) => {
  return (
    <table>
      <thead>
        <tr>
          <th>Name</th>
          <th>Email</th>
          <th>Status</th>
        </tr>
      </thead>
      <tbody>
        {data.map((row) => (
          <tr key={row.id}>
            <td>{row.name}</td>
            <td>{row.email}</td>
            <td>{row.status}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
};

In the above basic example, once the dataset reaches 5,000 or 10,000 entries, the browser is rendering thousands of DOM nodes simultaneously. This causes scrolling to slow down, filtering to become sluggish and the overall user experience to degrade.

To address this, teams typically need to implement features like row virtualization, which only renders the rows currently visible in the viewport. Building this from scratch or layering it on top of a free component that wasn’t designed for it is where the engineering cost starts to compound. We might leverage a third-party library like react-virtualization, or we might end up managing a container ref, a ResizeObserver, absolute positioning and scroll offset calculations ourselves.

// pseudo-code
const parentRef = useRef(null);

const virtualizer = useVirtualizer({
  count: data.length,
  getScrollElement: () => parentRef.current,
  estimateSize: () => 36,
  overscan: 5,
});

return (
  <div ref={parentRef} style={{ height: "500px", overflow: "auto" }}>
    <div style={{ height: virtualizer.getTotalSize(), position: "relative" }}>
      {virtualizer.getVirtualItems().map((virtualRow) => (
        <div
          key={virtualRow.key}
          style={{
            position: "absolute",
            top: 0,
            transform: `translateY(${virtualRow.start}px)`,
            height: `${virtualRow.size}px`,
          }}
        >
          {data[virtualRow.index].name}
        </div>
      ))}
    </div>
  </div>
);

This is just for a concept like row virtualization. We still need to layer on sorting, filtering, grouping, column pinning and keyboard navigation. Each of those features introduces its own state management, edge cases and regression risk. What started as a simple table becomes an internal platform project. At this point, the problem is no longer just performance. It’s the engineering time required to implement, test, and maintain these solutions on top of tools that weren’t designed for them.

What This Looks Like with KendoReact

The React Data Grid in the Progress KendoReact component library is built for exactly this scenario. Virtual scrolling (i.e., row virtualization) is enabled by default, meaning the Grid only renders visible rows plus a small buffer. It handles millions of records with constant memory usage, maintains 60 fps scroll performance and keeps the DOM lightweight regardless of dataset size.

Column virtualization is also available for datasets with many columns, rendering only the columns visible during horizontal scrolling.

Instead of wiring all of this ourselves, our Grid setup can look as simple as this:

<Grid
  data={data}
  autoProcessData={{
    filter: true,
    sort: true,
    group: true,
    page: true,
  }}
  filterable
  sortable
  groupable
  pageable
/>

Sorting, filtering, grouping and paging are all handled through the autoProcessData prop. No manual state wiring and no glue code between separate virtualization, sorting and filtering libraries. With regards to performance, here’s a visual example of how the grid behaves when loading and scrolling within a million+ records:

You can test the performance of the KendoReact Data Grid in the Performance | KendoReact Data Grid documentation.

Beyond tables, similar performance ceilings can show up in complex components like schedulers, tree views and charts when the volume of data or the complexity of interactions increases.

Maintenance Risk and the Support Gap

Fully open-source projects are maintained by people, and people have lives outside of code. Maintainers change jobs, experience burnout, shift their focus to new projects or simply move on. This is completely understandable and is not a criticism of the open-source community, but it is a risk that teams need to account for.

With the emergence of AI, open-source maintainers now face an additional burden: a growing flood of AI-generated pull requests and bug reports that consume their limited time and energy, as this real GitHub comment from an AI agent illustrates.

We’ve all opened a GitHub repository that looks healthy at first glance, with thousands of stars and active discussions. Then we notice the last meaningful commit was over a year ago. If the library sits at the core of our UI, the options aren’t ideal: we can wait and hope it gets attention again, or we can fork it and take on maintenance ourselves.

This risk compounds when something goes wrong in production. With free libraries, the support path typically looks like this: search GitHub Issues (or create our own), post a question on Stack Overflow or dig through the source code ourselves. These are all viable approaches, but none of them come with a guaranteed response time. Over time, this becomes ongoing maintenance overhead—time spent tracking issues, adapting to breaking changes or maintaining internal forks instead of building product features.

Commercial UI libraries like KendoReact change both sides of this equation. They have dedicated engineering teams whose job is to maintain, update and improve the components. Release schedules are predictable, breaking changes are documented and there’s an organizational commitment to long-term support. When we open a support ticket, a team that knows the codebase intimately is responsible for helping us resolve the issue. This doesn’t eliminate debugging entirely, but it significantly reduces the time spent on problems that originate outside our own code.

The Integration Tax

A less obvious cost of relying on free libraries is what we might call the integration tax. No single free library covers every component a modern application needs, so teams often end up pulling from multiple sources. A date picker from one library, a data grid from another, form components from a third, a modal dialog from yet another.

Each of these libraries has its own API patterns, styling approach and theming mechanism. Keeping them all compatible requires effort that isn’t always visible in sprint planning.

// The import sprawl of mixing multiple UI libraries
import { DatePicker } from "react-datepicker-lib";
import { DataGrid } from "another-grid-lib";
import { Modal } from "yet-another-modal-lib";
import { Select } from "some-select-lib";
import { Tabs } from "a-tabs-package";
import { Tooltip } from "tooltip-library-xyz";

// Each with its own:
// - Styling system (CSS modules, styled-components, plain CSS, Tailwind)
// - Event handling patterns
// - TypeScript type definitions (or lack thereof)
// - Breaking change policies

This illustrates the integration tax: the hidden engineering effort required to make multiple tools behave like a cohesive system, and to keep them that way over time.

The above is a very simplified illustration, but the pattern can be understood. When different UI packages and tooling each have their own way of handling themes, events and styling, the glue code needed to make them work together becomes maintenance of its own.

A comprehensive enterprise-ready React UI library, by comparison, provides a single API surface, a unified theming system and components that are designed to work together from the start. The date picker, the grid, the forms, the dialogs, the scheduler are all built by the same team, tested together and styled consistently.

Accessibility and Compliance at Scale

Accessibility is increasingly moving from a “nice to have” to a legal requirement. The European Accessibility Act, which went into effect on June 28, 2025, makes accessibility legally required for digital products used in the EU. In the United States, accessibility lawsuits continue to rise, targeting businesses of all sizes.

Many free UI libraries include some level of accessibility support, but the depth and consistency of that support vary widely. ARIA attributes might be present on some components but missing on others. Keyboard navigation might work for basic interactions, but break down in more complex flows and screen reader support might be untested or incomplete.

For teams that need to meet WCAG 2.2 or WCAG 2.1 compliance, this means auditing every component, identifying gaps and writing custom code to fill them. That audit and remediation process can be substantial, especially when dealing with complex interactive components like grids, trees and menus, where the accessibility requirements are non-trivial.

Commercial UI libraries that treat accessibility as a first-class concern build it into the component architecture from the beginning. This includes proper ARIA roles and attributes, keyboard navigation, focus management, high-contrast theme support and screen reader compatibility across components.

The cost of getting this right is absorbed by the library team rather than being passed on to every application team that uses the components. For KendoReact, as an example, accessibility compliance is a strategic and ongoing commitment.

When Do We Outgrow Free UI Libraries?

Free UI libraries serve an important role in the React ecosystem. They lower barriers, accelerate early development and provide solid building blocks for countless projects. Choosing them at the start of many projects can be the right decision.

KendoReact also includes a Free tier with 50+ production-ready React components available for use without a license.

However, projects evolve, and tools that worked well at one stage can become sources of friction at another. You may have outgrown free UI libraries if:

• You’re spending time implementing features like virtualization or complex state handling yourself.
• You’re maintaining forks of third-party components.
• You’re integrating multiple libraries with different APIs and styling systems.
• Accessibility or compliance requires additional engineering effort.
• Fixing UI issues depends on external maintainers or community responses.

The question isn’t whether free libraries are good or bad. It’s whether the total cost of using them, including developer time for workarounds, is still better than the alternative. Teams shifts from asking “Why pay for UI components?” to “What is the cost of continuing to build and maintain this ourselves?”

For teams that have reached that stage, it’s worth stepping back and evaluating the options more deliberately, including what a more integrated, enterprise-ready approach can offer in terms of performance, consistency and long-term reliability. This is where robust professional libraries like KendoReact step in, offering production-ready components, built-in performance optimizations, and a unified system that reduces the need for custom integrations and ongoing maintenance work.

For additional details on KendoReact and what it offers, check out the following resources:

• KendoReact Examples & Demos
• KendoReact Accessibility
• KendoReact Data Grid Performance
• KendoReact ThemeBuilder

Managing access across growing development teams can quickly become time-consuming when done manually.

That’s why we’re introducing System for Cross-domain Identity Management (SCIM) for Progress DevCraft Complete and DevCraft Ultimate subscription licenses, along with Fiddler and ThemeBuilder Enterprise licenses—bringing automated license seat management directly into your organization’s Identity Provider.

If SSO simplified how your team signs in, SCIM extends that experience by automating how access is assigned and maintained.

If you haven’t set up SSO yet, follow the steps in our SSO guide.

What Is SCIM and Why It Matters

For customers using DevCraft Complete and Ultimate subscription licenses, as well as Fiddler and ThemeBuilder Enterprise licenses, SCIM allows license access to be managed directly through your organization’s Identity Provider (IdP), such as Microsoft Entra ID or Okta.

Instead of managing users separately in Telerik, access becomes part of your existing internal processes. When developers are assigned to the right group in your IdP, they automatically receive access to their DevCraft subscription. When they are removed, their access is updated accordingly.

This helps organizations:

• Keep license access aligned with internal systems
• Eliminate manual seat management
• Reduce the risk of unused or outdated assignments

Your Identity Provider becomes the single place to manage access to your licenses.

How to Set It Up

SCIM builds on top of SSO and is designed to be quick to configure.

1. Enable SSO

SCIM requires SSO to be already configured for your domain.

If you haven’t enabled it yet, follow the steps in our SSO guide.

2. Open SCIM Setup in Your Telerik Account

• Go to Manage SSO and SCIM in your Telerik account.
• Click on SCIM Setup.

3. Generate Your SCIM Key

In the SCIM Setup screen:

• Copy the SCIM URL and use it when configuring your Identity Provider.
• Add a Key Note that should help differentiate your keys in the future.
• Generate and copy the SCIM API key and Finish Setup

⚠️ Important: Please copy the key, as once the setup is complete, you will no longer have access to the full key.

The generated SCIM API Key will be used as a Bearer authentication token in your IdP.

4. Configure SCIM in Your Identity Provider

This step connects your Identity Provider with Telerik, allowing it to send user and group updates automatically.

In your Identity Provider (for example, Okta):

• Add the Telerik SCIM URL.
• Use the generated API key for authentication.

• Enable provisioning—verify the Create, Update and Deactivate are enabled.

5. Map Your DevCraft License to Your IdP Group

In Manage SSO & SCIM in Your Account:

• Identify your DevCraft Complete or Ultimate subscription license that you want to enable the SCIM feature, and click on Configure.
• Enable SCIM Provisioning.
• Copy the IdP Group Identifier and Apply.

From this point on, access is controlled through group membership.

• Use the IdP Group Identifier to create a group with the same name in your IdP Provider and assign that group to the SCIM App. Optionally, add a group description as a human-readable name in the IdP.

• You can start adding users to the IdP group. For a start, if there are already seated users on the Telerik side, add those users to the IdP group as well. From there on, any IdP group change will be reflected on the Telerik side.

6. Verify User Synchronization

After completing the setup, you can verify that the configuration is correct and that users are syncing as expected from the Licensed Users view.

• Users added to the mapped IdP group will start appearing automatically.
• Existing users (with Telerik accounts) should show as Assigned, and can continue signing in via SSO as before.
• New users (without a Telerik account) will appear with an Invited status. They will receive an email invitation. They need to complete their account setup on their first login.

This handles both new and existing users seamlessly.

What Happens After SCIM Is Enabled?

Once SCIM is enabled for your license, access management becomes fully automated.

User access is driven entirely by group membership in your Identity Provider, while Telerik reflects those changes automatically. New users are guided through a simple onboarding experience at login, and the Licensed Users view becomes read-only for visibility and reporting.

There’s no need to manually manage seats in Telerik.-Your Identity Provider handles all updates.

Bring Automated Access to Your Telerik Licenses

SCIM makes it easier to manage access to your licenses by extending your existing identity management into license management.

Once combined with SSO, it provides a smooth experience where both authentication and access are handled together—directly from your Identity Provider.

Whether you’re looking to reduce manual work, keep access aligned with your organization or scale more efficiently as your team grows, SCIM is designed to help you get there!

Head to the Manage SSO and SCIM page now to get started.

If you’ve ever created an API in ASP.NET Core using the classic approach of dividing it into Controllers, Services and Repositories, you’ve probably faced some difficulties in creating the necessary structure. With each new feature, more files are scattered, more cross-dependencies appear, and it becomes more difficult to understand what truly belongs to each use case.

But what if, instead of organizing the code by technical layers, you organized it by system functionalities? That’s exactly what Vertical Slice Architecture proposes.

Instead of a giant folder for Services and another for Repositories, each functionality becomes a vertical “slice” of the system, containing everything it needs: endpoint, business rules, validations, DTOs and data access. Each request then has its own isolated flow.

In this post, we’ll explore Vertical Slice Architecture and how to apply it in a practical ASP.NET Core project.

Layered Architecture and Its Trade-offs

Layered Architecture is one of the best-known and most widely used architectural styles in enterprise software development. It’s commonly found in ASP.NET Core, Java/Spring and other enterprise platforms. The main point of this style is that it organizes the system into horizontal layers, each with well-defined responsibilities.

The classic architecture typically divides the system into four main layers (despite variations):

1. Presentation (UI / API): Controllers, endpoints, user interfaces
2. Application / Service: Orchestrates use cases
3. Domain / Business: Business rules
4. Infrastructure / Data Access: Database, external integrations, files, etc.

Each layer depends only on the layer immediately below it (or on abstractions), creating a predictable flow of dependencies.

Despite its popularity, this approach has some drawbacks, such as flow coupling. Although the layers are separate, use cases traverse all of them: Controller -> Service -> Domain -> Repository -> Database. This creates structural flow coupling.

A simple change in one use case can require changes in multiple layers. This results in scattered files and constant navigation between projects/folders to find important parts of the code.

Another negative point is that this architecture organizes code by technical type, not by functionality. For example, if you want to understand the “Create Order” use case, you will need to open multiple files in different folders (Controllers, Services folder, Repositories folder, etc.).

When can Layered Architecture start to become a problem? In large systems with many use cases, a high volume of changes per feature, a complex domain that requires strong modeling, and large teams working on multiple fronts. In scenarios like this, an excellent alternative is Vertical Slice Architecture.

Vertical Slice Architecture as an Alternative

Vertical Slice Architecture is an architectural style where the system is designed and organized by features (functionalities), rather than by technical layers as in traditional layer-based approaches.

Vertical Slice emerged as an alternative to problems with traditional approaches, such as the difficulty in maintenance due to classes being scattered throughout the program.

The proposal of Vertical Slice is simple: organize the code by functionality (feature) and not by technical type. Imagine you need to create functionalities for creating and canceling an order.

In a layered approach, we would have the standard structure:

Controller 
- OrderController 
Service 
- OrderService
Repository 
- OrderRepository
Dtos 
- OrderDto

In a Vertical Slice Architecture, you would organize things by use case:

Features/
CreateOrder/
CreateOrderEndpoint.cs
CreateOrderHandler.cs
CreateOrderRequest.cs
CreateOrderValidator.cs

CancelOrder/
CancelOrderEndpoint.cs
CancelOrderHandler.cs
CancelOrderRequest.cs
CancelOrderValidator.cs

Much clearer now, isn’t it? The image below shows a simple comparison between Vertical Slice Architecture and Layered Architecture:

Implementing Vertical Slice Architecture

Now we’re going to create an API using Vertical Slice Architecture. Our API will be used to manage a subscription service. You can access the complete code in this GitHub repository: Vertical Slice Subs Source Code.

Our project will follow this structure:

Creating the Domain Model

To create the base application, you can use the following command in the terminal:

dotnet new web -o SubscriptionManagement

Then, inside the project, create a new folder called “Features,” and inside it another folder called “Subscriptions”. Add the following class and enum to the folder Subscriptions:

namespace SubscriptionManagement.Features.Subscriptions;

public class Subscription
{
    public Guid Id { get; private set; } = Guid.NewGuid();
    public string ServiceName { get; private set; } = default!;
    public decimal Price { get; private set; }
    public DateOnly StartDate { get; private set; }
    public DateOnly? TrialEndsAt { get; private set; }
    public SubscriptionStatus Status { get; private set; }

    private Subscription() { }

    public Subscription(string serviceName, decimal price, DateOnly startDate, DateOnly? trialEndsAt)
    {
        ServiceName = serviceName;
        Price = price;
        StartDate = startDate;
        TrialEndsAt = trialEndsAt;
        Status = SubscriptionStatus.Active;
    }

    public void Cancel()
    {
        if (Status == SubscriptionStatus.Canceled)
            throw new InvalidOperationException("Subscription already canceled.");

        Status = SubscriptionStatus.Canceled;
    }
}

namespace SubscriptionManagement.Features.Subscriptions;

public enum SubscriptionStatus
{
    Active = 1,
    Canceled = 2
}

The next step is to create the database related files. In the root of the project, create a new folder called “Infrastructure” and add the following class to it:

• AppDbContext

using Microsoft.EntityFrameworkCore;
using SubscriptionManagement.Features.Subscriptions;

namespace SubscriptionManagement.Infrastructure;

public class AppDbContext : DbContext
{
    public DbSet<Subscription> Subscriptions => Set<Subscription>();

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

Feature 1: CreateSubscription

Command

Our first feature will be used to create a new subscription. Inside the Features/Subscriptions/ folder, create a new folder called “CreateSubscriptions” (all the classes below should be created within this structure: Features/Subscriptions/CreateSubscriptions), and inside it, add the following record:

public record CreateSubscriptionCommand(
    string ServiceName,
    decimal Price,
    DateOnly StartDate,
    DateOnly? TrialEndsAt
);

Validator

Next, let’s create a validator. Create the class below:

using FluentValidation;

namespace SubscriptionManagement.Features.Subscriptions.CreateSubscriptions;

public class CreateSubscriptionValidator : AbstractValidator<CreateSubscriptionCommand>
{
    public CreateSubscriptionValidator()
    {
        RuleFor(x => x.ServiceName)
            .NotEmpty()
            .MaximumLength(100);

        RuleFor(x => x.Price)
            .GreaterThan(0);

        RuleFor(x => x.TrialEndsAt)
            .GreaterThan(x => x.StartDate)
            .When(x => x.TrialEndsAt.HasValue);
    }
}

Handler

The concept of a Handler is common in projects that use Vertical Slice Architecture. A Handler is the component responsible for executing the application’s use case—that is, it contains the logic of the functionality.

Typically, the Handler is the class or function that receives a command or query and executes the corresponding operation, coordinating business rules, database access, calls to other services and response return.

Handlers work well in architectures that use Command Query Responsibility Segregation (CQRS), especially when using MediatR. Here, the concept doesn’t depend on MediatR; it already exists simply with the organization by slices.

Now, let’s create our first Handler. To do this, create the classes below:

namespace SubscriptionManagement.Features.Subscriptions.CreateSubscriptions;

public record CreateSubscriptionCommand(
    string ServiceName,
    decimal Price,
    DateOnly StartDate,
    DateOnly? TrialEndsAt
);

using SubscriptionManagement.Infrastructure;

namespace SubscriptionManagement.Features.Subscriptions.CreateSubscriptions;

public static class CreateSubscriptionHandler
{
    public static async Task<IResult> Handle(CreateSubscriptionCommand command, AppDbContext dbContext)
    {
        var subscription = new Subscription(
            command.ServiceName,
            command.Price,
            command.StartDate,
            command.TrialEndsAt
        );

        dbContext.Subscriptions.Add(subscription);
        await dbContext.SaveChangesAsync();

        return Results.Created($"/subscriptions/{subscription.Id}", subscription);
    }
}

Note that the handler class has a method to create a new subscription, and returns an HTTP Created status.

Endpoint

In Vertical Slice Architecture, it’s also common to declare separate endpoints. In this case, we’ll have one endpoint for each use case. Create the following class:

using FluentValidation;
using SubscriptionManagement.Infrastructure;

namespace SubscriptionManagement.Features.Subscriptions.CreateSubscriptions;

public class CreateSubscriptionEndpoint
{
    public static void Map(WebApplication app)
    {
        app.MapPost("/subscriptions", 
            async (CreateSubscriptionCommand command, 
                AppDbContext dbContext, 
                IValidator<CreateSubscriptionCommand> validator) =>
            {
                var validation = await validator.ValidateAsync(command);

                if (!validation.IsValid)
                    return Results.ValidationProblem(validation.ToDictionary());

                return await CreateSubscriptionHandler.Handle(command, dbContext);
            });
    }
}

Here we are defining an endpoint for creating a new subscription. It starts by validating the data, and if it’s valid, it uses the handler to create the new record and return the expected status.

Feature 2: CancelSubscription

The subscription creation flow is ready. Now let’s consider the cancellation use case. Following the same logic as before, within the Features/Subscriptions structure, create a new folder called CancelSubscriptions and add the following classes to that folder:

Command

namespace SubscriptionManagement.Features.Subscriptions.CancelSubscriptions;

public record CancelSubscriptionCommand(Guid Id);

Handler

using Microsoft.EntityFrameworkCore;
using SubscriptionManagement.Infrastructure;

namespace SubscriptionManagement.Features.Subscriptions.CancelSubscriptions;

public static class CancelSubscriptionHandler
{
    public static async Task<IResult> Handle(
        CancelSubscriptionCommand command,
        AppDbContext dbContext)
    {
        var subscription = await dbContext.Subscriptions
            .FirstOrDefaultAsync(x => x.Id == command.Id);

        if (subscription is null)
            return Results.NotFound();

        try
        {
            subscription.Cancel();
            await dbContext.SaveChangesAsync();
        }
        catch (InvalidOperationException ex)
        {
            return Results.BadRequest(new { error = ex.Message });
        }

        return Results.NoContent();
    }
}

Endpoint

using SubscriptionManagement.Infrastructure;

namespace SubscriptionManagement.Features.Subscriptions.CancelSubscriptions;

public static class CancelSubscriptionEndpoint
{
    public static void Map(WebApplication app)
    {
        app.MapDelete("/subscriptions/{id:guid}",
            async (Guid id, AppDbContext dbContext) =>
            {
                var command = new CancelSubscriptionCommand(id);
                return await CancelSubscriptionHandler.Handle(command, dbContext);
            });
    }
}

Program Class

The final step is to configure the Program class to use the endpoints we created above, to save time, we’ll use an in-memory database. So add the following code to the Program class:

using FluentValidation;
using Microsoft.EntityFrameworkCore;
using SubscriptionManagement.Features.Subscriptions.CancelSubscriptions;
using SubscriptionManagement.Features.Subscriptions.CreateSubscriptions;
using SubscriptionManagement.Infrastructure;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<AppDbContext>(opt =>
    opt.UseInMemoryDatabase("subscriptions-db"));

builder.Services.AddValidatorsFromAssemblyContaining<CreateSubscriptionValidator>();

var app = builder.Build();

CreateSubscriptionEndpoint.Map(app);
CancelSubscriptionEndpoint.Map(app);

app.Run();

Note that the Program class is quite simple, only creating configurations such as the use of the in-memory database, validations and the calling of the endpoint methods: CreateSubscriptionEndpoint.Map(app); and CancelSubscriptionEndpoint.Map(app);.

Testing the Application

Now, let’s run the endpoints and verify that the application is functional.

Run the application and make a POST request to the route http://localhost:5127/subscriptions using the JSON below as the body:

{
  "serviceName": "Aspflix",
  "price": 39.90,
  "startDate": "2026-03-01",
  "trialEndsAt": "2026-03-15"
}

If everything goes well, you will receive the following response in a debugger like Progress Telerik Fiddler Everywhere:

And to test the cancellation, simply execute a DELETE request to the route: http://localhost:5127/subscriptions/ID_HERE.

And you will receive the following response:

If you try to cancel again, you will receive a validation error.

Conclusion

Vertical Slice Architecture offers an alternative approach focused on system functionalities, rather than predefined structures.

As we saw in the article, this brings advantages such as ease of maintenance, due to the low cognitive requirements for understanding the project. It also offers agility in finding functions, as business rules are separated by use case. Furthermore, we implemented a subscription project in ASP.NET Core using Slice Architecture.

I hope this post helps you decide which architectural approach to use when creating or refactoring your projects.

If you have been building Vue applications for any amount of time, you’ve likely run into the same pattern over and over: call fetch or axios inside onMounted, store the result in a ref, manually track whether the request is loading, handle errors, and then figure out when and how to refetch the data when it goes stale. It works, but it doesn’t scale well, and it quickly becomes a mess of boilerplate scattered across your components.

In my previous article on Pinia state management, I mentioned TanStack Query as a powerful tool for managing asynchronous state that comes from your API. In this article, we’ll explore how to set it up in a Vue app, fetch data with useQuery, leverage automatic caching and control refetching behavior.

What Is TanStack Query?

TanStack Query (which curiously enough started as a React lib, React Query) is an async state management library that has since become framework-agnostic, with first class support for Vue. It is specifically designed to manage data that lives on your API and needs to be fetched, cached, synchronized and updated.

TanStack Query gives you out-of-the-box automatic caching, background refetching, request deduplication, loading and error states—all of this for free with the basic hands-off configuration.

It’s important to understand when to reach for TanStack Query vs. something like Pinia. Pinia is excellent for managing client state, things like UI preferences, form data, or any state that originates and lives entirely in the browser.

TanStack Query, on the other hand, shines when dealing with server state, data that comes from an API and that other users or processes could change at any time. They complement each other rather than compete.

Big disclaimer though: I highly recommend not mixing the two. I’ve yet to find a production grade application where I needed to use Pinia in conjuction with Tanstack. If you do end up needing both, make sure that you don’t overlap them. Keep your client and server data separate or it can become spaghetti code very quickly.

Setting Up TanStack Query

Setting up TanStack Query for a Vue 3 application is straightforward. First, install the package:

npm install @tanstack/vue-query
# or
yarn add @tanstack/vue-query

Then, head over to your main.js (or wherever you are mounting your app) and register the plugin.

main.js

import { createApp } from 'vue'
import { VueQueryPlugin } from '@tanstack/vue-query'
import App from './App.vue'

const app = createApp(App)

app.use(VueQueryPlugin)

app.mount('#app')

That’s it! Under the hood, VueQueryPlugin creates a QueryClient for us and provides it to the entire application. If you need to customize default options, you can pass a configuration object to the plugin.

In the example below, we can set a global staleTime (the time that it takes the application to consider data that is already pulled “stale” and, thus, marks it for refetch).

app.use(VueQueryPlugin, {
  queryClientConfig: {
    defaultOptions: {
      queries: {
        staleTime: 1000 * 60 * 5, // 5 minutes
      },
    },
  },
})

With the plugin registered, we are now ready to start fetching data.

Your First Query with useQuery

The core of TanStack Query is the useQuery composable. It takes a configuration object and returns a set of reactive properties that we can use directly in our templates. Let’s build a simple component that fetches a list of users.

UserList.vue

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

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

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

<template>
  <p v-if="isLoading">Loading users...</p>
  <p v-else-if="isError">Something went wrong: {{ error.message }}</p>
  <ul v-else>
    <li v-for="user in data" :key="user.id">
      {{ user.name }}
    </li>
  </ul>
</template>

Let’s break this down. The useQuery composable receives an object with two essential properties:

• queryKey: An array that uniquely identifies this query. TanStack Query uses this key to cache, deduplicate and refetch the data. Think of it as a unique ID for this particular piece of server state.
• queryFn: An async function that actually fetches the data. It must return a promise that resolves with the data or throws an error.

The composable returns several reactive properties, but the ones you’ll use most often are:

• data: The resolved data from the query function. It’s undefined until the query resolves!
• isLoading: A boolean that is true while the query is fetching for the first time (no cached data exists yet).
• isFetching: A boolean that is true while the query is fetching. This includes background refetches.
• isError: A boolean that is true if the query encountered an error.
• error: The error object if the query failed.

Notice how clean our template is. We don’t need to manually set up loading flags or try/catch blocks. TanStack Query handles all of that for us.

I highly recommend that you read through the Query basics page from the Tanstack documentation to really understand the different states and how to manage them.

Query Keys

Query keys deserve a bit more attention. They are not just static identifiers; they can be dynamic. For example, if we wanted to fetch a single user by ID, we could write:

const { data } = useQuery({
  queryKey: ['user', userId],
  queryFn: () => fetchUserById(userId.value),
})

Whenever userId changes, TanStack Query will automatically recognize it as a different query and fetch the new data accordingly. If the data for that particular key was already cached, it will be returned instantly while a background refetch happens. This is extremely powerful and removes a lot of the manual watch logic you would otherwise have to write.

If you’re having a hard time wrapping your head around this one, think about what an API endpoint usually looks like:

• myapp.com/user/1
• myApp.com/user/2

The user portion of the queryKey closely matches our API endpoint syntax (this doesn’t have to be like this, this is merely a suggestion). More importantly, the userId reactive value will represent the ID (1/2) that we are sending to the API. We definitely want the caches for both of the calls above to be different from one another.

Caching and Stale Data

One of the biggest advantages of TanStack Query is its built-in caching. Once a query resolves, the result is stored in memory and associated with its query key. If another component (or the same component after a navigation) requests data with the same query key, the cached data is returned immediately (if it’s not stale), so no other call has to be made to the API.

This is particularly noticeable when navigating between pages. Say you have a user list on one page and a user detail on another. When your user navigates back to the list, the data will already be there. No loading spinner, no flash of empty content.

TanStack Query manages this through two important concepts:

• staleTime: How long (in milliseconds) the data is considered “fresh.” While data is fresh, TanStack Query will never refetch it. The default is 0, meaning data is immediately considered stale after fetching.
• gcTime (garbage collection time): How long unused cached data is kept in memory before being garbage collected. The default is 5 minutes.

You can configure these per query:

const { data } = useQuery({
  queryKey: ['users'],
  queryFn: fetchUsers,
  staleTime: 1000 * 60 * 10, // 10 minutes
  gcTime: 1000 * 60 * 30,    // 30 minutes
})

In this example, after the data is first fetched, it will be considered fresh for 10 minutes. During that time, any component mounting with the same ['users'] query key will get the cached data instantly with zero network requests. After 10 minutes, the data is marked stale and will be refetched the next time it is needed. If no component uses the ['users'] query for 30 minutes, the cache entry is garbage collected entirely.

To be quite honest with you, I’ve personally never bother setting or modifying the default gcTime, but it’s an important concept to keep in mind when using Tanstack.

Refetching

TanStack Query doesn’t just fetch your data once and forget about it. It comes with several mechanisms to keep your data up to date, both automatic and manual.

Automatic Refetching

By default, TanStack Query will automatically refetch stale queries in the following situations:

• Window focus: When the user leaves your app and comes back (tabs away and returns), stale queries are refetched. This is incredibly useful and one of my favorite benefits of Tanstack that you get for free—your users always see fresh data without lifting a finger.
• Network reconnect: If the user loses their internet connection and reconnects, stale queries are refetched automatically.

You can control these behaviors individually:

const { data } = useQuery({
  queryKey: ['users'],
  queryFn: fetchUsers,
  refetchOnWindowFocus: false, // disable window focus refetch
  refetchOnReconnect: true,    // this is the default
})

Polling with refetchInterval

For data that needs to be updated on a regular cadence, for example a notifications counter or a live feed, you can set up polling with refetchInterval.

const { data } = useQuery({
  queryKey: ['notifications'],
  queryFn: fetchNotifications,
  refetchInterval: 1000 * 30, // refetch every 30 seconds
})

This will fire a background refetch every 30 seconds regardless of user interaction and regardless of stale state. The UI updates seamlessly since the cached data is replaced when the new data arrives. Keep in mind that all data returned by useQuery is reactive.

Manual Refetching

Sometimes you want to give the user explicit control over when to refresh data. The useQuery composable returns a refetch function for exactly this purpose.

UserList.vue

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

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

<template>
  <button @click="refetch" :disabled="isFetching">
    Refresh
  </button>

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

Notice we’re using isFetching here instead of isLoading to control the button’s disabled state. The distinction is important: isLoading is only true when there is no cached data and a fetch is in progress (first load), while isFetching is true whenever any fetch is happening, including background refetches. This allows us to show the cached data in the list while indicating that a refresh is in progress.

Conditional Queries with Enabled

One last option worth mentioning is enabled. Sometimes you don’t want a query to fire immediately. Perhaps you need to wait for a user to select something first, or you want to set up a computed property with some conditions that need to occur first.

const { data } = useQuery({
  queryKey: ['users', userId],
  queryFn: () => fetchUserById(userId.value),
  enabled: () => !!userId.value,
})

The query will only execute when enabled evaluates to true. Once userId gets a value. Tanstack query will fire automatically once the reactive property returns true. If this property reverts to false the query no longer refetch when stale.

Wrapping Up

TanStack Query takes a lot of the pain out of data fetching in Vue applications. With minimal setup, we get automatic caching, configurable stale times, background refetching on window focus and reconnect, polling, and clean loading and error states.

We’ve only scratched the surface here. TanStack Query also supports mutations for creating and updating data, optimistic updates, infinite queries for pagination and a fantastic set of devtools for debugging your queries in the browser.

I recommend taking a deep dive into the official documentation as it is very well written and packed with examples.

Happy fetching!

A few days ago, we checked out Google I/O 2026, and today we need to talk about our favorite framework: Angular. Why? Because version 22 is here!

Angular v22 is a major update focused on stability, performance and ergonomic APIs. It brings a more polished signal-driven platform and better data loading primitives that make modern apps feel faster and simpler to build.

Before we look at the most interesting changes, let’s talk about the foundation. Angular v22 stabilizes the features we have been testing in the last few versions. If you want to build a high-performance app today, these are the new standards.

Stable Signal Forms and httpResource

Reactive Forms were great, but they often felt separate from the modern Signal-based reactivity. In v22, Signal Forms are officially stable.

What does this mean for us?

• Better reactivity: No more unnecessary updates when a single field changes.
• Better type safety: We finally have a form system that works perfectly with TypeScript.

Do you remember HttpClient and the manual toSignal conversions? They worked, but they added extra code. Now we have httpResource.

It is the new standard for fetching data. It treats your HTTP requests as signals, automatically handling the loading, error, and data states for you.

Learn more: Dive deeper into Getting Started with httpResource API and learn more about Angular Signal Forms vs. Reactive Forms.

But what if your request depends on another signal? In v22, we have the new chain() method. It allows you to link resources together. If the first resource is loading, the second one waits automatically. This is a big win for complex data!

Wait, what if you are already using RxJS? Don’t worry, Angular has a solution for that too. Let’s see how v22 handles the transition from Observables to Resources.

RxResource vs. httpResource

A common question is: “Should I stop using RxJS?” The answer is no. Angular v22 introduces rxResource as the perfect partner for your existing Observable streams.

• httpResource: Use this for standard API calls. It is optimized for the Fetch API and handles JSON automatically.
• rxResource: Use this when your data source is an existing Observable. It allows you to use the power of RxJS operators inside the clean, Signal-based Resource API.

Now that we have our data fetching ready, how do we make sure our users and agents can navigate efficiently? Let’s talk about the new smart navigation features in the Router.

Smart Navigation and Incremental Hydration

The Angular Router received some updates in v22 that solve common problems.

• URL decoupling: You can now keep a clean URL in the address bar while the app shows a different state. With the new browserUrl input on RouterLink, you can show /settings while the router actually uses /account/advanced-preferences.
• Parameter inheritance: Child routes now inherit parameters from their parents by default, and you don’t need extra configuration to get an ID from a parent route.

But a great UI and smart routing mean nothing if the page is slow to load. This brings us to the most impressive performance update in v22: incremental hydration.

Server-Side Rendering (SSR) is no longer a problem. In v22, incremental hydration is the default.

Angular now loads your application in small parts as they become visible. Combined with resource caching, the client can use the data fetched on the server without making a second API call. The user sees the data instantly, and the “flicker” of reloading data is gone.

Learn more: Explore The New Angular Hydration for in-depth details.

But performance is also about how the browser handles changes. This is where the biggest change in Angular’s history reaches its peak.

OnPush by Default

For years, ChangeDetectionStrategy.Eager (previously known as `Default`) was the standard for Angular’s change detection. With v22, ChangeDetectionStrategy.OnPushis now the default for new components!

By using ChangeDetectionStrategy.OnPush as the default, we get:

• Better performance: The framework only checks what it needs to, exactly when it needs to, avoiding unnecessary checks.
• A step closer to Zoneless: This sets the stage for eventually dropping zone.js in the future.

If you have an older app, don’t worry! There is a migration tool that adds ChangeDetectionStrategy.Eager (the new name for the old behavior) to your existing components exactly as before.

Now, how do we make sure our fast code actually works? Let’s talk about the new speed king of testing.

Vitest

Testing used to be the slow part of our work. Not anymore. Angular v22 officially replaces Karma/Jasmine with Vitest as the default test runner.

It is very fast and shares the same configuration as your build pipeline. Also, the new migrate-karma-to-vitest tool makes the change very easy, even for complex tests!

Do you want to try Vitest?

Angular Aria: Accessibility for Everyone

Building custom components with correct ARIA roles and focus management can be difficult. In v22, Angular Aria is officially stable.

Think of it as “headless accessibility.” It provides the logic you need to build your own accessible components. It handles the complicated parts of ARIA attributes and keyboard interactions for you.

Why does this matter for AI? Because accessible apps are much easier for AI Agents to understand!

Check this example about how to build accessible components with Angular Aria.

Async Dependency Injection

The injectAsync() function allows us to lazy-load services only when they are actually needed, while still creating the instance with Angular dependency injection. This keeps your app small and fast.

export class CheckoutComponent {
  // We declare the lazy injection in the injection context (class field)
  private paymentGatewayLoader = injectAsync(() => 
    import('./payment-gateway.service').then(m => m.PaymentGatewayService)
  );

  async onCheckoutCompleted() {
    // We only load the heavy PaymentGatewayService when the user actually checks out!
    const paymentGateway = await this.paymentGatewayLoader();
    await paymentGateway.processTransaction();
  }
}

Building a Dashboard with Angular 22

Instead of just explaining features, let’s build a practical dashboard example that uses the stable core of Angular v22: @Service(), httpResource() and the new template syntax.

Want to follow along? You can clone the complete project from GitHub: angular-22-nba-finals. Just run npm start and you’ll have the dashboard running locally.

The Data Service with @Service

Now, let’s create our service. We will use the new @Service() decorator (which replaces @Injectable()) and httpResource to fetch the games. Notice how httpResource handles loading and error states for you.

// src/app/nba.service.ts
import { Service } from '@angular/core';
import { httpResource } from '@angular/common/http';

export interface NbaGame {
  id: number;
  gameNumber: number;
  homeTeam: string;
  homeScore: number | null;
  awayTeam: string;
  awayScore: number | null;
  status: 'Final' | 'Scheduled';
  date: string;
  location: string;
}

@Service()
export class NbaService {
  // httpResource is the standard for fetching data
  gamesResource = httpResource<NbaGame[]>('/api/nba-finals');
}

The UI Layer & Error States

We display the data using the new @for block and keep the error handling inside the component template. This keeps the example focused on stable Angular v22 behavior.

// src/app/app.ts
@Component({
  template: `
    <app-dashboard></app-dashboard>
    <router-outlet></router-outlet>
  `
})

Our Dashboard component remains simple:

// src/app/dashboard.component.ts
import { Component, inject } from '@angular/core';
import { NbaService } from './nba.service';

@Component({
  selector: 'app-dashboard',
  template: `
    <div class="dashboard">
      <h1>NBA Finals 2026: Knicks vs Spurs</h1>

      @if (nbaService.gamesResource.isLoading()) {
         <p>Loading game data...</p>
      } @else {
        <div class="cards">
          @for (game of nbaService.gamesResource.value(); track game.id) {
            <div class="card">
              <div class="meta">Game {{ game.gameNumber }} • {{ game.date }}</div>
              <div class="score">
                {{ game.homeTeam }} {{ game.homeScore }} vs {{ game.awayScore }} {{ game.awayTeam }}
              </div>
              <div class="status">{{ game.status }}</div>
            </div>
          }
        </div>
      }
    </div>
  `
})
export class DashboardComponent {
  nbaService = inject(NbaService);
}

Save changes and run ng server navigate in the browser and tada!!!

Done!! We play with the stable part of Angular v22 using @Service() for a clean singleton service definition, httpResource() for declarative, signal-based HTTP loading and @for with @if in templates to render loading and data states.

And, of course, AI is not forgotten by the Angular team. They updated and added new tools for Angular MCP and Skills. Let’s see them!

Angular MCP and Skills

Of course, Angular continues embracing AI. The Angular MCP exposes app state and builds workflows for tools that understand Angular projects. That includes server-side MCP tools such as devserver.wait_for_build, devserver.start and devserver.stop.

Version 22 also introduces Agent Skills for Angular, a lightweight set of skill definitions that give AI assistants direct knowledge of modern Angular idioms and best practices. These skills are useful for teams that want to integrate agent-assisted coding into their workflow without pain.

• Learn more about Angular MCP: angular.dev/ai/mcp
• Learn more about Agent Skills for Angular: github.com/angular/skills

Recap

Angular 22 is a declaration that the way we build for the web has evolved. And by using Signals, OnPush performance and declarative async resources, we can build applications that are faster, simpler and easier to maintain.

This release is about making stable patterns:

• Use httpResource() for fetch-heavy components.
• Use @Service() for singleton services.
• Use injectAsync() when you want to defer heavy service loading.
• Let template syntax like @for and @if keep your view code readable.
• Embrace the AI era with Agent Skills and MCP tools.

My advice is don’t just read this article—build something! Take the dashboard we sketched and turn it into an interactive experience with Progress Kendo UI for Angular AI Chat. A chat interface is a powerful way to explore the series score in real time and it’s a great way to test Angular 22 with a modern Kendo UI scenario.

Feel free to watch for all the new features in Angular 22:

For a complete overview and to verify all the new features, you can check the official release post: Announcing Angular v22.

Happy coding!

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.

Another year, another Google I/O. This time, the vibe is different. We are not just talking about “AI in a sidebar” or “chatbots.” We are witnessing the birth of the Agentic Era.

Watch the Google I/O Developer Keynote Recap:

As developers, we have all felt the pain: building a beautiful UI, only to have an AI agent try to “scrape” it. The agent fails to find the right button or misinterprets a CSS class. In 2026, Google is changing the game by providing the infrastructure for agents that do not just “chat,” but actually act.

Let’s dive into the key updates from the Developer Keynote that will change how we build software this year.

These are the top highlights of Google I/O 2026 for developers:

• Gemini 3.5 and Managed Agents: Act, Don’t Just Talk.
• Antigravity 2.0 and Managed Agents: The Agent-First Infrastructure.
• WebMCP: Making Your UI “Agent-Ready.”
• AI-Powered DevTools: Debugging for Humans and Agents.
• Android: The End of Slow Migrations.
• Firebase, Built-in AI and Performance: The Core of the Agentic Web.

Let’s explore each one.

1. Gemini 3.5 and Managed Agents: Act, Don’t Just Talk

The biggest shift this year is the introduction of Gemini 3.5 and the Managed Agents API. This is not just about a smarter LLM: it is about orchestration.

With a single API call, you can now set up a remote sandbox and an agent harness. This allows you to deploy autonomous agents that can execute code, manage files and interact with your backend. You do not have to manage the underlying compute or security infrastructure.

This integration goes beyond just code generation: it includes a “one-click deploy” from Google AI Studio directly to Cloud Run. This makes the path from prototype to production much faster. For Android developers, native Kotlin support enables a “vibe coding” experience. In this mode, the model understands complex app structures as if it were a senior teammate.

• Learn more about Gemini 3.5 capabilities.
• Watch Gemini 3.5 in action.

But having a brain capable of action is only the first step. To truly use this power, we need an ecosystem that can safely manage these agents. This is where the next generation of infrastructure comes in.

2. Antigravity 2.0 and Managed Agents: The Agent-First Infrastructure

The most powerful announcement for our productivity is the launch of Antigravity 2.0 and the all-new Antigravity CLI. This platform is more than just a tool: it is a complete surface for managing specialized subagents. These subagents can tackle complex workflows, such as UI development or backend migrations. The best part is that all of this happens while being protected by built-in terminal sandboxing and credential masking.

If you want to skip the infrastructure setup, the new Managed Agents in the Gemini API is a great solution. With one API call, Google provides a fully set-up agent harness with a remote sandbox. This removes the friction of setup, allowing you to focus on the logic of your agent.

• Check out the Antigravity SDK documentation.
• Watch Antigravity 2.0 in action.

Once we have the infrastructure to build and deploy agents, the next challenge is enabling our web applications to actually talk back to them. Let’s look at how Google is standardizing this conversation.

3. WebMCP: Making Your UI ‘Agent-Ready’

On the web side, the big news is WebMCP (Model Context Protocol for the Web). This protocol allows your website to expose structured tools directly to browser-based AI agents.

If you have been following my work on the Progress Kendo UI for Angular MCP Server, you know how powerful this is. While Kendo UI MCP helps the developer build apps by giving the agent specific knowledge, WebMCP helps the user’s agent navigate the app once it is built. Together, they create a complete AI lifecycle from creation to consumption.

Instead of an AI agent “guessing” how to interact with your data by clicking randomly, it can discover and use specific tools via WebMCP. For example, it can use a “Filter” or “Export” command in a Kendo UI Grid. This improves reliability and security for the end user.

• Discover WebMCP Architecture.

With our apps now acting as toolkits for agents, we need a way to see what is happening under the hood. Thankfully, the debugging tools we use every day have also received an AI-first update.

4. AI-Powered DevTools: Debugging for Humans and Agents

One of the most innovative updates is the transformation of Chrome DevTools into an AI-first environment. Google has introduced the AI Assistance panel. This is a context-aware chat interface powered by Gemini that understands the technical state of your page.

To enable these features today, make sure your DevTools language is set to English (US). Then, enable the “AI Innovations” flag in the DevTools Settings.

The dedicated DevTools interface for AI agents also grants autonomous assistants access to the accessibility tree and network traffic. This allows AI coding agents to identify and fix bugs or performance issues by themselves.

• Watch AI Assistance in DevTools.

But the shift toward an agentic future is not limited to the browser. These same patterns are now landing in the mobile ecosystem, starting with a massive update to how we migrate and build Android apps.

5. Android: The End of Slow Migrations

For mobile developers, the Android Migration Agent in Android Studio is a breakthrough. It can migrate source code from React Native or iOS into native Kotlin Android apps very quickly.

This is not just about translating syntax: the agent understands the architectural details of Navigation 3 and modern Jetpack libraries. By using open-source Android Skills, the migration follows industry-standard patterns. This means you do not just get a working app, you get a high-quality native codebase that follows Google’s best practices.

• Explore Android Skills on GitHub.
• Watch Android AI Updates.

None of these platforms would matter without a high-performance engine. To close our recap, let’s look at the core browser APIs and Firebase updates that make this entire experience possible.

6. Firebase, Built-in AI and Performance

Firebase is also becoming agent-ready with Firebase Data Connect. This feature brings PostgreSQL to Firebase, allowing you to build full-stack apps with AI Studio integration. You can now build and launch apps directly to Cloud Run without leaving your development environment.

On the browser side, Chrome 148 brings the Prompt API (powered by Gemini Nano) to the stable channel. It is now multimodal, which means you can process images, audio and text directly on the user’s device. The inclusion of Gemma 197M means these models are fast, even on older hardware.

Additionally, the new Soft Navigations API finally treats client-side transitions in SPAs as first-class citizens. This gives us accurate Core Web Vitals for our Angular dashboards. We also saw the release of HTML-in-Canvas, which allows us to render real DOM elements inside 3D environments.

• Check the Chrome 148 release notes.
• Watch Performance Updates.

Recap: Why These Tools Matter

Google I/O 2026 has made it clear: the browser and the OS are no longer just renderers. They are execution environments for intelligence. The shift from AI Assistance to Agentic Workflows is a massive opportunity for us as developers to redefine how users interact with software.

By making the web machine-readable with WebMCP and providing the Antigravity platform, Google is setting the stage for a proactive web. Our role is shifting from building static interfaces to building intelligent platforms.

What You Can Do Now

1. Experiment with WebMCP: Think about which repetitive task in your current app could be handled by a secure subagent or a structured tool. You can also play with the Kendo UI MCP to see it in action!
2. Optimize for Soft Navigations: If you are building web apps with React or Angular, start using the new API to get the real performance story of your dashboards.
3. Try the Managed Agents API: Test the loop between AI Studio and Cloud Run to see how fast you can go from idea to an agentic prototype.

If you have time, you can also check out the full video of the Developer Keynote for even more demos and deep dives.

Happy coding!

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.

There are not many good articles on publishing a TypeScript package to npm automatically. The best article I have seen is by the one and only Matt Pocock, How to Create an NPM Package. This is wonderful for understanding the package part, but publishing is not well documented. Recently, the npm publish keys have gone away, so we must connect our workflow manually with Trusted Publishing.

Let’s go through all steps to publish a TS npm package automagically!

Create Repository

1. Create a folder with the name of your package and open it up in VS Code.

2. Create your repository on GitHub with same name.

3. Run git init in root.

4. Create a .gitignore file in root. dist will be where it builds the JavaScript.

   node_modules
   dist
   .env
   .env.*
   

Note: You may not have an .env file, but it is good practice.

5. Create your README.md with whatever content.
6. Create a LICENSE file if you want as well. There are packages for this or you can copy and paste.
7. Run git add . and git commit -m 'first' to commit your first file.
8. Run git branch -M main to make main the default branch.
9. Add your remote origin with:

git remote add origin https://github.com/YOUR_REPOSITORY

10. Push package with git push -u origin main.

Note: My example package will be named format-price.

Create Your Package.json File

1. Create package.json in root.

{
  "name": "format-price",
  "version": "1.0.0",
  "description": "A demo of a simple TypeScript package that formats a price value.",
  "keywords": [
    "demo",
    "typescript",
    "price",
    "formatting"
  ],
  "homepage": "https://github.com/jdgamble555/format-price",
  "bugs": {
    "url": "https://github.com/jdgamble555/format-price/issues"
  },
  "author": "Jonathan Gamble (https://code.build)",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/jdgamble555/format-price.git"
  },
  "files": [
    "dist"
  ],
  "type": "module",
  "main": "dist/index.js",
  "scripts": {
    "build": "tsc",
    "test": "vitest run",
    "ci": "npm run build && npm test"
  }
}

• name - name it
• description - describe it
• version - use semantic versioning for changesets
• keywords - add keywords
• homepage - add your homepage
• bugs - where to report bugs
• author - who created this
• repository - where to view git source
• files - the folder to install
• type - use module for TypeScript
• main - entry point for node
• scripts
  • build - build TypeScript file
  • test - test with vitest
  • ci - continuous integration command for workflow

Install Dependencies

• npm i -D typescript to install it as development dependency
• npm i -D vitest for testing

Config TypeScript

• Create tsconfig.json file.

{
    "compilerOptions": {
        "esModuleInterop": true,
        "skipLibCheck": true,
        "target": "es2022",
        "allowJs": true,
        "resolveJsonModule": true,
        "moduleDetection": "force",
        "isolatedModules": true,
        "verbatimModuleSyntax": true,
        "strict": true,
        "noUncheckedIndexedAccess": true,
        "noImplicitOverride": true,
        "module": "NodeNext",
        "outDir": "dist",
        "rootDir": "src",
        "sourceMap": true,
        "declaration": true,
        "declarationMap": true
    }
}

See Matt Pocock’s Total TypeScript for more info and if you want prettier, etc.

Add Your TypeScript Content

For this test package, we are updating the price to standard format.

• /src/index.ts

export const formatPrice = (price: number) => {
    return new Intl.NumberFormat('en-US', {
        style: 'currency',
        currency: 'USD',
    }).format(price);
};

Add Testing Script

• /src/index.test.ts

import { formatPrice } from "./index.js";
import { test, expect } from "vitest";

test("formatPrice", () => {
    expect(formatPrice(1234.56)).toBe("$1,234.56");
});

test("formatPrice with small value", () => {
    expect(formatPrice(5)).toBe("$5.00");
});

Note: You can test your package with npm run test, which just runs npx vitest run under the hood.

Workflow 1

GitHub has the ability to run scripts once you commit. Every workflow file will be a YAML file with the extension .yml.

Create Default Continuous Integration Workflow

• .github/workflows/ci.yml

name: CI

on:
    pull_request:
    push:
        branches:
            - main

concurrency:
    group: ${{ github.workflow }}-${{ github.ref }}
    cancel-in-progress: true

jobs:
    ci:
        runs-on: ubuntu-latest

        steps:
            - uses: actions/checkout@v4

            - name: Use Node.js
              uses: actions/setup-node@v4
              with:
                  node-version: '20'

            - name: Install dependencies
              run: npm install

            - name: Run CI
              run: npm run ci

• This will install node, install dependencies and run the continuous integration script.

GitHub

When you commit your package, you will see the workflow runs in the Action tab on GitHub.

This workflow runs npm run ci, which basically makes sure the tests pass. It is queued first and then run.

And if it does not pass, you will see an error.

Your last commit will fail.

Which also notifies you in your email.

And, of course, you see a check once you re-commit with tests that pass.

Versioning with ChangeSet

Use changesets for versioning.

• Install it with npm i -D @changesets/cli
• Initialize it with npx changeset init

Create a New Version

• Run npx changeset
  • Select patch, minor or major for the type of update.
  • Enter a summary for the log describing the change.
  • You will see a new file under .changeset like smooth-ads-lick.md or some random name. This will be the log that will be appended to your root CHANGELOG.md file.
• Run npx changeset version to automatically update your package version.
  • The generated file smooth-ads-lick.md (will be different name) has been deleted, and your log in the root CHANGELOG.md file has been appended.

# format-price

## 1.0.2

### Patch Changes

- testing for log

## 1.0.1

### Patch Changes

- first patch

• Commit to GitHub as is:
  • git add .
  • git commit -m 'patch'
  • git push

GitHub

Now, let’s set up for auto publishing.

Go to Settings in your GitHub project, then click Actions and General on the left menu.

• You need to allow GitHub to publish to npm with read and write permissions.

Optional GitHub Ruleset

Under Rules and then Rulesets, it is wise (you will get a warning anyway) to protect your main branch.

• Name the ruleset Restrict Deletions or whatever you like.
• Make sure default is selected under target branches.
• By default, Restrict deletions and Block force pushes will be selected.

Workflow 2

Create the second workflow file in the .github/workflows folder called release.yml.

name: Publish Package

on:
    push:
        branches:
            - main

permissions:
    contents: write # required for tags + version PR
    pull-requests: write # required for Version Packages PR
    id-token: write # required for npm trusted publishing (OIDC)

jobs:
    publish:
        runs-on: ubuntu-latest

        steps:
            - uses: actions/checkout@v4
              with:
                  fetch-depth: 0 # Changesets needs tag + commit history

            - uses: actions/setup-node@v4
              with:
                  node-version: '20'
                  registry-url: 'https://registry.npmjs.org'

            - name: Update npm
              run: npm install -g npm@latest

            - name: Install dependencies
              run: npm ci

            - name: Build (if needed)
              run: npm run build --if-present

            - name: Run tests
              run: npm test

            - name: Changesets version / publish
              uses: changesets/action@v1
              with:
                  # When there *are* pending changesets → create/update Version Packages PR
                  version: npm run changeset:version

                  # After the Version Packages PR is merged → publish & create tags
                  publish: npm run changeset:publish
              env:
                  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
                  NPM_CONFIG_PROVENANCE: true

This workflow will run the tests with npm test, then create a PR. Once the PR is merged (this is manual for security—you don’t want this automatic), the version is updated, and that version is published to npm.

Note: Notice the permissions at the top. We need this to allow changes to the version. This is saved in GitHub under Releases and Tags.

Publish to npm

This assumes you have an npm account. You can create one at npm if you don’t have one. Make sure to enable 2FA.

Publish your first version to npm by running.

• npm login – You will log in with the browser, then enter your 2FA code.
• Run npm publish --access public to publish a public package.

Once you publish, you will see your package published in npm. This means anyone can install it with npm i format-price in their repo.

Note: Our final goal is to publish automatically with a git commit.

Configure GitHub Publishing

Click on the package, then go to Settings.

• Create a new Connection to GitHub Actions.

• Enter your GitHub username and repository, as well as your YAML file release.yml.

• You will see a connection enabled for GitHub to be a Trusted Publisher.

Auto Publishing

Now that the connection is setup, you can publish automatically.

• Create a change to your file.
• Run npm run build and then whatever other formatting or pre-publishing commands you use.
• Run npx changeset to create a new version. You can use patch for testing.
• Create a new commit
  • git add .
  • git commit -m 'auto publish'
  • git push
• Go to your project on GitHub, and you should see a successful Pull Request.

• Click the Merge pull request button to merge the versioning and changes. It will also auto publish and auto update your versions. Feel free to add any more description info for the PR.
• Wait a few minutes for the publish to update, and you will now see a Releases option in your GH sidebar.

• Don’t forget to pull the version changes locally with git pull.

You now have a fully automated npm publishing pipeline!

You can install your package anywhere with npm i format-price!

Example Repo: GitHub

Read next: TypeDB: A Graph Database for Things

Wiring up an LLM endpoint takes an afternoon; the harder engineering problem is building a UI layer that can absorb the inherent unpredictability of AI without introducing layout thrashing, inconsistent interaction patterns or sprawl that a small team can't maintain.

That's the problem Icanpreneur solved with KendoReact.

“The hard part with AI is not just calling a model – it’s designing complex, trustworthy workflows around it. That’s where KendoReact helped a lot.”

Icanpreneur’s platform orchestrates guided, AI-assisted workflows that blend business logic, structured data and real-time feedback into a familiar, approachable experience. Users move through Lean Canvas modeling, validation flows and strategic planning steps with AI augmenting their thinking along the way. They’re now used not only by early-stage founders but also by accelerators, innovation hubs and product teams inside organizations such as Founder Institute, Campus X, Science Park Graz, ABLE Activator, Sofia Tech Park, Visa Innovation Program Europe and Telerik Academy’s Upskill Product Management program.

Raw AI output can be unpredictable. Without a stable, consistent UI foundation, that translates into friction and mistrust. The consistency, predictability and performance of KendoReact in the UI layer turned the output of Icanpreneur’s AI assistant, IVA, into something usable and trustworthy. For Icanpreneur’s six-person team, KendoReact was the infrastructure that made AI usable at scale.

Icanpreneur’s Architecture

At a high level, Icanpreneur’s platform is structured as a layered system that separates UI composition and user interaction, server / API management and LLM orchestration.

KendoReact is the core of the Icanpreneur UI layer, allowing them to guide users through complex multi-pane screens, support long-running workflows with consistent UI patterns and handle advanced multi-step journeys without overwhelm. Every major module (Lean Canvas, conversational interview console, go-to-market editor, persona builder) is composed from the same KendoReact primitive set, themed consistently and governed by the same layout contracts. That decision paid compounding dividends as the product scaled.

In an AI-first platform, it can be tempting to start thinking about the UI as set dressing; just a thin layer over the APIs to make things “look pretty” for the users. However, AI interaction patterns are still very new and unfamiliar to many users. A UI that naturally folds AI into the user experience can be a real differentiator in the competitive market.

“Founders in partner programs started telling us that the interview, insights and go-to-market flow ‘feels like one tool – simple and intuitive, not five stitched together.'”

AI technology is impressive but UI engineers are still the ones who translate that potential into true value for the user. In Icanpreneur’s case, they needed stable layout primitives, reliable form controls and high-performance data visualization components – all of which had to present AI output reliably (while responses were streaming, partial or evolving) without triggering unnecessary re-renders or layout shifts. KendoReact provided that and more, empowering the team to focus their effort on user experience, business logic and AI orchestration.

Composability as a Force Multiplier

One of the most important architectural decisions was treating KendoReact not as a collection of finished widgets or mere building blocks to be combined but as true UI infrastructure. KendoReact powers everything from research dashboards and conversational interview consoles to mini-CRMs and multi-step go-to-market editors.

Foundation pieces were combined to create higher-order workflows that guide users through their interactions with IVA. Rather than building custom UI for each flow, the team defined composable patterns built on KendoReact primitives. For example, the multi-step validation flow reused the same layout + navigation structure, AI feedback panels reused consistent container and typography patterns and interview summaries reused standardized layout and card structures. Because the Icanpreneur team didn’t need to design complex new interaction patterns for each additional feature, they were able to implement quickly and iterate fast – smoothly layering their AI workflows on top of KendoReact’s component system.

Consistent UX for Novel AI Workflows

For Icanpreneur users, this meant that they never had to open a page and feel unsure of where to go or what to do next – even though the AI-powered technology may be new, it leveraged familiar and consistent patterns to guide them through the experience.

“Because all the AI-driven experiences reuse the same KendoReact components as the rest of the app, they behave in a predictable way. Users don’t have to ‘learn' a new interface just because AI is involved – it feels like one coherent workspace.”

Design-to-Code Fidelity

With KendoReact, Icanpreneur designers and engineers worked from the same component language, which meant no translation layer between design and implementation, no pixel-chasing and no divergence between what's mocked and what ships. Designers also created a custom design system using the Kendo UI Figma Kits and the Progress Design System Kit, which greatly reduced the time needed to create mockups and new pages.

“Using the Kendo UI Figma Kits and a custom Kendo theme, we aligned design and development from day one. Most new features now start as a quick sketch in our KendoReact-based design system and turn into a working screen in days instead of weeks.”

Increased Development Speed

AI-assisted workflows evolve quickly: new steps get added, feedback formats change and validation criteria expand. Because KendoReact components are extensible and themeable, the Icanpreneur team could meet these challenges while still preserving UX consistency. As workflows grew, the UI layer remained adaptable; less time debugging or re-writing UI logic meant faster revision cycles and more shipped features.

“New workflow-style features (such as a new research flow or AI-assisted editor) now typically go from idea to shipped version in days instead of weeks, because we mostly compose existing KendoReact patterns instead of building UI from scratch.”

The UX of AI

Some of the biggest challenges in AI-first applications are handling uncertainty (usually in the form of partial / still evolving responses) and guiding users through new workflows. The Icanpreneur team leveraged KendoReact’s design tools to create UX patterns that integrate AI feedback into existing, structured UI flows, so users are never left wondering “what now?”.

One of the most unique features of Icanpreneur is their Synthetic Customer Interview feature, which allows their AI assistant, IVA, to answer questions as though it was a potential customer in their target market. Not all teams have easy access to customers to run interviews with, so this allows founders to “stress-test” their hypotheses quickly across multiple scenarios. That output helps them refine their questions and assumptions before talking to real people. Afterwards, IVA reviews all the data (across both real and synthetic customer interviews) to summarize, highlight patterns and extract quotes and evidence that can be leveraged in personas and further market research.

“When we designed IVA, the conversational interview console and the research workspace, we could prototype and ship quickly because we already had chat-style layouts built from existing KendoReact Layout and Form components, multi-step flows for things like research setup and go-to-market editors and reusable Panels, Drawers, Dialogs and Data Grids for displaying AI outputs, suggestions and insights aggregation”

Using KendoReact meant that not only could they leverage these familiar user patterns – but also that common AI concerns (such as slow, partial or unexpected responses) could be handled with UI structures and error responses that users already knew how to interact with.

Performance and Scalability

Icanpreneur workflows are complex, multi-stage journeys. Moving from idea to hypothesis, validating with AI or human-led interviews, identifying patterns and extracting valuable feedback, generating personas and finally creating landing pages or pitch decks – any one of these alone would be demanding but all together they offer a true development challenge. Each step builds upon the previous and the context must be preserved as the user moves between them. Without careful performance engineering, rendering and re-rendering these views would quickly degrade the user experience.

AI workflows can introduce frequent state updates as responses stream in or evolve - for example, when IVA synthesizes interview insights or drafts positioning. In poorly structured UIs, this can lead to layout thrashing or lag. However, these updates render inside structured, well-optimized KendoReact components, so the Icanpreneur UI remains stable.

As features accumulate, custom CSS and one-off component implementations are a common source of bundle bloat and regression risk. At Icanpreneur, new features and modules all plug into the same KendoReact UI system (rather than introducing new patterns and components). That allows even a small team to control UI sprawl and manage bundle growth. Custom CSS – a common pain point for fast-growing applications – is significantly reduced and centralized, because the UI is themed consistently. This kept initial load times reasonable even as the feature surface expanded.

“When we introduce new AI-driven experiences, they use the same KendoReact components, so we see far fewer UI regressions. That made it much easier to roll out new AI features without exploding our QA surface.”

That smaller, bounded QA surface meant faster turnaround and faster time to ship, while the lower complexity means that the small team was able to manage the expedited growth without being overwhelmed. New features that reuse existing KendoReact components inherit known-good behavior, so regression risk didn't scale with feature additions.

KendoReact’s components are designed for high-density, data-heavy enterprise applications; no reinvention (or re-optimization) was required even for complex components like grids, forms and dialogs. KendoReact reduced the need to solve hard performance problems manually, allowing Icanpreneur to access enterprise-level quality with a startup-size team.

Icanpreneur: Powered by KendoReact

Icanpreneur began as a structured way to guide founders from idea to product-market fit. Today it operates as a full AI co-founder, with IVA empowering entrepreneurs to ideate, validate and grow their companies as a trusted partner.

By treating the UI layer as infrastructure and building on KendoReact from day one, the team was able to:

• Scale complex, AI-driven workflows with consistency

• Ship new features rapidly without fragmenting UX

• Deliver a coherent experience across classic and AI-powered screens

For teams building AI-driven workflows, the UI layer is crucial: it's what determines whether AI output becomes a usable, trustworthy product or a source of friction. Icanpreneur's architecture is a case study in treating that layer seriously from day one. Or, as the Icanpreneur team said themselves:

“A six-person core team is able to maintain and evolve a fairly large, AI-first product (research, interviews, personas, positioning, landing pages, sales decks, etc.) without a separate “component team” or design system squad – KendoReact is that system for us.”

For teams building AI-driven applications with complex workflows, treating the UI layer as infrastructure can dramatically reduce friction as the product evolves. For Icanpreneur, KendoReact became that foundation: explore how KendoReact could become that foundation for your team, as well.