DEV Community: Lucy Muturi

How to Convert DOCX to HTML in C# Without Breaking Formatting

Lucy Muturi — Wed, 17 Jun 2026 11:00:34 +0000

TL;DR: Need to render Word documents in the browser without broken layouts? Convert DOCX files to clean, responsive HTML in C#, no Microsoft Word required. Preserve formatting, remove messy markup, and ensure consistent performance. Learn how to customize output, control styles, images, and layout with practical examples and best practices.

You open a Word document, and it looks perfect. Neatly aligned text, consistent fonts, beautifully structured sections. Exactly how you designed it.

Now, you upload it to your app and render it in a browser. Suddenly… things feel off.

The layout breaks in unexpected places.
Styles don’t match what you saw in Word.
The HTML is bloated with unnecessary markup, slowing everything down.
What once looked polished now feels messy and unreliable.

If you’re building something like a document portal, knowledge base, or even a simple content preview feature, this gap isn’t just annoying; it’s a real problem. It impacts performance, user trust, and the overall experience of your app.

So, you start wondering… What if there was a better way?

What if you can convert Word(DOCX) files into clean, lightweight, responsive HTML, something that just works in the browser without surprises?

That’s exactly what we’re going to explore. In this blog, we’ll see how to:

Convert DOCX files to HTML using the Syncfusion^® .NET Word Library (DocIO).
Fine-tune the output so it looks polished, loads faster, and blends seamlessly into your app.

Let’s get started!

What makes the conversion process easier?

A reliable DOCX-to-HTML conversion engine should do more than simply export content. It should help developers maintain consistency between the original document and what users eventually see in the browser.

Here’s where the Syncfusion .NET Word Library becomes useful:

Preserve document formatting. Maintain headings, lists, tables, styles, and text formatting so the HTML output closely matches the original Word document.
Deploy across modern environments. Whether you’re building apps on Windows, Linux, macOS, in containers, or in the cloud, the library works consistently without requiring Microsoft Office.
Control the HTML output. Customize how styles, images, headers, footers, and form fields are exported so the generated HTML fits your app requirements.
Reduce development complexity. Instead of manually processing Open XML structures or writing custom converters, developers can handle document conversion with a few API calls.

Getting started with the .NET Word Library

Step 1: Create a new .NET Core project

Open Visual Studio and select the ASP.NET Core template. Enter your project name, choose the desired configuration, and click Create.

Create a new .NET Core project

Now, you have a working foundation ready to handle document processing.

Step 2: Install the Syncfusion .NET Word Library

Next, install the Syncfusion.DocIO.Net.Core NuGet package.

Install the Syncfusion.DocIO.Net.Core NuGet package

This package enables your application to read, process, and convert Word documents, including converting them into HTML.

Convert DOCX files to HTML in C

The DocIO library makes it simple to convert Word documents (DOCX) into browser-friendly HTML format, while keeping the structure intact.

Here’s a simple example:

FileStream fileStreamPath = new FileStream("Template.docx", FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
//Opens an existing document from the file system through the constructor of the WordDocument class.
using (WordDocument document = new WordDocument(fileStreamPath, FormatType.Docx))
{
    //Saves the docx file to MemoryStream.
    MemoryStream stream = new MemoryStream();
    document.Save(stream, FormatType.Html);
    //Closes the Word document.
    document.Close();
}

That’s it! Your Word document is now converted into HTML, and ready to be rendered in a browser or embedded into your app.

Converting a Word document (DOCX) to HTML using C#

Note: Some advanced Word styling (like borders or background colors) may have limited support in HTML. For edge cases, it’s worth checking the official documentation.

Customizing the export settings in DOCX to HTML conversion

Here’s where things get more interesting.

Real-world apps rarely need a “default” conversion; you often need control. And this is exactly where DocIO shines.

You can fine-tune the output to match your UI, performance goals, and content needs.

What you can customize

Extract images to a specified directory for easy management.
Include headers and footers in the exported HTML for complete document fidelity.
Control editable fields by treating text input fields as editable or static text.
Define CSS styles with custom stylesheet types and names.
Embed images as Base64 for a single-file HTML output.
Omit XML declaration for cleaner HTML using the HtmlExportOmitXmlDeclaration property.

The following code example illustrates how to customize the export settings for DOCX to HTML conversion.

//Load an existing Word document into the DocIO library instance.
using (FileStream fileStreamPath = new FileStream("Input.docx", FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
   using (WordDocument document = new WordDocument(fileStreamPath, FormatType.Docx))
   {
        //The header and footer in the input are exported.
        document.SaveOptions.HtmlExportHeadersFooters = true;
        //Export the text form fields as editable.
        document.SaveOptions.HtmlExportTextInputFormFieldAsText = false;
        //Set the style sheet type.
        document.SaveOptions.HtmlExportCssStyleSheetType = CssStyleSheetType.Inline;
        //Set value to omit XML declaration in the exported HTML file.
        //True- to omit XML declaration, otherwise false.
        document.SaveOptions.HtmlExportOmitXmlDeclaration = false;
        //Create a file stream.
        using (FileStream outputFileStream = new FileStream("WordToHTML.html", FileMode.Create, FileAccess.ReadWrite))
        {
            //Save the HTML file to the file stream.
            document.Save(outputFileStream, FormatType.Html);
        }
   }

See the following image for better visual clarity.

Customizing the export settings in DOCX to HTML conversion

Read the full blog post on the Syncfusion Website

State Management in Blazor: Complete Guide to Building Scalable Apps

Lucy Muturi — Mon, 15 Jun 2026 11:36:05 +0000

TL;DR: Struggling with lost data after refreshes, messy component communication, or unexpected state leaks in your Blazor app? The problem usually isn’t Blazor; it’s how state is managed. This guide breaks down the most effective state management patterns in Blazor, from component state and dependency injection to browser storage and persistent state, helping you build scalable, reliable apps that behave predictably across every user interaction.

Your Blazor app works perfectly… until it suddenly doesn’t. Everything feels stable, until:

You refresh, and your form data disappears.
A small change breaks the state across components.
Or worse, one user sees another user’s data.

This isn’t rare. It’s one of the most common problems in real-world Blazor apps and it makes your app feel unreliable fast.

Here’s the hard truth: your app isn’t broken. Your state management is.

Blazor gives you a lot of flexibility, but without clear boundaries for where state should live, that flexibility quickly turns into confusion.

Fix that, and everything changes:

No more lost data on refresh,
No more property drilling chaos,
No more cross-user bugs, and
No more guessing where the state belongs.

In this guide, you’ll learn the practical state management patterns in Blazor (.NET 10 / ASP.NET Core 10), with real examples, so your apps stay stable, predictable, and easy to scale.

What is state management?

The web is inherently stateless. Anything you don’t deliberately store is gone when:

User refreshes (F5),
Tab closes,
User navigates away,
Server circuit reconnects (Blazor Server),
App switches from prerendered HTML to interactive mode (Blazor Web App).

The state management is simply about deciding where data should live so it persists across these events without leaking between users or making the app difficult to maintain.

How does state management work in Blazor?

Blazor gives you the same component model across three hosting approaches, but where and how long the state lives change dramatically.

Blazor WebAssembly (Pure client-side):

The entire .NET runtime and your app run inside the browser. Here, the state lives entirely in the browser’s memory:

Values of fields and properties in component instances.
The component hierarchy and its latest render output.
Data is held in DI services (usually registered as singletons, since the app runs in the browser).
Values set through JavaScript interop and browser storage (localStorage or sessionStorage).

Blazor Server (Server-side with SignalR):

Your components and logic execute on the server. State is tied to a live SignalR circuit:

Component instances and their in-memory fields are created on the server.
Scoped DI services that live for the duration of the user’s circuit.
Any server-side object that survive only while the connection is active.

Blazor Web App (Unified .NET 8+ model):

You get static server-side rendering (SSR) + optional interactivity (Server or WebAssembly per component).

State can flow seamlessly between server prerendering and client using PersistentComponentState, with Protected Browser Storage for secure persistence and automatic hydration across render modes.

In short, effective state management in Blazor means selecting the right technique based on state lifetime, scope, and hosting model, so user data remains consistent and reliable.

Which state management tool should I use?

The following are the state management types you can implement in Blazor.

Use this as a first pass:

Bookmarkable/shareable state: URL route/query parameters.
UI-only state inside one component: Local component fields.
Direct parent ↔ child coordination: Parameters + EventCallback.
Deep subtree configuration/context: Cascading values/parameters.
Cross-page or unrelated components: DI service (scoped/singleton carefully).
Reactive shared state: State container with change notifications.
Prerender → interactive continuity: [PersistentState] or PersistentComponentState.
Secure persistence in browser (Server only): ProtectedLocalStorage / ProtectedSessionStorage.

URL/query string parameters

For a state that needs to be bookmarkable, shareable via URL, or directly controls what is displayed on a page, encoding it in the URL is a robust approach.

Blazor’s routing mechanism allows you to define parameters directly in the URL path or extract them from the query string.

Use cases:

Product ID: /products/123
Category filter: /products?category=electronics
Search terms: /search?q=blazor+state
Pagination state (/items?page=2&pageSize=10).

Pros:

State is part of the URL, making it bookmarkable and shareable.
Naturally handles browser navigation (back/forward buttons).
Stateless from the server’s perspective (good for SEO and caching if server-side rendered).

Cons:

Limited to simple data types (strings, numbers, dates).
Not suitable for large or complex objects.
Can make URLs long and less readable if too many parameters are used.

Refer to the GitHub example demonstrating URL-based state management using route parameters and query strings.

Here, the {Category} route parameter, combined with [SupplyParameterFromQuery(Name = “searchTerm”)], automatically binds values from both the URL path and query string into component properties. Using the NavManager.NavigateTo() method, along with manual URI construction in ApplySearch(), ensures that any filter change updates the browser URL.

As a result, refreshing the page, bookmarking the link, or using browser navigation restores the exact filtered view without relying on additional storage, services, or state containers.

Local component state

The local component state is the simplest form of state management. Any private field or property in a @code block is local state, where state is contained entirely within a single Blazor component. This is fast, zero-overhead, and perfect for UI-only concerns (toggle flags, temporary form drafts, and animation states).

Use cases:

State for UI elements like a toggle button’s IsActive status.
Temporary input values in a form that haven’t been submitted yet.
Any state that is only relevant to the component itself and doesn’t need to be shared.

Pros:

Extremely simple and straightforward.
Highly encapsulated and isolated, reducing side effects.

Cons:

Cannot be directly accessed or shared by other components.

For more details, refer to the code example on the GitHub repository.

Improvement tip: If the same state needs to be shared across sibling components, this approach no longer works; that’s your cue to move to a higher-level state management pattern.

Parent-child communication (Parameters & EventCallbacks)

This is the standard way to manage state flow between directly related components in a hierarchical structure.

Parameters ([Parameter]): Used by a parent component to pass data to a child component.
EventCallbacks ([Parameter] EventCallback): Used by a child component to send notifications or data to its parent.

Use cases:

Displaying a list of items where each item is rendered by a child component.
A child component triggering an action in its parent (e.g., a “Save” button in a child form).
Any scenario where components have a clear parent-child relationship and need to exchange data.

Pros:

Clear and explicit data flow, easy to trace.
Strongly typed, enhancing code safety.
Supports two-way binding using Parameter and EventCallback pairs (e.g., Value and ValueChanged).

Cons:

Prop drilling: If data needs to go through many intermediate components that don’t use it, it can lead to verbose and difficult-to-maintain code.

Find the code example on GitHub and see the output image below for a better understanding.

Sharing state down the tree: Cascading parameters and values

The cascading parameters provide an elegant solution for passing data down a component hierarchy without the need for explicit parameter declarations at every level.

A component wraps a portion of the UI and makes a value available to all components within that subtree. The child components consume this value using [CascadingParameter].

For dynamic updates, use the CascadingValueSource(newer, notification-capable pattern).

The following component hierarchy diagram with arrows showcases the cascading parameter flow from root to leaves, highlighting reduced prop drilling.

Use cases:

Providing color schemes, fonts, or UI densities.
Making the current user’s identity or permissions available.
Sharing user preferences across many components.
Avoiding prop drilling for common, deeply nested data.

Pros:

Eliminates prop drilling for deeply nested components.
Cleaner component signatures as parameters aren’t explicitly listed.

Cons:

Less explicit data flow; it can be harder to see where a value originates from.
Can be misused for non-hierarchical data, leading to less maintainable code.

Also, check out the demo on the GitHub repository and see the output below.

Global state with dependency injection services

When a state needs to be shared across unrelated components or pages, using a dependency injection service is the most practical approach. A shared service allows the state to persist for the lifetime of a user session (Blazor Server) or browser tab (Blazor WebAssembly).

This is implemented by registering a plain C# class in Blazor’s dependency injection container. The service holds the shared data and typically exposes methods to update it. If needed, it can also notify components about changes.

Registration scopes:

Choosing the correct lifetime is critical:

AddScoped():
- Blazor Server: A new instance per user circuit/session. Ideal for per-user state (e.g., shopping cart, user preferences).
- Blazor WebAssembly: A new instance per browser tab. Ideal for per-tab state.
AddSingleton():
- Blazor Server: A single instance for the entire app. Use with caution, as all users will share the same instance.
- Blazor WebAssembly: A single instance for the entire app running in the browser tab.

Use cases:

Shopping cart accessible from product pages, header, and checkout.
User profile data that is shared across various authenticated pages.
Global notifications (toasts, alerts).
Any complex state that doesn’t fit a parent-child relationship.

Pros:

Centralized state management, keeping components lean.
Decoupled components from state implementation details.
Highly testable.
Supports various scopes to match state longevity needs.

Cons:

Requires manual implementation of change notification (e.g., event, Action delegates, StateHasChanged()).
Can become complex for very large apps without additional patterns (such as implementing a more structured, centralized state management solution like the Flux or Redux patterns using libraries like Fluxor, which enforce a unidirectional data flow and make state changes more predictable and manageable).

Example:

CounterState.cs

public class CounterState
{
    public int Count { get; private set; }

    public void Increment() => Count++;
    public void Reset() => Count = 0;
}

The registration differs by hosting model, see the following code example for more details.

Program.cs


// Blazor WebAssembly – Program.cs
builder.Services.AddSingleton<CounterState>();

// Blazor Server – Program.cs (.NET 6+)
builder.Services.AddScoped<CounterState>();

Scoped services in Blazor Server live per user circuit, while singletons in WebAssembly live for the browser tab. Using the wrong scope can lead to memory issues or shared data across users.

Note: In a Blazor Web App, when the CounterState class is added to the WebAssembly project, and you are using server-side prerendering, you need to register CounterState in the Server project as well, along with the WebAssembly project. Also, you can avoid prerendering at the server side by setting @rendermode @(new InteractiveWebAssemblyRenderMode(prerender: false)) and avoid registering the CounterState at the Server project.

Consumption:

ComponentUsingService.razor


@inject CounterState CounterState

<p>Count: @CounterState.Count</p>
<button @onclick="() => CounterState.Increment()">+</button>

Reactive state containers

Plain services like the above example don’t notify consumers of changes. A lightweight container fixes that.

ReactiveStateContainer.cs


public class ReactiveStateContainer
{
    private string? _savedString;

    public string Property
    {
        get => _savedString ?? string.Empty;
        set
        {
            _savedString = value;
            NotifyStateChanged();
        }
    }

    public event Action? OnChange;

    private void NotifyStateChanged() => OnChange?.Invoke();
}

Component usage (important: always unsubscribe):

StateContainer.razor


@page "/reactive-state-container"
@rendermode InteractiveWebAssembly
@implements IDisposable
@inject ReactiveStateContainer ReactiveStateContainer

<h2>Reactive State Container Demo</h2>
<p>Property: <strong>@ReactiveStateContainer.Property</strong></p>
<button class="btn btn-info" @onclick="UpdateValue">Update from Parent</button>

<NestedComponent />

@code {
    protected override void OnInitialized()
    {
        ReactiveStateContainer.OnChange += StateHasChanged;
    }

    private void UpdateValue()
    {
        ReactiveStateContainer.Property = $"Updated at {DateTime.Now}";
    }

    public void Dispose()
    {
        ReactiveStateContainer.OnChange -= StateHasChanged; // Prevent memory leak
    }
}

NestedComponent.razor:

NestedComponent.razor


@implements IDisposable
@inject ReactiveStateContainer ReactiveStateContainer

<div class="border p-4 mt-4 bg-light shadow-sm rounded"
     style="max-width: 580px;">
    <p>
        <strong>Nested component:</strong>
        Property = <em>@ReactiveStateContainer.Property</em>
    </p>

    <button class="btn btn-secondary" @onclick="UpdateFromNested">
        Update from Nested
    </button>
</div>

@code {
    protected override void OnInitialized()
    {
        // Subscribe so nested component re-renders on changes
        ReactiveStateContainer.OnChange += StateHasChanged;
    }

    private void UpdateFromNested()
    {
        ReactiveStateContainer.Property = $"Updated by Nested at {DateTime.Now:HH:mm:ss}";
    }

    public void Dispose()
    {
        // Unsubscribe on disposal
        ReactiveStateContainer.OnChange -= StateHasChanged;
    }
}

After executing the above code examples, the output will resemble the following image.

After clicking the nested component, the property is updated with a formatted date value.

Prerendered state persistence

The prerendered state persistence in Blazor means saving the UI state created during server prerendering so the client can continue seamlessly without re-running components.

In Blazor Server, this prevents the UI from resetting when the SignalR connection is established, giving a smooth transition from prerendered HTML to interactive components.
In Blazor WebAssembly, it lets the WASM runtime pick up the prerendered state immediately after downloading, avoiding flicker and improving perceived load performance.

You can persist the prerendered state in the following ways:

[PersistentState] attribute (Declarative)
PersistentComponentState service (Manual/imperative)
Custom serializer PersistentComponentStateSerializer

Let’s explore them in detail!

[PersistentState] attribute (Declarative)

Properties that are public, annotated with the [PersistentState] attribute, are serialized during prerendering. This is the simplest declarative approach and recommended for most cases.

Use cases:

Simple read-only or slowly changing data (weather forecasts, user preferences, catch lists).
Avoiding UI flicker on first load / F5.
Data that should survive prerender → interactive handover.

Pros:

Extremely clean (one line).
Automatic registration, cleanup, and restoration.
New in .NET 10 – officially recommended way.

Cons:

Only works on public properties.
Default JSON serialization (no easy way to encrypt property data without a custom serializer).
Limited control over timing.

In the GitHub example code, the Forecasts property is declared as public and marked with the [PersistentState] attribute, which will serialize all the four properties of WeatherForecast items.

If your data is mostly read‑only and doesn’t change often, you can still enable AllowUpdates = true on the [PersistentState] attribute so that any occasional updates get stored during enhanced navigation.
This is helpful for scenarios where the data is cached and expensive to retrieve, allowing the app to keep the latest snapshot without refetching or rerunning initialization logic.

To prevent the state from being restored when the app is prerendered, set RestoreBehavior to SkipInitialValue. If you want the state to refresh after a reconnection instead of using the last saved snapshot, set RestoreBehavior to SkipLastSnapshot.


[PersistentState(AllowUpdates = true)]
public WeatherForecast[]? Forecasts { get; set; }

[PersistentState(RestoreBehavior = RestoreBehavior.SkipInitialValue)]
public string NoPrerenderedData { get; set; }

[PersistentState(RestoreBehavior = RestoreBehavior.SkipLastSnapshot)]
public int CounterNotRestoredOnReconnect { get; set; }

To persist private property or a field, you need to use the PersistentComponentState class manually. Let’s see how to use it.

Read the full blog post on the Syncfusion Website

Free Online PDF Converters for Word, Excel, HTML & Images You Should Try

Lucy Muturi — Fri, 12 Jun 2026 11:05:31 +0000

TL;DR: Need to convert Word files, spreadsheets, webpages, or images without losing formatting? These free online PDF conversion tools help you create high-quality PDFs and image exports instantly, with accurate rendering, fast performance, and zero software setup.

PDFs remain the most reliable way to share documents across platforms, but converting files without disrupting layout is still a common challenge. Fonts shift, tables misalign, and images lose clarity, especially with low-quality tools.

Modern browser-based PDF converters address this with high layout fidelity and predictable output. Whether you’re working with Office files, web content, or images, the right solution ensures your documents render correctly without requiring heavy software.

In this guide, you’ll explore the most essential conversion types:

Office → PDF (Word, Excel, PowerPoint)
HTML → PDF (URLs, receipts, dashboards, web pages)
Image → PDF (merge scans, photos, documentation)
PDF → Image (JPG, PNG, WEBP exports)

All tools referenced here are free online converters powered by enterprise-grade document processing engines, delivering fast, accurate, and reliable results.

How free online PDF conversion works

Most tools follow a simple workflow:

Upload a file (or paste a URL for web content)
Select output format or options
Convert instantly
Download the result

Behind the scenes, high-quality converters rely on rendering engines that accurately interpret document structure, fonts, images, and layouts, much like professional document SDKs.

Office and document to PDF conversion

Converting Office files to PDF is one of the most common use cases, especially when consistency and portability matter.

Word to PDF

Ideal for resumes, reports, and business documents where formatting must remain stable.

Preserves:

Fonts, headings, and spacing
Tables and embedded images
Print-ready layout

Turn your Word file into a perfect PDF with one smooth click!

Excel to PDF

Spreadsheets often contain complex visuals and formatting that can easily break during conversion.

Preserves:

Charts, dashboards, and graphs
Number formats and formulas
Page scaling and alignment

Turn your spreadsheet into a clean, ready-to-share PDF instantly!

PowerPoint to PDF

Useful when sharing presentations across devices or distributing as static content.

Preserves:

Slide layouts and themes
Visual elements like icons and charts
High-resolution images

Transform your slides into a sleek, presentation‑ready PDF in a flash!

XPS to PDF

XPS is a legacy format that’s less supported today. Converting it to PDF ensures long-term accessibility.

Preserves:

Text and formatting
Vector elements and annotations
Overall document structure

Convert your XPS file into a clean, modern PDF in seconds!

HTML to PDF conversion

HTML-to-PDF is widely used for capturing dynamic or web-based content.

Common use cases:

Invoices, receipts, and reports
Dashboards and internal tools
Articles and documentation

This approach converts a live web page into a static, printable format while preserving the layout and styling.

Capture any webpage as a clean PDF, just paste the URL and convert!

Image to PDF conversion (JPG, PNG)

Combining images into a PDF is useful for organizing visual content into a structured document.

Typical scenarios:

Scanned documents and receipts
Photos or handwritten notes
Multi-page image collections

Key capabilities:

Reorder and merge images
Adjust layout and orientation
Maintain clarity and alignment

Turn your images, JPG, and PNG into a clean, organized PDF instantly!

Read the full blog post on the Syncfusion Website

AI-Powered Natural Language Filtering in .NET MAUI DataGrid

Lucy Muturi — Thu, 11 Jun 2026 10:58:30 +0000

TL;DR: Skip complex filters, let users simply describe what they need. With our .NET MAUI DataGrid and Azure OpenAI, queries like “customers from New York” are instantly converted into accurate filters. The result is a faster, more intuitive, zero learning curve experience built on a clean, scalable architecture for modern cross-platform apps. Ready to see how this works in practice? Let’s dive in.

What if filtering thousands of rows in a grid felt as simple as typing a sentence?

Traditional filtering forces users into rigid patterns: dropdowns, exact field names, and predefined conditions. Most grids still expect users to think like developers, remember column names, pick operators, and navigate layered menus just to find what they need. It’s slow, unintuitive, and often frustrating.

Now imagine your users simply typing:

Orders above $500,
Show high-value customers, and
Products under $100

…and instantly seeing exactly what they asked for.

No clicks. No confusion. Just results.

That’s the power of AI‑powered natural language filtering.

In this blog, we’ll show you how to bring this smart, natural-language filtering to life using Syncfusion^® .NET MAUI DataGrid and Azure OpenAI, so your apps feel less like tools and more like intelligent assistants.

Why natural language filtering matters

Natural language filtering transforms rigid, technical filtering into a simple, conversational experience. It lets users interact with data the way they naturally think, not the way the UI demands.

Key benefits

Faster data discovery. Skip menus and get instant results by simply describing what you need.
Zero learning curve. No need to remember column names, operators, or filter syntax.
Intuitive interaction. Users express intent in plain English, and AI handles the complexity behind the scenes.
Greater confidence. Explore data freely without worrying about making mistakes.

How it works

AI-powered filtering bridges the gap between human language and structured data by:

Understanding intent,
Translating it into precise filter logic, and
Delivering accurate results instantly.

The result: Faster insights, happier users, and a dramatically simpler, more engaging data experience.

Note: Before proceeding, refer to the getting started with .NET MAUI DataGrid documentation.

Prerequisites

Visual Studio.
Create a .NET MAUI application.
An Azure OpenAI resource and a valid API key.

How to embed AI-powered natural-language filtering in .NET MAUI DataGrid?

Adding AI-powered filtering to the .NET MAUI DataGrid isn’t just about calling an API, it requires a clean and scalable architecture. By using the MVVM pattern, you can neatly separate UI, business logic, and data handling, while dependency injection ensures your AI services are consistently available across the app.

Step 1: Create the AI filtering service

At the core of this implementation is the AIFilterService. Its role is to convert user-friendly, natural-language queries into a structured format your DataGrid can understand and apply.

For example, a query like:

“Female employees with rating ≥ 8 and salary > 5000”

is transformed into a compact JSON-based filter plan.

Here’s what happens behind the scenes:

A schema-aware prompt is sent to Azure OpenAI to ensure responses align with your data structure.
The AI returns a cleaned JSON filter definition (removing code fences and noise).
The response is then validated and parsed into strongly typed models such as FilterPlan or Condition, with support for nested filter groups.

If anything goes wrong, such as a missing configuration or invalid JSON, the service safely returns null, ensuring your app remains stable.

Refer to the following code example for implementation details.

public class AIFilterService : IAIFilterService
{
    // Converts a natural language prompt into a JSON filter plan via Azure OpenAI.
    public async Task<FilterPlan?> CreateFilterPlanAsync(string naturalLanguagePrompt)
    {
        // Ensure Azure OpenAI settings are present
        if (string.IsNullOrWhiteSpace(AzureBaseService.Endpoint) ||
            string.IsNullOrWhiteSpace(AzureBaseService.DeploymentName) ||
            string.IsNullOrWhiteSpace(AzureBaseService.Key))
        {
            return null;
        }

        // Clear instructions: JSON filter plans only, aligned with your grid schema
        var system = "You convert plain English filters into strictly valid JSON filter plans for a data grid.";
        var user = $"Grid schema:\n{SchemaText}\n\nUser query:\n{naturalLanguagePrompt}\n\nReturn JSON only.";

        try
        {
            // Call Azure OpenAI and get raw content
            var content = await CallAzureAsync(system, user);

            // Extract compact JSON (removes json fences, trims noise)
            var json = ExtractJsonObject(content);
            if (string.IsNullOrWhiteSpace(json))
                return null;

            // Parse JSON into a FilterPlan (parsing implemented elsewhere)
            return ParseFilterPlanFromJson(json);
        }
        catch
        {

            // Fail safe: return null on network/parse errors
            return null;
        }
    }
}

Step 2: Configuring AI services

Once your AI filtering service is ready, the next step is to make it available throughout your app. This is done during app startup by registering your services using dependency injection.

By configuring your AI service and ViewModel at this stage, you ensure they can be easily accessed wherever needed without manual instantiation or tight coupling.

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddAiServices(this IServiceCollection services)
    {
        services.AddSingleton<IAIFilterService, AIFilterService>();
        services.AddSingleton<EmployeesViewModel>();
        services.AddTransient<MainPage>();
        return services;
    }
}

Step 3: Integrating Azure OpenAI with your .NET MAUI app

To enable natural language filtering, your app needs to connect to Azure OpenAI, which powers the understanding and interpretation of user queries.

To do so:

First, ensure you have access to Azure OpenAI and create a deployment in the Azure portal.
If you do not have access, please refer to the create and deploy Azure OpenAI service guide to set up a new account.
Note down the deployment name, endpoint URL, and API key.
Make sure you’ve installed the Azure.AI.OpenAI NuGet package from the NuGet Gallery.
In your base service class (AzureBaseService), initialize the OpenAIClient.
Replace the Endpoint, DeploymentName, and Key with the actual values from your Azure OpenAI resource.

public abstract class AzureBaseService
{
    internal const string Endpoint = "YOUR_END_POINT";
    internal const string DeploymentName = "DEPLOYMENT_NAME";
    internal const string Key = "API_KEY";

    protected AzureBaseService() {}
}

Next, we’ll define the models that make this integration work seamlessly.

Read the full blog post on the Syncfusion Website

How to Add PDF Annotations in Angular Using a Built-In Toolbar

Lucy Muturi — Fri, 05 Jun 2026 13:30:43 +0000

TL;DR: Build a review-ready Angular PDF experience with an embedded annotation toolbar, enable highlights, sticky notes, stamps, and shapes to streamline document workflows, improve collaboration, and keep feedback within your application for faster, traceable approvals.

You’ve added a PDF viewer to your Angular app. Users can scroll, zoom, and search documents, a great start.

But the moment someone asks, “Can I highlight this section?” or “Can I leave a comment here?”, the experience breaks. The viewer works, but the review process doesn’t.

Most PDF viewers are built for reading, not reviewing. Real-world applications, contracts, approvals, and engineering plans require annotations, not just rendering.

This is where an embedded PDF annotation experience becomes essential.

In this blog, you’ll integrate a Syncfusion^® Angular PDF Viewer and enable a fully functional annotation toolbar with support for highlights, sticky notes, stamps, and shapes.

Why PDF review workflows fail without in-app annotation tools

When annotation isn’t part of your application, users are forced into fragmented workflows:

Context switching slows everything down Open PDF → download → annotate in another tool → re-upload → send feedback → track manually.
No audit trail for compliance Feedback scattered across emails or chat leaves no reliable record of who reviewed what and when.
User experience breaks Users leave your product to complete tasks elsewhere and may not return.
Approval processes become messy Version conflicts, manual tracking, and disconnected tools introduce delays and errors.

A viewer alone isn’t enough. The review process needs to stay within your application.

Syncfusion Angular PDF Viewer with built-in annotation toolbar

Instead of building annotation functionality from scratch, you can use our Angular PDF Viewer that already includes a configurable annotation toolbar.

No third-party overlay, no custom annotation engine required.

This enables you to turn a basic document viewer into a review-ready interface with minimal setup.

What you get out of the box

Configurable annotation toolbar
Multiple annotation types (text markup, notes, stamps, shapes, ink)
Author tracking and comments panel
Import/export support (JSON/XFDF)
Works across desktop and responsive layouts

Quick setup

Let’s get the viewer running first: 5 steps, under 5 minutes.

Step 1: Install the package

Run the command below to install our Angular PDF Viewer package in your Angular application:

npm CLI

npm install @syncfusion/ej2-angular-pdfviewer --save

Step 2: Add required styles

Add the following Syncfusion Material theme CSS to your style.css file:

style.css

@import '../node_modules/@syncfusion/ej2-base/styles/material.css';
@import '../node_modules/@syncfusion/ej2-buttons/styles/material.css';
@import '../node_modules/@syncfusion/ej2-inputs/styles/material.css';
@import '../node_modules/@syncfusion/ej2-popups/styles/material.css';
@import '../node_modules/@syncfusion/ej2-lists/styles/material.css';
@import '../node_modules/@syncfusion/ej2-navigations/styles/material.css';
@import '../node_modules/@syncfusion/ej2-dropdowns/styles/material.css';
@import '../node_modules/@syncfusion/ej2-splitbuttons/styles/material.css';
@import '../node_modules/@syncfusion/ej2-notifications/styles/material.css';
@import "../node_modules/@syncfusion/ej2-angular-pdfviewer/styles/material.css";

Step 3: Register required services

Import PdfViewerModule and the required AnnotationService module in your app.module.ts:

app.module.ts

import {
  PdfViewerModule,
  ToolbarService,
  AnnotationService,
  TextSearchService,
  MagnificationService
} from '@syncfusion/ej2-angular-pdfviewer';

@NgModule({
  imports: [PdfViewerModule],
  providers: [
    ToolbarService,
    AnnotationService,
    TextSearchService,
    MagnificationService
  ]
})

Step 4: Add the PDF Viewer component

Open your component template and add the <ejs-pdfviewer> tag to render the PDF Viewer component:

app.component

<ejs-pdfviewer 
       id="pdfViewer" 
       [documentPath]="'https://cdn.syncfusion.com/content/pdf/pdf-succinctly.pdf'" 
       [resourceUrl]="'https://cdn.syncfusion.com/ej2/25.1.35/dist/ej2-pdfviewer-lib'"
       style="height:640px;display:block">
</ejs-pdfviewer>

Step 5: Run the app

Start the development server:

npm CLI

ng serve --open

Angular PDF Viewer

Explore the setup documentation and live demo to see PDF annotation tools like highlights, notes, and stamps in action.

Core PDF annotation features in Angular

Instead of spreading features across separate workflows, annotations bring everything into one place.

Text markup annotations (Highlights, Underline, Strikethrough)

Ideal for contract reviews and document validation:

Highlight key clauses and obligations
Underline sections for discussion
Strike out outdated or invalid terms

This keeps the review context within the document without relying on external tools.

Adding Text Markup annotation

You can explore the text markup annotation documentation for more details.

Read the full blog post on the Syncfusion website.

From Read-Only Grids to Real Spreadsheets in React

Lucy Muturi — Thu, 04 Jun 2026 12:03:02 +0000

TL;DR: When React apps move beyond data display, read‑only grids start breaking down. This article explores when a true Excel‑like spreadsheet editor makes sense, covering real-world use cases, editing and formula support, Excel import/export, performance at scale, and how it improves UX, productivity, and long-term maintainability for data-heavy applications.

Modern React applications don’t just display data anymore. Users expect to edit values, apply formulas, format cells, analyze results, and export files, all without leaving the app. That’s where traditional read‑only data grids begin to struggle.

Grids work well for displaying rows and columns, but as soon as real data work enters the picture, teams end up patching missing features, adding workarounds, or pushing users back to Excel. At that point, it’s worth asking whether a grid is still the right foundation.

This article looks at when grids fall short, what defines a real spreadsheet experience, and how React apps can move to an Excel‑like Spreadsheet Editor without rewriting the UI.

Why read-only data grids fall short for modern React apps

Data grids are optimized for viewing and light interaction, not for data manipulation. That limitation becomes clear as soon as users need to do more than scroll and filter.

Common breaking points include:

No built‑in formula support for calculations or derived values
Limited or no cell‑level formatting
Missing Excel workflows like autofill, copy/paste ranges, or multi‑cell edits
No native way to import or export real Excel files
Increasing customization cost as every new requirement turns into custom code

When users repeatedly export data just to finish their work in Excel, the grid no longer helps; it slows the workflow.

What a real Excel-like Spreadsheet editor requires

A spreadsheet experience is more than editable cells. It’s a cohesive set of capabilities that allow users to work with data naturally, the same way they already do in Excel.

At a baseline, a production‑ready React spreadsheet editor needs:

Smooth inline editing with keyboard navigation
Multi‑cell selection, copy/paste, and autofill
Formula support with automatic recalculation
Rich formatting (fonts, borders, alignment, number formats)
Reliable Excel import and export without breaking structure

For data‑heavy or enterprise applications, additional capabilities matter just as much:

Multi‑sheet workbooks for complex datasets
Charts and visualizations generated from sheet data
Data validation to control inputs
Sheet‑ and workbook‑level protection

When these features exist natively inside the app, users stop switching tools, and productivity improves immediately.

Syncfusion Spreadsheet Editor

One of the first questions developers ask is whether a spreadsheet can handle large datasets. Performance becomes critical when you’re dealing with thousands of rows, formulas, and multiple sheets.

The Syncfusion React Spreadsheet Editor is exactly that, and it scales. It handles large datasets efficiently using virtualization, keeping performance fast even with thousands of rows and columns. For large workbooks, enable virtualization and follow the React Spreadsheet performance best practices, including virtual scrolling, chunked responses, and controlled formula recalculation.

What makes the upgrade smoother:

Unified API across React, Angular, Vue, Blazor, and other major frameworks, ideal for teams with mixed stacks.
Consistent behavior across tech stacks, low learning curve for your team.
Maintainable codebase, one component that scales as your product grows.

Whether your team works with a single framework or a mixed stack, the Syncfusion Spreadsheet Editor is available across all major frameworks, so everyone works with the same component, the same API, and the same behavior.

React Spreadsheet Editor

Ready to explore everything the React Spreadsheet Editor can do? Jump into the feature tour.

What a Syncfusion React Spreadsheet editor delivers out of the box

Switching from a grid to a spreadsheet isn’t just about editing; it’s about unlocking workflows that weren’t possible before.

Core spreadsheet features

Cell and range selection with real keyboard support
Inline WYSIWYG editing
Undo/redo, copy/paste, and autofill
Multi‑line cell editing

Editing in React Spreadsheet Editor

Excel-level calculation and formatting

Built‑in formulas with automatic recalculation
Number formats for currency, percentages, dates, and time
Conditional formatting and aggregates

Adding a formula in React Spreadsheet Editor

Data organization and analysis

Sorting and filtering
Data validation
Freeze panes and resize rows or columns
Insert, delete, hide, or merge cells and sheets

Applying data validation in React Spreadsheet

Advanced spreadsheet capabilities

Charts created directly from sheet data
Images and hyperlinks
Sheet and workbook protection
Customizable UI and templates

Protect sheet support in React Spreadsheet

Global, accessible, production-ready

Localization and RTL layouts
Global number and date formats
Full WAI‑ARIA compliance with keyboard navigation

All of these features come together in a single component, reducing custom development and long-term maintenance.

Want to see all these spreadsheet features in action? Try the Syncfusion React Spreadsheet demo.

How to integrate Syncfusion Spreadsheet into a React app

Adding our ** Spreadsheet React** component to your app is quick and straightforward. With just a few steps, you can replace your grid with a fully interactive Excel‑like editor.

Step 1: Create a new React application

You can quickly set up a React app using Vite.

npm CLI

npm create vite@latest my-app -- --template react
cd my-app
npm run dev

Step 2: Install the Syncfusion React Spreadsheet Editor package

npm CLI

npm install @syncfusion/ej2-react-spreadsheet --save

Read the full blog post on the Syncfusion website.

Why Nested ListView Breaks Down Faster Than You Expect in .NET MAUI

Lucy Muturi — Wed, 03 Jun 2026 15:06:30 +0000

TL;DR: Nested ListView in .NET MAUI is often introduced as layouts grow more complex. This article explores where that pattern creates challenges and examines the alternative list structuring approaches commonly used instead.

Using .NET MAUI ListView to build complex, data-heavy layouts often starts smoothly, especially when the UI structure closely mirrors the data model. The friction shows up later, usually when lists grow, layouts become interactive, and scrolling needs to stay fluid across devices.

This guide walks through what actually happens inside Syncfusion^® .NET MAUI ListView when lists are nested, why those internal behaviors lead to gesture conflicts and layout thrashing, and how common replacement patterns, such as grouping, expand/collapse rows, and composite templates, change the performance profile of a page.

Along the way, it also looks at where nesting sometimes cannot be avoided, what trade-offs it introduces, and how tuning options like sizing strategy and incremental loading affect real-world scrolling behavior in Syncfusion ListView.

Why you should avoid nested ListView

1. Competing virtualization pipelines

Each List View maintains its own recycling, measurement, and layout lifecycle. When one ListView is nested inside another, both attempt to virtualize independently.

Any change in the inner list can force the outer list to remeasure, triggering cascading layout passes. As item counts grow, this directly impacts scroll smoothness.

2. Re-entrant layout and memory pressure

Expandable inner lists, dynamic item heights, or late data loading trigger repeated layout invalidations. On mobile hardware, that translates into extra CPU work and short-lived allocations, issues that surface as stutter or frame drops.

3. Gesture and scroll ownership conflicts

When both parent and child List View controls believe they own vertical scrolling, gesture arbitration becomes unpredictable. Users experience sticky scrolling, missed swipes, or inconsistent touch handling.

4. Accessibility and focus side effects

Keyboard navigation and accessibility tools struggle with nested scroll regions. Managing focus across multiple ListView instances often requires additional customization that offsets the original layout simplicity.

Designing hierarchy without Nesting Syncfusion ListView

The key architectural shift is this: hierarchy does not require nested ListView controls.

With Syncfusion’s ListView features, you can preserve structure while keeping a single, predictable virtualization and scrolling pipeline.

Grouping

Grouping is the most scalable alternative to nested lists. It is an organizational pattern that buckets items into labelled sections based on a shared key.

Instead of embedding ListViews, bind a single SfListView to a flat collection and group items using a shared key (for example, CategoryName). Group headers render inline, optionally as sticky headers, while all items scroll within a single virtualized surface.

Why grouping works well in Syncfusion ListView:

One virtualization pipeline.
Predictable measurement behavior.
Clear visual hierarchy without layout recursion.
Stable performance with large datasets.

This pattern fits catalogs, settings pages, and any screen where sectioning matters more than strict parent-child interaction.

Let’s implement the grouping feature in Syncfusion .NET MAUI ListView.

Step 1: Creating a data model

Start by creating a data model to bind to the ListView. Define a Product class with Name, Price, and CategoryName (used as the grouping key) in a Product.cs file, as shown in the code example below.

public sealed class Product
{
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public string CategoryName { get; set; } = string.Empty;
    public bool IsHeader { get; set; }
}

public sealed partial class Category : BindableObject
{
    public string Name { get; set; } = string.Empty;

    private bool isExpanded;
    public bool IsExpanded
    {
        get => isExpanded;
        set
        {
            if (isExpanded == value) return;
            isExpanded = value;
            OnPropertyChanged();
        }
    }

    public ObservableCollection<Product> Products { get; } = new();
}

Step 2: Populate the model collection in the ViewModel

Next, create a view model to supply grouped data. Build Categories and flatten the data into GroupedProducts (ObservableCollection) in CatalogViewModel.cs, assigning CategoryName to each item so grouping can be resolved at the list level, as shown in the code example below.

public class CatalogViewModel
{
    public ObservableCollection<Category> Categories { get; }
    public ObservableCollection<Product> GroupedProducts { get; }

    public CatalogViewModel()
    {
        Categories = new ObservableCollection<Category>
        {
            new Category
            {
                Name = "Featured",
                Products = // Add products here
                {
                }
            }
        };

        var flat = new List<Product>();
        foreach (var cat in Categories)
        {
            flat.Add(new Product
            {
                CategoryName = cat.Name,
                IsHeader = true
            });
            foreach (var p in cat.Products)
            {
                flat.Add(new Product
                {
                    Name = p.Name,
                    Price = p.Price,
                    CategoryName = cat.Name
                });
            }
        }

        GroupedProducts = new ObservableCollection<Product>(flat);
    }
}

Step 3: Binding the ViewModel and defining the item template

Define the XAML that renders a single, grouped list. Bind Syncfusion .NET MAUI ListView to GroupedProducts, configure grouping using CategoryName through a GroupDescriptor, and provide templates for group headers and list items, including optional sticky headers, as shown in the code example below.

XAML

<!-- Grouped List View with sticky headers (details in GitHub demo) -->
<sfListView:SfListView ItemsSource="{Binding GroupedProducts}"
                       IsStickyGroupHeader="True"
                       SelectionMode="None">
    <!-- sfListView:SfListView.DataSource with sfData:GroupDescriptor -->
    <!-- GroupHeaderTemplate: shows {Binding Key} -->
    <!-- ItemTemplate: shows product fields -->
</sfListView:SfListView>

Here’s a quick demo of the feature in action:

.NET MAUI ListView with Grouping Enabled

Expand/Collapse items using a single SfListView

Expand and collapse is a disclosure pattern that works particularly well with Syncfusion .NET MAUI ListView.

Instead of pushing users into nested lists or secondary views, parent rows reveal or hide related content inline. The ListView remains continuous, and users never lose scroll context.

To implement this feature, bind Syncfusion .NET MAUI List View to the Categories collection through the page’s BindingContext. Then define an ItemTemplate that renders a tappable category header and conditionally displays its child items when IsExpanded is true, as shown in the code example below.

XAML

<!-- reuse the Model and ViewModel from the Grouping section. -->
<!-- Expandable rows (details in GitHub demo) -->
<sfListView:SfListView ItemsSource="{Binding Categories}"
                       SelectionMode="None">
    <!-- ItemTemplate:
        - Header row with tap gesture or command
        - Divider line
        - Child items in a BindableLayout shown when IsExpanded -->
</sfListView:SfListView>

Expand/Collapse items in .NET MAUI ListView

Composite item template

Some screens are heterogeneous rather than hierarchical.

Using a DataTemplateSelector with Syncfusion ListView allows you to render different row types, headers, items, and dividers—inside a single ListView instance. The control still maintains one recycling and measurement path.

This pattern is ideal for:

Feed-style layouts.
Mixed content lists.
Scenarios where row structure varies by item state.

You gain flexibility without fragmenting virtualization across multiple controls.

Step 1: Defining the template selector

Create a template selector to render header and item rows differently within a single ListView. Define ProductTemplateSelector (e.g., ProductTemplateSelector.cs) that switches between HeaderTemplate and ItemTemplate based on the IsHeader property, as shown in the code example below.

public sealed class ProductTemplateSelector : DataTemplateSelector
{
    public DataTemplate? HeaderTemplate { get; set; }
    public DataTemplate? ItemTemplate { get; set; }

    protected override DataTemplate OnSelectTemplate(object? item, BindableObject container)
    {
        if (item is Product product && product.IsHeader)
        {
            return HeaderTemplate ?? ItemTemplate ?? new DataTemplate(() => new ContentView());
        }

        return ItemTemplate ?? HeaderTemplate ?? new DataTemplate(() => new ContentView());
    }
}

Read the full blog post on the Syncfusion website.

The Evolution of Syncfusion Agentic UI Builder with Agent Skills

Lucy Muturi — Mon, 01 Jun 2026 15:27:21 +0000

TL;DR: The latest Syncfusion Agentic UI Builder introduces embedded Syncfusion Agent Skills that help AI generate more organized UIs within the project. By grounding generation on the available Syncfusion component intelligence, developers can reduce post-generation cleanup and accelerate UI realization.

AI-assisted development has rapidly changed how developers build application UI. Modern coding assistants can generate layouts, dashboards, forms, and data experiences in seconds using natural-language prompts.

But as AI-generated UI becomes part of real-world enterprise processes, developers increasingly expect more than isolated snippets or visual scaffolding. They need generated UIs that are structured, framework-aware, responsive, maintainable, and ready for integration into actual applications.

That is the direction driving the latest evolution of Syncfusion^®Agentic UI Builder.

The newest release introduces embedded Syncfusion Agent Skills, a project-aware architecture designed to help AI generate more uniform, enterprise-focused interfaces using locally available Syncfusion component intelligence.

This evolution builds on the earlier orchestration capabilities of the UI Builder experience and enhances how AI understands, configures, and composes Syncfusion-powered app interfaces directly inside the developer pipeline.

The result is a more streamlined path from prompt to usable UI with improved consistency, reduced setup effort, and a smoother refinement experience for development teams.

Why enterprise UI generation requires more than snippets

While AI tools can quickly generate UI fragments, enterprise applications demand a much higher level of completeness and reliability.

The challenge is not generating UI, it’s making it work correctly within a real app context.

Enterprise interfaces must handle:

Complex layouts that adapt across devices,
Accurate and complete feature configuration,
Cohesive integration with app architecture,
Accessibility and compliance requirements, and
Long-term maintainability as the app evolves.

In practice, developers often spend significant time bridging the gap between generated output and production-ready UI. This includes fixing incomplete configurations, aligning layouts, wiring data interactions, and ensuring consistency across the application.

For example, a generated dashboard may include visual elements like charts or grids, but still require additional work to ensure:

Components are fully configured and functional,
Layout behavior remains consistent across screen sizes,
Features are properly integrated with the app, and
UI patterns align with project standards.

This gap between generated snippets and usable app interfaces is where most development effort is still spent and where improvements in AI-assisted UI generation make the biggest impact.

Introducing embedded Syncfusion Agent Skills

The latest Syncfusion UI Builder introduces embedded Syncfusion Agent Skills that provide locally available implementation guidance within the project environment.

Think of these skills as verified instruction packs that help AI understand how Syncfusion components should be configured and organized inside real applications.

Each skill can include:

Component APIs,
Setup guidance,
Required imports,
Feature configuration references,
Framework-specific patterns,
Accessibility recommendations, and
Layout composition guidance.

When UI Builder generates interfaces containing components such as DataGrid, Charts, Scheduler, Navigation Drawer, or Forms, the relevant Syncfusion Component Skills are automatically applied during generation.

This helps developers receive more cohesive UI scaffolding with minimized rework cycles.

How Syncfusion Agentic UI Builder has evolved

Earlier versions of Syncfusion UI Builder focused heavily on runtime coordination to help AI understand component behavior during generation.

That coordination model helped establish the foundation for AI-assisted Syncfusion UI generation.

As adoption expanded, teams increasingly looked for:

More project-aware generation,
Stronger customization capabilities,
Deeper alignment with internal standards, and
More streamlined local development experiences.

The addition of Agent Skills further evolves the architecture by bringing implementation guidance directly into the project environment.

This enables generation that is:

More grounded in the project context,
Easier to customize, and
Better aligned with production-scale applications.

Rather than changing the developer experience conceptually, the updated architecture enhances how UI Builder supports AI-assisted UI generation at scale.

Architecture comparison

Aspect	Earlier Runtime Retrieval Model	Skill-Based UI Builder
Component intelligence source	External services	Local embedded skills
API resolution	Runtime fetch	Local skill grounding
Enterprise compatibility	Environment dependent	Improved
Debugging effort	Higher	Reduced

MCP-based architecture

Embedded Agent Skills-based architecture

How the new architecture works

High-level flow of Agentic UI Builder architecture

This helps improve:

Generation uniformity,
Adaptability across devices,
Reliability,
Customization flexibility, and
Enterprise readiness.

What developers can build faster?

With the evolved architecture, Syncfusion UI Builder can scaffold more complete app UIs with significantly less manual setup.

You can quickly generate:

SaaS admin dashboards,
Analytics workspaces,
Reporting systems,
Approval workflows,
CRUD management portals,
Responsive forms, and
Data-heavy business applications.

Instead of manually assembling layouts, charts, grids, filters, themes, and navigation patterns, teams can generate production-ready UI foundations from natural-language prompts.

This allows developers to spend more time building product functionality and less time assembling repetitive UI infrastructure.

Read the full blog post on the Syncfusion website.

Angular Spreadsheet Freezing on Large Excel Imports? Here’s the Fix

Lucy Muturi — Fri, 17 Apr 2026 12:10:31 +0000

TL;DR: Large Excel imports in Angular Spreadsheet freeze the UI because synchronous XLSX parsing (styles, formats, objects) blocks the main thread. Optimize imports by disabling style/format parsing, enforcing server-side cell and file size thresholds, and using openFromJson with selective deserialization for predictable performance and lower memory usage.

Have you ever uploaded an Excel file and watched your web app freeze instantly? It happens more often when users try to import Excel files in Angular. A large workbook can easily slow down the browser, trigger memory spikes, or get stuck while reading the file, making the entire page feel unresponsive.

Most Angular apps freeze during large Excel imports because the browser tries to parse every cell, style, formula, and object on the main thread. This leads to long pauses, high memory usage, and unpredictable “page unresponsive” errors.

Syncfusion^® Angular Spreadsheet Editor avoids these issues by loading only what’s necessary, enforcing file size and data limits, and allowing large workbooks to open quickly via lightweight JSON loading rather than full XLSX parsing.

In this blog, you’ll learn three specific techniques to fix this:

Skip heavy formatting using IgnoreStyle and IgnoreFormat.
Prevent server overload using MaximumDataLimit and MaximumFileSize.
Load large workbooks faster using openFromJson with selective deserialization.

Let’s dive deeper into these techniques that make large Excel imports fast and reliable.

Why large Excel imports silently break web apps

Large Excel files don’t just “take longer.” They often trigger a chain reaction that feels like a crash:

The page freezes because parsing blocks the UI thread.
Memory jumps due to styles, formats, images, and workbook metadata.
Imports time out on slower machines or remote environments.
Users get no actionable error, just a stuck screen or killed tab.

This is especially common in enterprise scenarios where “normal” spreadsheets contain hundreds of thousands of cells plus formatting rules, validations, and embedded objects.

How Syncfusion Angular Spreadsheet eliminates large file import failures

Many apps fail because they load everything at once. Syncfusion Angular Spreadsheet Editor is designed to avoid that pattern by letting you:

Load only what you need (data vs. styling/features)
Enforce thresholds before a file overwhelms the system
Open workbooks from lightweight JSON for faster startup

Angular Spreadsheet with Styles and Formatting

Curious to see the Angular Spreadsheet in action? Explore the live demo.

Parsing options: Load only what you need

Most Excel imports fail not because of data volume alone, but because of formatting overhead. Styles, number formats, and empty-cell metadata dramatically increase parsing cost, even when your app only needs raw values.

Syncfusion solves this with WorkbookParseOptions. By enabling IgnoreStyle and IgnoreFormat properties on the server, the spreadsheet loads only raw data, skipping the formatting overhead entirely.

Here is a server-side example:

public IActionResult Open(IFormCollection openRequest) 
{
    OpenRequest open = new OpenRequest();
    ...
    // Enable parsing options to skip styles and formats for faster loading
    open.ParseOptions = new WorkbookParseOptions()
    { 
        IgnoreStyle = true, 
        IgnoreFormat = true
    }; 
    ...
    // Process and return the parsed workbook data
    return Content(Workbook.Open(open)); 
}

By disabling style and format parsing:

Only raw cell values are processed
JSON payload size is reduced
Memory usage drops significantly
Import time improves immediately

Note: These options are ideal when styles and number formats aren’t important for your use case, and the goal is to load the Excel data as quickly as possible.

What you gain

Faster file loading
Lower memory usage
Smaller JSON payloads sent to the client

This is ideal for “data pipeline” imports where formatting is irrelevant (finance exports, HR records, inventory loads).

Threshold limits: Stop the file before it crashes the app

Large Excel files don’t just overload the browser; they can spike server memory too. Without a safety check, a single oversized upload can silently degrade your entire application’s performance.

Syncfusion’s threshold limits give you a clear control point. You can define:

MaximumDataLimit: The maximum number of cells allowed.
MaximumFileSize: The maximum file size in bytes.

What happens when a limit is exceeded

An alert message appears: The file is large.
Cancel stops the import cleanly
OK continues (only if your app logic permits it)

This single check prevents crashes, timeouts, and memory overloads caused by unexpectedly large uploads, and gives users clarity rather than confusion.

You can configure the thresholds API on the server side using the following code example:

public IActionResult Open(IFormCollection openRequest)
{
    OpenRequest open = new OpenRequest();
    open.File = openRequest.Files[0];
    open.Guid = openRequest["Guid"];

    // Set maximum allowed number of cells
    open.ThresholdLimit.MaximumDataLimit = 1000000; // 1,000,000 cells

    // Set maximum allowed file size in bytes (e.g., 5MB)
    open.ThresholdLimit.MaximumFileSize = 5000000;

    var openbook = Content(Workbook.Open(open));
    return openbook;
}

The above code example enforces a safety gate before parsing becomes expensive, protecting both the user experience and backend stability.

File size warning in Angular Spreadsheet

JSON serialization: Parse once, open instantly

Parsing a full XLSX file on every file open is expensive. If the workbook includes charts, images, conditional formatting, or complex styles, that overhead adds up fast.

Syncfusion Angular Spreadsheet solves this with JSON serialization options. These let you exclude specific features, such as styles, formats, charts, images, wrap, and more, from the Workbook JSON object when opening it via the openFromJson method.

Why JSON-based loading is faster

Using openFromJson, you can:

Avoid repeated XLSX parsing
Exclude features your app doesn’t need
Reduce JSON size and processing time
Improve load speed for large or complex workbooks

Syncfusion also supports selective deserialization. You can choose exactly which parts of the JSON to ignore during loading. Previously, openFromJson always loaded every element: styles, formulas, conditional formatting, charts, images, validations, and Notes. Now you control that explicitly.

Client-side example:

// Load workbook JSON — ignore styles for faster rendering of the spreadsheet
.openFromJson(
    { file: fileJson },
    { ignoreStyle: true }
);

This gives you fine-grained control over the loading process, exactly what you need when you import large Excel files in Angular apps with complex structures.

Want to know more details about these techniques? Explore the full Angular Spreadsheet documentation.

Configuring Syncfusion Angular Spreadsheet for large file imports

Here’s how to integrate the Syncfusion Spreadsheet into your Angular app from scratch.

Step 1: Install Angular CLI

You can use Angular CLI to set up your Angular applications. To install Angular CLI, use the following command:

Bash

npm install -g @angular/cli

Step 2: Create a new Angular application

You can create a new Angular application using the following Angular CLI command:

Bash

ng new my-app

Choose your preferred stylesheet format (CSS/SCSS) and SSR options when prompted.

For more details, refer to the blog post at Syncfusion.com

.NET MAUI State Management: From ViewModels to App Stores

Lucy Muturi — Thu, 16 Apr 2026 13:46:15 +0000

TL;DR: Start with MVVM and data binding for page-level state, apply Visual State Manager for visual-only changes, and rely on DI-backed app-wide stores for shared state. For highly interactive or complex flows, MVU or reducer-style unidirectional updates offer better predictability.

State is the backbone of every .NET MAUI application. It determines what users see, how the UI reacts to interactions, and how consistently data flows across screens. Whether it’s the text inside an Entry, the enabled state of a button, or the user session shared across pages, effective state management ensures your UI remains predictable, testable, and easy to maintain.

.NET MAUI does not enforce a single state management solution. Instead, it provides flexible building blocks that allow you to choose the right approach based on your app’s complexity. This article walks through the most practical and production-ready ways to manage state in .NET MAUI, from simple ViewModel state to shared app-wide stores, and helps you decide when to use each.

Why state management in MAUI matters

In real apps, state stops being “just a couple of properties” fast:

Authentication affects navigation, headers, API calls, and cached data.
Offline support introduces queues and retry logic.
Multiple pages need the same data (profile, cart, preferences).
Background sync and push notifications mutate state while the user is elsewhere.
Multi-window scenarios need a shared but safe global state.

If state changes can happen anywhere, debugging becomes guesswork. The goal is not a perfect architecture; it’s predictable updates and a UI that stays consistent.

Recommended state management approaches in .NET MAUI

Most real-world MAUI apps rely on a combination of the following patterns:

MVVM with data binding for page-level and feature-level state.
MVU-style updates for predictable, unidirectional state transitions.
Visual State Manager (VSM) for purely visual UI changes.
Dependency Injection (DI) for shared and app-wide state.

Rather than treating these as competing patterns, think of them as complementary tools. The key is applying each one where it fits best.

MVVM + INotifyPropertyChanged: The foundation

MVVM (Model-View-ViewModel) is the most widely used pattern in .NET MAUI and forms the foundation of state management for most applications.

In MVVM:

The View defines the UI using XAML.
The ViewModel holds the state and exposes it through bindable properties.
The Model represents your domain or business data.

The View never directly manipulates state. Instead, it binds to ViewModel properties. When the ViewModel changes, the UI updates automatically through data binding.

Here’s the example MVVM implementation:

ViewModel.cs

public class ViewModel : INotifyPropertyChanged
{
    private string name;
    public string Name
    {
        get => name;
        set
        {
            if (name != value)
            {
                name = value;
                OnPropertyChanged();
            }
        }
    }
    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}

MainPage.xaml

<Label Text="{Binding Name}" FontSize="20" />

MainPage.xaml.cs

public partial class MainPage : ContentPage
{
    public MainPage()
    {
        InitializeComponent();
        BindingContext = new ViewModel { Name = "Maui" };
    }
}

When to use:

Forms, lists, and CRUD screens
Input validation and command-based interactions
Navigation flows and page-level logic

MVVM is ideal when you want strong separation of concerns, easy unit testing, and straightforward data binding.

MVVM architecture flow in .NET MAUI

MVU (Model-View-Update): Predictable state flow

MVU introduces a functional, unidirectional approach to state management. Instead of mutating properties across different objects, MVU treats state as an immutable model that changes only through explicit updates.

The flow looks like this:

Model → View → Message → Update → Model

Model represents the entire state snapshot.
View renders UI based solely on the model.
Update receives user actions or events messages and returns a new model.

Example

public record AppModel(int Count);
public enum Msg { Increment }

public static AppModel Update(AppModel model, Msg msg) =>
    msg == Msg.Increment ? model with { Count = model.Count + 1 } : model;

Because all state changes occur in a single Update function, MVU delivers predictable behavior and prevents unintended state mutations. It works best for UIs with complex, interdependent interactions.

When to use

Highly interactive screens
Complex workflows with many dependent UI updates
Scenarios where unidirectional data flow is preferred

MVU is less common than MVVM in MAUI, but it shines in advanced use cases and pairs well with frameworks like Comet or MauiReactor.

MVU architecture flow in .NET MAUI

Visual State Manager (VSM): Declarative UI states

Visual State Manager (VSM) is designed specifically for visual changes, not business logic. It allows you to define named visual states, such as Normal, Pressed, or Selected, and let VSM handle the transitions.

The View (XAML) declares VisualStateGroups and individual VisualStates, each containing the appearance rules for that state.
State changes are triggered through bindings, behaviors, or code.

Instead of manually toggling properties across controls, you switch visual states and let VSM handle the transitions. This keeps your UI logic organized, consistent, and easy to maintain.

Example:

XAML

<ContentView>
    <BoxView x:Name="box"
             WidthRequest="120"
             HeightRequest="120" />
    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup Name="SelectionStates">
            <VisualState Name="Normal">
                <VisualState.Setters>
                    <Setter TargetName="box"
                            Property="BackgroundColor"
                            Value="LightGray" />
                </VisualState.Setters>
            </VisualState>
            <VisualState Name="Selected">
                <VisualState.Setters>
                    <Setter TargetName="box"
                            Property="BackgroundColor"
                            Value="LightBlue" />
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
</ContentView>

When to use

Visual feedback such as selection, focus, or disabled states.
Simple animations or appearance changes.
Keeping UI logic declarative and XAML-focused.

Avoid placing business logic inside visual state transitions.

Visual State Manager flow in .NET MAUI

For more details, refer to the blog post at Syncfusion.com

.NET MAUI ListView vs CollectionView: How Syncfusion ListView Performs Better

Lucy Muturi — Thu, 16 Apr 2026 12:16:44 +0000

TL;DR: Many .NET MAUI lists falter under real-world demands. This comparison reveals how Syncfusion .NET MAUI ListView confidently manages grouping, gestures, infinite scroll, and large data, delivering smoother scrolling, fewer allocations, and less glue code than CollectionView.

When CollectionView hits its limits, here’s the ListView built for real apps

If you’ve built more than a demo app with .NET MAUI, you’ve probably hit this point:

“The list worked great—until we added more features.”

The .NET MAUI CollectionView is a solid starting point, but it starts to show strain as an app grows.

Add grouped data, sticky headers, swipe actions, drag‑and‑drop, or infinite scrolling, and CollectionView often turns into a web of event handlers, state management, and performance trade‑offs. The result is familiar: more code to maintain, tougher debugging, and a list of experiences that feel sluggish on real devices.

Syncfusion^® .NET MAUI ListView takes a different approach.

Instead of making you piece together common list behaviors, it delivers them out of the box using built‑in properties, MVVM‑friendly commands, and a virtualization engine designed for large datasets. The payoff is immediate: cleaner code, smoother scrolling, and significantly lower memory usage.

This post compares both controls using the same real‑world scenario and shows where Syncfusion .NET MAUI ListView saves time, code, and memory.

How Syncfusion .NET MAUI ListView outshines Collection View

When comparing these two controls, the Syncfusion .NET MAUI ListView stands out with built‑in features that reduce extra code and deliver smoother performance:

Grouping with sticky headers: Pins the current group header at the top while scrolling.
Swipe actions: Reveals quick actions by swiping left or right on an item.
Drag-and-drop reorder: Users can reorder items by dragging them.
Incremental loading: Loads the page on demand for faster, lighter lists.
Layout choices: Switches between list and grid presentations to fit the content.
Item sizing and virtualization: Uses fixed or measured row heights to keep scrolling smooth.

Syncfusion .NET MAUI ListView vs .NET MAUI CollectionView: Real feature comparison

To keep this comparison honest, we are going to test both controls using the same MVVM book list, no shortcuts, no artificial demos. Each section answers the kinds of questions developers actually run into when building production apps:

How much effort does sticky grouping really take?
How quickly does swipe support get messy?
What breaks when you add drag‑and‑drop reordering?
And what happens to memory usage as the list grows?

Along the way, you’ll see where Syncfusion ListView handles these scenarios with built‑in properties and templates, and where Collection View requires extra event wiring, state tracking, and custom logic.

Instead of theory or feature checklists, this walkthrough shows real code, real UI behavior, and real performance numbers, so you can decide which control fits your feature needs and performance goals based on facts rather than assumptions.

1. Grouping with sticky headers

To see the difference clearly, let’s compare how each control handles this feature:

a) Syncfusion .NET MAUI ListView

Sticky headers are a built-in feature in Syncfusion .NET MAUI ListView. As you scroll, the current group title stays pinned at the top, so users always know where they are. A single setting enables it, and grouping by the first letter feels effortless.

Here’s the code you need:

XAML

<listView:SfListView x:Name="listView"
                      ItemsSource="{Binding BookInfo}"
                      IsStickyGroupHeader="True">

    <listView:SfListView.GroupHeaderTemplate>
        <DataTemplate>
            <Grid BackgroundColor="#F2F2F2" Padding="8,4">
                <Label Text="{Binding Key}" VerticalTextAlignment="Center" FontAttributes="Bold" />
            </Grid>
        </DataTemplate>
    </listView:SfListView.GroupHeaderTemplate>
</listView:SfListView>

// Group items by the first character of BookName (uppercase).
listView.DataSource.GroupDescriptors.Add(new GroupDescriptor()
{
    PropertyName = "BookName",
    KeySelector = (object obj1) =>
    {
        var item = (obj1 as BookInfo);
        return item.BookName[0].ToString();
    }
});

b) .NET MAUI CollectionView

You need to manage sticky headers manually. On every scroll, you recalculate which group is visible and update the header. It works but requires extra housekeeping.

Refer to the following code.

XAML

<Grid RowDefinitions="Auto,*">
    <Border BackgroundColor="#F2F2F2" Padding="8,4">
        <Label Text="{Binding CurrentGroupName}" FontAttributes="Bold"/>
    </Border>

    <CollectionView x:Name="List"
                    Grid.Row="1"
                    ItemsSource="{Binding BookGroups}"
                    IsGrouped="True"
                    SelectionMode="Multiple"
                    ItemSizingStrategy="MeasureFirstItem"
                    Scrolled="OnCollectionViewScrolled">
        <CollectionView.GroupHeaderTemplate>
            <DataTemplate>
                <Grid BackgroundColor="#f2f2f2" Padding="12">
                    <Label Text="{Binding Name}" FontAttributes="Bold" />
                </Grid>
            </DataTemplate>
        </CollectionView.GroupHeaderTemplate>
    </CollectionView>
</Grid>

Loaded += OnLoaded;

private void OnLoaded(object sender, EventArgs e)
{
    UpdateCurrentGroupHeader();
}

private void OnCollectionViewScrolled(object sender, ItemsViewScrolledEventArgs e)
{
    UpdateCurrentGroupHeader(e.FirstVisibleItemIndex);
}

private void UpdateCurrentGroupHeader(int firstVisibleIndex = 0)
{
    if (Vm == null || Vm.BookGroups == null || Vm.BookGroups.Count == 0)
        return;

    var index = firstVisibleIndex < 0 ? 0 : firstVisibleIndex;

    // Map to group by flattening groups until we cover firstVisibleIndex
    int cursor = 0;
    foreach (var group in Vm.BookGroups)
    {
        int groupCount = group.Count;
        if (index < cursor + groupCount)
        {
            Vm.CurrentGroupName = group.Name;
            return;
        }
        cursor += groupCount;
    }

    // Fallback
    Vm.CurrentGroupName = Vm.BookGroups[0].Name;
}

2. Swipe actions

Both controls support swipe gestures, but the way they implement and simplify quick actions differs significantly:

a) Syncfusion .NET MAUI ListView

Swipe gestures reveal sleek, ready-to-use actions like Favorite and Delete. Templates keep the UI consistent, and commands bind directly to your ViewModel. The experience feels native across platforms.

Refer to the following code example.

XAML

<listView:SfListView x:Name="listView"
                      ItemsSource="{Binding BookInfo}"
                      AllowSwiping="True">

    <listView:SfListView.StartSwipeTemplate>
        <DataTemplate>
            <Grid BackgroundColor="#E8F5E9" Padding="12">
                <Button Text="Favourite"
                        FontSize="12"
                        Padding="10"
                        TextColor="White"
                        BackgroundColor="#2E7032"/>
            </Grid>
        </DataTemplate>
    </listView:SfListView.StartSwipeTemplate>

    <listView:SfListView.EndSwipeTemplate>
        <DataTemplate>
            <Grid BackgroundColor="#FFEBEE" Padding="12">
                <Button Text="Delete"
                        TextColor="White"
                        BackgroundColor="#C62828"
                        Command="{Binding BindingContext.DeleteCommand, Source={x:Reference listView}}"
                        CommandParameter="{Binding .}"/>
            </Grid>
        </DataTemplate>
    </listView:SfListView.EndSwipeTemplate>
</listView:SfListView>

b) .NET MAUI CollectionView

You wrap each item in a Swipe View and define left/right actions yourself. Flexible, but repetitive, more template code for the same result.

Here’s how to implement this feature:

XAML

<CollectionView ItemsSource="{Binding BookInfo}">
  <CollectionView.ItemTemplate>
    <DataTemplate>
      <SwipeView>
        <SwipeView.LeftItems>
          <SwipeItems Mode="Reveal">
            <SwipeItem Text="Fav" BackgroundColor="#FFE08A"
                       Command="{Binding FavoriteCommand}" CommandParameter="{Binding .}"/>
          </SwipeItems>
        </SwipeView.LeftItems>
        <SwipeView.RightItems>
          <SwipeItems Mode="Reveal">
            <SwipeItem Text="Delete" BackgroundColor="#FFCDD2"
                       Command="{Binding DeleteCommand}" CommandParameter="{Binding .}"/>
          </SwipeItems>
        </SwipeView.RightItems>
        <Grid Padding="12,8"><Label Text="{Binding BookName}"/></Grid>
      </SwipeView>
    </DataTemplate>
  </CollectionView.ItemTemplate>
</CollectionView>

3. Drag-and-drop reordering

This feature shows a clear difference in how each control handles item movement and user interaction:

a) Syncfusion .NET MAUI ListView

Reordering is built in. You can press, drag, and release; items move exactly where expected without juggling gestures or indexes, as shown in the code below.

XAML

<listView:SfListView x:Name="listView"
                      ItemsSource="{Binding BookInfo}"
                      DragStartMode="OnHold">

b) .NET MAUI CollectionView

You wire up drag/drop events, manage indices, and refresh grouping after reordering. Powerful, but more moving parts.

Here’s how you can do it in code:

XAML

<CollectionView x:Name="List"
                Grid.Row="1"
                ItemsSource="{Binding BookGroups}"
                IsGrouped="True"
                SelectionMode="Multiple"
                ItemSizingStrategy="MeasureFirstItem"
                Scrolled="OnCollectionViewScrolled">

    <CollectionView.ItemTemplate>
        <DataTemplate>
            <SwipeView>
                <Grid Padding="12" RowDefinitions="Auto,Auto" ColumnDefinitions="Auto,*" HeightRequest="70">
                    <Grid.GestureRecognizers>
                        <DropGestureRecognizer AllowDrop="True" DragOver="OnDragOver" Drop="OnDrop" />
                    </Grid.GestureRecognizers>

                    <!-- Drag handle icon -->
                    <Label Grid.RowSpan="2" Grid.Column="0" VerticalOptions="Center" Margin="0,0,8,0" Text="≡≡" FontSize="18" Opacity="0.6">
                        <Label.GestureRecognizers>
                            <DragGestureRecognizer CanDrag="True" DragStarting="OnDragStarting" DropCompleted="OnDropCompleted" />
                        </Label.GestureRecognizers>
                    </Label>

                    <Label Text="{Binding BookName}" Grid.Row="0" Grid.Column="1" FontAttributes="Bold" />
                    <Label Text="{Binding BookDescription}" Grid.Row="1" Grid.Column="1" Opacity="0.7" />
                </Grid>
            </SwipeView>
        </DataTemplate>
    </CollectionView.ItemTemplate>
</CollectionView>

private void OnDragStarting(object sender, DragStartingEventArgs e)
{
    if (sender is Element element && element.BindingContext is BookInfo item)
    {
        e.Data.Properties["item"] = item;
    }
}

private void OnDrop(object sender, DropEventArgs e)
{
    if (Vm == null) return;
    if (!e.Data.Properties.TryGetValue("item", out var payload) || payload is not BookInfo source)
        return;

    if (sender is Element element && element.BindingContext is BookInfo target && !ReferenceEquals(source, target))
    {
        var list = Vm.BookInfo;
        var sourceIndex = list.IndexOf(source);
        var targetIndex = list.IndexOf(target);
        if (sourceIndex >= 0 && targetIndex >= 0)
        {
            // Normalize target index when removing earlier item affects index
            if (sourceIndex < targetIndex)
                targetIndex--;

            list.RemoveAt(sourceIndex);
            list.Insert(targetIndex, source);
            // Update stable order indices and rebuild grouping to reflect new order in the UI
            Vm.ReindexOrders();
            Vm.RefreshGroups();
        }
    }
}

4. Incremental loading

Handling large datasets highlights how each control approaches infinite scrolling and data fetch efficiency:

a) Syncfusion .NET MAUI ListView

Infinite scrolling is simple. The control fetches more items as you near the end, with a built-in busy indicator. A single command controls when and how much to load.

Refer to the following code examples for feature implementation.

XAML

<listView:SfListView x:Name="listView"
                      ItemsSource="{Binding BookInfo}"
                      LoadMoreOption="Manual"
                      LoadMorePosition="End"
                      LoadMoreCommand="{Binding LoadMoreItemsCommand}"
                      LoadMoreCommandParameter="{Binding Source={x:Reference listView}}">

public ICommand LoadMoreItemsCommand { get; }

LoadMoreItemsCommand =
    new Command<object>(LoadMoreItems, CanLoadMoreItems);

private bool CanLoadMore() => BookInfo.Count < totalItems;

private bool CanLoadMoreItems(object obj) => CanLoadMore() && !IsLoading;

private async void LoadMoreItems(object obj)
{
    if (!CanLoadMore() || IsLoading)
    {
        return;
    }
    else
    {
        listView.IsLazyLoading = true;
        await Task.Delay(2000);
        listView.IsLazyLoading = false;
    }

    AddBooks(currentIndex, PageSize);
    currentIndex += PageSize;
}

b) .NET MAUI CollectionView

You implement a “ Load More ” footer and spinner, track remaining items, and manage progress state. Clear and explicit, but heavier on logic.

Here’s the code you need for quick implementation:

XAML

<CollectionView x:Name="List"
                 ItemsSource="{Binding BookGroups}">

    <!-- Manual Load More footer to mirror List View's LoadMoreOption=Manual at End -->
    <CollectionView.Footer>
        <Grid Padding="12" BackgroundColor="Transparent" HorizontalOptions="Center" RowDefinitions="Auto,Auto" ColumnDefinitions="Auto,Auto">
            <Button Text="Load More"
                    Grid.Row="0" Grid.ColumnSpan="2"
                    HorizontalOptions="Center"
                    IsEnabled="{Binding HasMoreItems}"
                    Command="{Binding LoadMoreItemsCommand}"
                    CommandParameter="{Binding Source={x:Reference List}}" />
            <ActivityIndicator Grid.Row="1" Grid.ColumnSpan="2"
                               IsVisible="{Binding IsLoading}"
                               IsRunning="{Binding IsLoading}" />
        </Grid>
    </CollectionView.Footer>
</CollectionView>

public ICommand LoadMoreItemsCommand { get; }

LoadMoreItemsCommand =
    new Command<object>(LoadMoreItems, CanLoadMoreItems);

private bool CanLoadMore() => BookInfo.Count < totalItems;

private bool CanLoadMoreItems(object obj) => CanLoadMore() && !IsLoading;

private async void LoadMoreItems(object obj)
{
    if (!CanLoadMore() || IsLoading)
    {
        return;
    }
    else
    {
        // CollectionView path uses the footer ActivityIndicator bound to IsLoading
        IsLoading = true;
        await Task.Delay(2000);
        IsLoading = false;
    }

    AddBooks(currentIndex, PageSize);
    currentIndex += PageSize;
    RebuildGroups();
}

For more details, refer to the blog post at Syncfusion.com

Spec-Driven Development with Markdown for AI Workflows

Lucy Muturi — Thu, 02 Apr 2026 07:23:10 +0000

TL;DR: Spec-driven development uses Markdown specifications and Code Studio prompt files as a single source of truth, letting AI reliably generate, test, review, and deploy code while preserving context. This blog shows practical prompt files and workflows, plus project structure and best practices for building a real-time project.

AI revolutionizes software development but loses context between chats, forgets earlier architectural decisions, and produces contradictory implementations unless you keep re-explaining the same requirements.

Spec-driven development treats Markdown specifications as your single source of truth. Rather than repeating requirements in AI conversations, you maintain a single living document that captures what your application does, how it behaves, and why.

Syncfusion ^®Code Studio makes this even easier with a prompt.md files (and Custom Agents), workflow files that tell your AI assistant exactly what to do at each development stage. This enables seamless specification-to-code compilation, code reviews, testing, and deployment workflows.

This blog post will guide you through implementing a practical spec-to-code workflow using prompt.md templates while building a real-world analytics dashboard example.

Why AI-assisted development breaks down

The core problem: AI context loss

When working with traditional AI‑assisted development, the AI often generates code in isolation without retaining or referencing the broader project context.

Example :

You ask for a feature (e.g., authentication).
The AI generates code in isolation.
Later, you ask for changes, and the AI forgets earlier constraints (tenancy, RBAC, security rules, naming conventions).
You repeat requirements and still get drift.

What is spec-driven development?

Spec-driven development is a methodology where:

The specification is the source code. Your Markdown files describe the complete application design (behavior, APIs, constraints, and acceptance criteria) in plain English mixed with structured data. AI generates implementation; Code Studio’s Custom Agents compile your specification into working code.
Every AI task references the same spec. You reduce contradictions and rework.
Documentation stays aligned. The spec evolves alongside the code rather than becoming stale.

Example:

User: Build me a user authentication module.

AI: Generates authentication code

Spec‐driven development ensures the AI always has access to the relevant specifications. This means the generated code is not only functional but also aligned with architectural requirements, security standards, and organizational workflows:

# User Authentication Module Specification
## Overview
Multi-tenant SaaS application requiring OAuth 2.0 with role-based access control (RBAC) 
across 10,000+ organizations.
## RBAC Structure
- Organization Admin: Full access to org settings
- Team Lead: Manage team members and reports
- Member: Read-only access to team data

This format makes requirements explicit, so code generation and reviews can consistently validate against it.

How spec-driven development with Markdown works in Code Studio

What are prompt.md files?

Prompt files are workflow specifications written in Markdown that tell Code Studio’s AI what to do at each stage of development. They are the primary tool for automating your development process.

Key features:

Repeatable instructions: Store prompts and reusable specifications to ensure consistent execution across projects.
Task automation: Automate critical stages such as compilation, testing, code review, and deployment for faster delivery.
Tool access: Provide AI with direct access to file operations, terminal commands, and web search for comprehensive workflow support.
Reusable workflows: Share and apply prompt files across teams and projects to standardize development practices.
Version control: Manage and track prompt files in Git alongside source code for full history and collaboration.

Prompt.md file format (template)

All prompt files follow this structure:

---
name: prompt file name 
mode: agent
description: Brief description of what this prompt does
---

# Main Task Title
Step-by-step instructions for the AI.
- Use bullet points for clarity
- Include specific file paths
- Reference specifications
- Define expected outputs

This structure is simple, but it’s the key to making AI output consistent and reviewable.

Spec-driven development with Markdown: Project setup (dashboard example)

Creating a complete dashboard project with the help of prompt.md files.

Recommended project structure

analytics-dashboard/

├──. codestudio/

│ └── prompts/

│ ├── compile.prompt.md

│ ├── lint.prompt.md

│ └── test.prompt.md

├── src/

│ ├── components/

│ │ ├── Dashboard.tsx

│ │ ├── Chart.tsx

│ │ └── Widget.tsx

│ └── types/

│ └── dashboard. types.ts

├── tests/

│ ├── dashboard.test.ts

│ └── api.test.ts

├── package. json

└── tsconfig. json

Note: Keep prompts in .codestudio/prompts/ so they’re easy to find, review, and run consistently.

Create your prompt files

To create Custom Prompts in Code Studio, follow these steps:

Open Chat Window.
Select Prompt Files.
Click + New Prompt File and choose the location based on your preference.
Type prompt file name.

For more insights, see our documentation on configuring custom prompts.

Creating Custom Prompt Files in Code Studio

Create the .codestudio/prompts/ folder and create these files:

compile.prompt.md: Compile spec to code.
dashboard.prompt.md: The dashboard specification.
review.prompt.md: Code review against spec.
security.prompt.md: Security audit.
test.prompt.md: Test generation.
lint-spec.prompt.md: Spec linting.

Note: You can find all these sample prompt files in this repository.

For more details, refer to the blog post at Syncfusion.com