DEV Community: Syncfusion, Inc.

How to Import Excel and CSV Data into a .NET MAUI DataGrid

Jollen Moyani — Thu, 15 Oct 2026 12:44:18 +0000

TL;DR: Learn how to import Excel and CSV files into a .NET MAUI DataGrid using FilePicker, Syncfusion XlsIO, and a lightweight CSV parser. The imported data is converted into a DataTable and displayed in an interactive DataGrid with sorting, filtering, grouping, and editing.

Need to display data from Excel and CSV files directly in your .NET MAUI application? Instead of requiring users to open these files in separate applications, you can import them and display the data in a DataGrid, allowing users to work with it directly within your app.

In this blog, we’ll build an import process using the Syncfusion .NET MAUI DataGrid. We’ll use the .NET MAUI FilePicker to select files, Syncfusion XlsIO to read Excel data, and a CSV parser to process CSV files. Both formats will be converted into a DataTable and displayed in the DataGrid.

The import pipeline is simple:

Pick an Excel or CSV file → Process the data → Store it in a DataTable → Show it in the DataGrid

What we’ll build

The application will allow users to:

Select an Excel or CSV file from their device.
Read Excel data using Syncfusion XlsIO.
Parse CSV data.
Convert the imported data into a DataTable.
Display the data in the Syncfusion DataGrid.
View the number of imported rows and columns.
Receive feedback when an import fails.

Once the data is displayed, you can configure the DataGrid to support features such as sorting, filtering, grouping, and editing.

Why import Excel and CSV data into a .NET MAUI DataGrid?

Excel and CSV files are convenient for storing and sharing tabular data. However, users may need more than a way to open these files. They may want to search, filter, sort, or edit the data directly within an application.

Importing the data into a DataGrid provides a way to work with it inside the app.

The key is to separate file processing from data display. First, read the file and prepare the data. Then, bind the resulting data to the DataGrid.

Let’s implement this process step by step.

Implement Excel and CSV import in a .NET MAUI DataGrid

Prerequisites

Before getting started, make sure your .NET MAUI project has the required workload installed.

Add the following NuGet packages:

Syncfusion’s .NET MAUI examples use XlsIO to read Excel files and export worksheet data to a DataTable, which can then be assigned to the DataGrid’s ItemsSource.

1. Create the data model

The imported data needs to be available to the UI so that the application can track changes to the data property.

Create a model that implements INotifyPropertyChanged:

public class Model : INotifyPropertyChanged
{
    // Raised when a property value changes to notify bound UI elements.
    public event PropertyChangedEventHandler? PropertyChanged;
}

In this example, the DataTable provides a common structure for both Excel and CSV data.

2. Create the ViewModel for file import

Next, we’ll handle file selection and data import.

The ViewModel will:

Open the file picker.
Determine whether the selected file is an Excel or CSV file.
Read the file.
Convert its contents into a DataTable.
Return the imported data to the UI.

This keeps the file-import logic separate from the DataGrid display.

Import data from Excel

For Excel files, Syncfusion XlsIO reads the workbook and exports the worksheet data to a DataTable.

private static DataTable ImportFromExcel(Stream excelStream)
{
    using var memory = new MemoryStream();

    excelStream.CopyTo(memory);
    memory.Position = 0;

    using var excelEngine = new Syncfusion.XlsIO.ExcelEngine();

    var xlsApp = excelEngine.Excel;
    xlsApp.DefaultVersion = Syncfusion.XlsIO.ExcelVersion.Xlsx;

    var workbook = xlsApp.Workbooks.Open(memory);
    var sheet = workbook.Worksheets[0];

    var dataTable = sheet.ExportDataTable(
        sheet.UsedRange,
        Syncfusion.XlsIO.ExcelExportDataTableOptions.ColumnNames);

    // Remove completely empty rows.
    for (int i = dataTable.Rows.Count - 1; i >= 0; i--)
    {
        bool empty = true;

        foreach (var obj in dataTable.Rows[i].ItemArray)
        {
            if (obj is not null &&
                obj is not DBNull &&
                !(obj is string s && string.IsNullOrWhiteSpace(s)))
            {
                empty = false;
                break;
            }
        }

        if (empty)
        {
            dataTable.Rows.RemoveAt(i);
        }
    }

    return dataTable;
}

The important part is ExportDataTable. It converts the worksheet’s used range into a tabular structure that can be used as the DataGrid’s data source. This is also the approach shown in Syncfusion’s documented Excel-to-MAUI-DataGrid example.

The code selects the first worksheet and treats its first exported row as the column names. It also removes completely empty rows before displaying the data.

Import data from CSV

CSV files do not require an Excel workbook. We can read them directly from the selected stream and convert their contents into a DataTable.

private static DataTable ImportFromCsv(Stream csvStream)
{
    // CSV import implementation:
    // 1. Read the CSV file from the provided stream.
    // 2. Extract column headers from the first row.
    // 3. Create DataTable columns based on the headers.
    // 4. Read each subsequent row and populate the DataTable.
    // 5. Return the populated DataTable.
}

Here, the first row is treated as the column header. The code also handles duplicate column names by generating unique names and fills missing cells with empty strings.

Note: The **ParseCsvLine* helper used in this implementation must be included in the complete sample repository.*

3. Load the selected file

Now, we’ll connect the .NET MAUI FilePicker to the Excel and CSV import methods.

The .NET MAUI FilePicker allows users to select a file from their device. The following method configures the supported file types, opens the selected file as a stream, and calls the appropriate import method.

public async Task<DataTable?> ImportFromFilePickerAsync()
{
    // Import data from the selected file and return it as a DataTable.
}

The import logic now has a clear responsibility:

FilePicker selects the file.
The file extension determines which import method to call.
The selected method reads the file and returns a DataTable.

The DataGrid can use the same data structure regardless of whether the user selects an Excel or CSV file.

Note: This example supports *.xlsx** and .csv files. The Excel import reads the first worksheet, and the CSV import treats the first row as the column header.*

4. Build the .NET MAUI DataGrid UI

With the import logic ready, let’s create a simple UI that lets users select a file and view the imported data.

The UI needs two primary elements:

An Import from File button.
A Syncfusion DataGrid to display the imported records.

<Grid Padding="16" RowSpacing="12">

    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>

    <Button Grid.Row="0"
            WidthRequest="300"
            HeightRequest="50"
            Text="Import from File"
            Clicked="OnImportClicked" />

    <syncfusion:SfDataGrid Grid.Row="1"
                           x:Name="DataGrid"
                           ColumnWidthMode="Fill"
                           HeaderRowHeight="40"
                           RowHeight="40" />

</Grid>

The button starts the file-selection process, while the DataGrid displays the imported data.

Connect the import button to the DataGrid

Add the following event handler:

private async void OnImportClicked(object sender, EventArgs e)
{
    try
    {
        var table = await _service.ImportFromFilePickerAsync();

        if (table is null)
        {
            return;
        }

        DataGrid.Columns.Clear();
        DataGrid.ItemsSource = table.DefaultView;

        ViewModel.Items = table;

        await DisplayAlertAsync(
            "Success",
            $"Imported {table.Rows.Count} rows and {table.Columns.Count} columns.",
            "OK");
    }
    catch (Exception ex)
    {
        await DisplayAlertAsync(
            "Import Failed",
            ex.Message,
            "OK");
    }
}

The key line is:

DataGrid.ItemsSource = table.DefaultView;

This assigns the imported data to the DataGrid through the DataTable’s default view.

After a successful import, the application displays the number of imported rows and columns. If the user cancels file selection, the method returns without displaying a success message.

If an exception occurs during selection or processing, the application displays an error alert.

See the import flow in action

When you run the sample, the application displays an Import from File button.

Select an Excel or CSV file. The application reads the file, converts its contents into a DataTable, and assigns the result to the DataGrid. A success message displays the number of imported rows and columns.

The result is a DataGrid containing the imported data, ready for further interaction.

Import Excel and CSV data into a .NET MAUI DataGrid

Handling the imported data

Once the data is displayed, you can extend the DataGrid configuration to support features based on your application’s requirements, including:

Sorting.
Filtering.
Grouping.
Editing.
Custom column behavior.
Data validation and application-specific processing.

Because both file formats are converted into a DataTable, the same data-binding approach can be used regardless of the original file format.

GitHub reference

You can explore the complete sample, including the file-import logic and DataGrid implementation, in the GitHub repository.

Frequently Asked Questions

Q1: What file formats are supported?

The sample supports Excel(.xlsx) and CSV(.csv) files. The file picker is configured to display these file types on the supported platforms.

To support additional formats, update the file-picker configuration and add the corresponding processing logic.

Q2: Which NuGet packages are required?

The sample uses: Syncfusion.Maui.DataGrid and Syncfusion.XlsIO.NETCore. The .NET MAUI workload is also required.

For Excel import, XlsIO provides the APIs used to open the workbook and export worksheet data to a DataTable.

Q3: How is the imported data bound to the DataGrid?

Both Excel and CSV data are converted into a DataTable. The resulting DataView is assigned to the DataGrid’s ItemsSource:

DataGrid.ItemsSource = table.DefaultView;

This provides a common data source for both file formats.

Q4: Does the import handle empty rows and duplicate headers?

For Excel files, the sample removes completely empty rows after exporting the worksheet data.

For CSV files, the import logic generates unique column names when duplicate headers are detected and fills missing cells with empty strings.

Q5: Can I use a strongly typed collection instead of a DataTable?

Yes. A DataTable is convenient when the column structure is determined by the imported file.

If your application has a known schema, you can map the imported rows to a model and bind an ObservableCollection to the DataGrid instead.

Q6: How can I handle large files?

The DataGrid supports virtualization for larger datasets. However, the import process itself also affects performance.

For very large files, avoid unnecessary data copies and consider moving longer-running processing away from the UI thread so the application remains responsive.

The appropriate approach depends on the file size, data structure, and processing requirements of your application.

Conclusion

Importing Excel and CSV files into the Syncfusion .NET MAUI DataGrid provides a way to work with file-based data directly inside an application.

In this example, FilePicker handles file selection, Syncfusion XlsIO reads Excel data, a CSV parser processes CSV files, and both formats are converted into a DataTable before being displayed in the Syncfusion .NET MAUI DataGrid.

You can extend this approach with application-specific validation, data transformation, strongly typed models, and additional DataGrid features.

Explore the complete GitHub example to try importing your own Excel and CSV data into a .NET MAUI application.

For more information, refer to the Syncfusion .NET MAUI DataGrid documentation.

If you’re a Syncfusion customer, you can access the latest Essential Studio release from the license and downloads page. New users can try Syncfusion with a 30-day free trial.

For questions, contact us through our support forums, feedback portal, or support portal.

Related Blogs

Create Reusable, Schema-Driven Forms with Syncfusion Form Builder and Form Renderer

Jollen Moyani — Wed, 14 Oct 2026 13:46:10 +0000

TL;DR: Build schema-driven forms in Angular with Syncfusion Form Builder and Form Renderer. Design forms visually, export their configuration as a JSON schema, and render interactive forms with configured fields and validation rules. This approach separates the form definition from rendering logic and simplifies form maintenance.

Have you ever needed to update the same form across multiple applications whenever a field, label, or validation rule changes? Maintaining separate form definitions can lead to duplicated code and inconsistent behavior.

What if you could define a form once and reuse its schema wherever needed? Syncfusion^® Form Builder and Form Renderer provide a schema-first approach to form development. Form Builder lets you design forms visually and export a JSON-based schema, while Form Renderer uses that schema to generate an interactive form with the defined fields, layout, and validation rules.

In this blog, you’ll explore how these components work together, understand the form schema, and learn how to render a form and handle its submission.

What Is Syncfusion Form Builder?

Syncfusion Form Builder is a visual form designer that lets you create forms by dragging and dropping fields onto a design canvas. Instead of manually defining every field in code, you can configure the form through the designer and inspect the generated JSON schema.

The Form Builder interface has five main areas:

Toolbox: Displays the available form fields you can add to the form.
Design canvas: Provides the workspace for adding and arranging fields.
Properties pane: Lets you configure the form and selected fields.
Code view: Displays the generated form schema as you make changes.
Form preview: Shows how the form will appear and behave.

You can drag a field from the toolbox onto the design canvas or use the canvas’s add button to insert one through the context menu. After adding a field, configure its properties, such as its label and validation rules, through the properties pane.

As you make changes, Form Builder updates the schema to reflect the form configuration. You can inspect the schema in the code view, preview the form, and export the definition for use with Form Renderer.

For setup instructions, refer to the Angular Form Builder getting-started guide.

How does the schema-first approach work?

A form schema describes the structure and configuration of a form, including its fields, layout, validation rules, and settings. Form Builder creates this definition, and Form Renderer uses it to generate the form at runtime.

The process consists of four steps:

Design: Add fields and configure their properties in Form Builder.
Export: Generate the JSON schema containing the form definition.
Render: Pass the schema to Form Renderer through its schema property.
Handle submission: Use the renderer’s submit event to access the submitted data and validation status.

This separation keeps the form definition independent of the application code that displays and processes it. When a form needs to change, you can update the schema and ensure that the relevant applications load the updated version.

Form Builder interface

What is Syncfusion Form Renderer?

Syncfusion Form Renderer is a schema-driven component that converts a structured form definition into an interactive form at runtime. It uses the supplied schema to determine which fields to display, how to arrange them, and which validation rules to apply.

Let’s look at an Angular example that defines a login form with an email field, a password field, a Remember Me checkbox, and a submit button.

Define the Form Schema in Angular

The following example defines the form schema and passes it to the Form Renderer component.

import { Component, ViewEncapsulation } from '@angular/core';
import { FormRendererModule, Schema } from '@syncfusion/ej2-angular-form-renderer';

@Component({
    selector: 'app-root',
    template: `<div>
                  <div
                    id="form-renderer-control"
                    ejs-form-renderer
                    [schema]="formSchema"
                    (submit)="onSubmit($event)">
                  </div>
               </div>`,
    styleUrls: ['app.component.css'],
    encapsulation: ViewEncapsulation.None,
    standalone: true,
    imports: [FormRendererModule]
})
export class AppComponent {
    formSchema: Schema = {
        "version": "0.1.0",
        "properties": {
            "emailAddress": {
                "id": "textbox_1785491685456_167",
                "name": "emailAddress",
                "type": "string",
                "label": "Email Address",
                "textboxType": "email",
                "required": true,
                "widget": "textbox"
            },
            "password": {
                "id": "textbox_1785491685456_537",
                "name": "password",
                "type": "string",
                "label": "Password",
                "textboxType": "password",
                "required": true,
                "minLength": 6,
                "widget": "textbox"
            },
            "rememberMe": {
                "id": "checkbox_1785491685456_262",
                "name": "rememberMe",
                "type": "boolean",
                "label": "Remember Me",
                "widget": "checkbox"
            },
            "submit": {
                "id": "submit_button_initial",
                "name": "defaultFormsubmit",
                "type": "button",
                "label": "Submit",
                "buttonType": "submit",
                "widget": "button",
                "style": "primary",
                "disabled": false
            }
        },
        "layout": [
            { "type": "field", "propertyId": "emailAddress" },
            { "type": "field", "propertyId": "password" },
            { "type": "field", "propertyId": "rememberMe" },
            { "type": "field", "propertyId": "submit" }
        ],
        "settings": {
            "name": "Untitled Form"
        }
    };

    public onSubmit(args: any): void {
        console.log('Is Valid:', args.isValid);
        console.log('Submitted Data:', args.data);

        if (args.isValid) {
            console.log('Processing form submission...');
        }
    }
}

The rendered result appears as follows.

Form Renderer output

Form Renderer uses the schema property to build the form and the submit event to invoke the onSubmit() method.

The schema includes three input fields and a submit button. It marks the email and password fields as required and applies a minimum length of six characters to the password. This rule illustrates schema-based validation and should not be treated as a production password policy.

Understand the Form Schema

The schema organizes the form configuration into three main sections:

properties: Defines the form fields, including their names, labels, data types, widgets, and validation rules.
layout: Specifies the order in which fields appear. Each entry references a field through its propertyId.
settings: Stores form-level configuration, such as the form name.

The widget property determines the type of control used to render a field. This example uses textbox, checkbox, and button widgets.

Validation rules are defined alongside their corresponding fields. The email and password fields use required, while the password field also uses minLength. Other supported schema rules include maxLength and pattern, depending on the field configuration.

Note: Client-side validation helps identify input errors, but it does not replace server-side validation or authorization. Always validate submitted data on the server before processing it or allowing access to protected resources.

For setup details and additional schema examples, refer to the Angular Form Renderer getting-started guide.

How form submission works

Once the form is rendered, users can enter their details and select the Submit button. Because the button uses "buttonType": "submit", Form Renderer validates the form and raises its submit event.

The event provides the submitted form data through args.data and the validation status through args.isValid.

In the Angular example, the onSubmit() method logs both values:

public onSubmit(args: any): void {
    console.log('Is Valid:', args.isValid);
    console.log('Submitted Data:', args.data);

    if (args.isValid) {
        console.log('Processing form submission...');
    }
}

The submitted data is keyed by the field names defined in the schema. For this example, it can contain values associated with:

emailAddress
password
rememberMe

The submit button is not included as an input value in the submitted data object.

Checking args.isValid lets the application determine whether the form passed validation before proceeding. In a real application, that step might involve sending the validated data to a server for further validation and processing.

You can also explore the Form Renderer StackBlitz sample to see the control in action.

Form Builder vs. Form Renderer

Form Builder and Form Renderer work together, but each has a distinct responsibility.

Form Builder	Form Renderer
Provides a visual form-design interface	Generates an interactive form from a schema
Lets you add, arrange, and configure fields	Maps field definitions to supported widgets
Lets you configure field properties and validation rules	Applies the configured layout and validation rules
Provides a preview and schema export	Handles form interactions and raises form-action events
Produces the form schema	Provides submitted form data to the application

This separation means that an application does not need to recreate the form structure manually. It can use a supported schema and pass it to Form Renderer.

Why shared schemas simplify form development

A schema-first approach is useful when form definitions need to be reused or updated regularly. Here are three practical benefits.

Avoid maintaining separate form definitions

When multiple applications use the same form, maintaining separate markup and validation logic makes updates repetitive. A shared schema brings field definitions, layout, and validation rules together, reducing duplicated form configuration.

Keep validation rules close to field definitions

Rules such as required and minLength can be defined alongside their corresponding fields. When validation requirements change, you can update the schema instead of modifying separate validation logic. Applications must load the updated schema for the changes to take effect.

Simplify form updates across applications

Consider a customer onboarding form used in a self-service portal, an administrator dashboard, and an internal support application. Instead of updating three separate form definitions, you can maintain one shared schema for applications that support it. Each application must load the appropriate schema version to reflect the changes.

Where can these components be useful?

Form Builder and Form Renderer are useful for applications that need configurable or frequently updated forms, including:

Customer onboarding forms
Surveys and feedback forms
Support and service-request forms
Internal approval forms
Configurable intake forms
SaaS applications that allow users to design forms
Low-code and no-code development platforms

For example, a service team may need to add a field to a support-request form when its process changes. A shared schema can reduce the work involved in maintaining that form across multiple applications, provided each application loads the updated definition.

The approach is particularly useful when form definitions change more frequently than the application code responsible for displaying them.

Getting started with Form Builder and Form Renderer

Ready to try schema-driven forms in your app? Use the following resources to explore the components and their configuration options.

Resource	Link
Angular Form Builder	Getting Started
Angular Form Renderer	Getting Started
Form Renderer schema reference	Form Schema
Form Renderer examples	Angular demos

Working with another framework? Check the corresponding Syncfusion documentation to ensure both packages fit your application setup.

Start building schema-driven Forms

Maintaining forms across applications does not have to mean maintaining separate definitions for every instance. Syncfusion Form Builder and Form Renderer separate form design from rendering, allowing you to create a form visually, export its JSON schema, and generate interactive forms with preconfigured fields and validation rules.

By keeping the form definition in one reusable schema and ensuring that applications load the appropriate version, you can reduce duplicated definitions and simplify future updates.

Design the form, reuse its schema, and make form maintenance easier.

Explore the complete Essential Studio Volume 3 What’s New and Release Notes documentation to find the features relevant to your project.

Existing Syncfusion customers can download the latest version from the license and downloads page, while new users can get started with a free 30-day trial.

Have questions or feedback? Connect with us through the Syncfusion support and feedback channels.

Related Blogs

React Gantt Chart Performance: Which Library Handles 100,000 Tasks Best?

Jollen Moyani — Tue, 13 Oct 2026 15:36:11 +0000

TL;DR: Which React Gantt chart handles large schedules better? We benchmarked Syncfusion React Gantt, Bryntum Gantt, and DHTMLX Gantt across rendering, task operations, hierarchy changes, and dependency recalculation. Syncfusion performed best in most tested scenarios, completing the 100,000-task stress test in 44.4 seconds, compared with 122.2 seconds for DHTMLX. DHTMLX was faster at deletes, while Bryntum had no reported result for the 100K test. Results may vary with your data and environment.

Choosing a React Gantt chart isn’t just about features; performance matters, too. When task counts reach tens of thousands, does the chart still load quickly, respond to updates, and recalculate dependencies efficiently?

To find out how they compare, we benchmarked Syncfusion^® React Gantt Chart, Bryntum Gantt, and DHTMLX Gantt with workloads of up to 100,000 tasks. All three libraries were tested using the same datasets, interactions, and environment, and the results and test resources were shared for independent verification.

What does the benchmark measure?

The benchmark focuses on client-side React performance across five areas:

Initial rendering
CRUD operations
Hierarchical expand/collapse actions
Dependency recalculation
Large-scale stress workloads

The benchmark does not evaluate feature depth, licensing, accessibility, exporting, collaboration features, or memory consumption.

All tests used production builds, the same machine and browser, and the same logical datasets, with only the data-format adaptations required by each library’s API.

Because Syncfusion conducted this benchmark, the results should be considered a reproducible data point rather than a definitive industry ranking. Independent validation is encouraged.

Test environment

To compare the three libraries under consistent conditions, we used the following hardware and software configuration.

Item	Configuration
Operating System	Windows 11 Enterprise
Processor	Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
Memory	16 GB RAM
Browser	Microsoft Edge Version 154.0.4258.62 (Official build) (64-bit)
Node.js	v24.19.0
React	19.2.8
Build Tool	Create React App (CRA)

React Gantt library versions

The benchmark used the following versions:

Library	Version
Syncfusion React Gantt Chart	35.1.37
Bryntum Gantt	7.3.5
DHTMLX Gantt	10.0.2

Performance can vary between releases, so these versions define the scope of this comparison.

Build and runtime conditions

Benchmark results can be influenced by factors beyond the Gantt component itself. To reduce avoidable variance and provide a fair comparison, all runs were executed under the same baseline conditions:

Production builds only, without development-mode measurements.
Local execution on the same machine.
Browser extensions disabled.
No intentionally parallel workloads during benchmark capture.
Identical logical datasets, with only the minimum data-format adaptations required by each library.
Consistent benchmark workflows, measurement logic, and runtime configuration across test scenarios.

The benchmark repository is available on GitHub: Gantt Chart Performance Benchmark Repository

The repository is intended to provide the dataset generators, configuration files, benchmark scripts, and raw measurements in CSV and JSON formats. These resources allow readers to inspect the results, verify calculations, and reproduce the tests in their own environments.

Readers are encouraged to run the workloads using their own hardware, browser versions, and project configurations to assess how the results relate to their applications.

Dataset design

The benchmark uses synthetic datasets rather than real project files. This approach allows the same workload characteristics to be applied consistently across the three libraries, although the datasets cannot represent every project structure or scheduling pattern.

The scenarios cover 5,000 to 100,000 tasks and include:

Repeated parent-child structures for rendering tests.
Deep hierarchies with 10 levels of nesting for navigation tests.
Dependency-heavy schedules for recalculation tests.
Combined hierarchy and scale workloads for stress testing.

The dataset generators are included in the benchmark repository so that readers can recreate the same scenarios and validate the results in different environments.

What we observed

Initial rendering

The largest gap appeared during initial load.

Tasks	Syncfusion	Bryntum	DHTMLX
5K	1.5 s	8.3 s	1.5 s
10K	2.1 s	18.4 s	3.3 s
25K	5.1 s	52.5 s	11.1 s
50K	10.2 s	91.2 s	54.2 s

At smaller sizes, Syncfusion and DHTMLX produced similar results, while Bryntum required noticeably more time to complete rendering. As dataset size increased, the gap widened significantly.

Initial render time (seconds) across dataset sizes

The most interesting observation is not the absolute numbers but the scaling behavior. Between 5K and 50K tasks, Syncfusion’s growth curve remained comparatively gradual, while DHTMLX and Bryntum increased more sharply.

For teams routinely opening 25K-50K task portfolios, this difference could affect perceived application responsiveness.

Note: The page load timer starts when the dataset is assigned to the Gantt Chart. The timer stops in the dataBound event after the Gantt Chart has completed rendering, and the elapsed time is displayed as the initial rendering time.

Editing performance

For interactive planning applications, editing performance can be just as important as initial rendering.

Record updates were generally the fastest operation across all libraries:

Dataset	Syncfusion	Bryntum	DHTMLX
5K	9.8 ms	30.20 ms	16.9 ms
10K	11.7 ms	40.8 ms	22.1 ms
25K	17.2 ms	44.8 ms	76.0 ms
50K	21.2 ms	64.5 ms	147.8 ms

Syncfusion and DHTMLX consistently completed updates in milliseconds, while Bryntum showed higher variability across the reported scenarios.

Update operation latency (milliseconds)

Note: A record update represents the benchmark’s defined update operation applied to a single task. See the benchmark repository for the exact implementation and measurement logic.

The practical distinction here is substantial. A sub-25 ms update feels instantaneous. Multi-second delays are immediately visible to users and can interrupt planning workflows.

Delete operations proved significantly more expensive for every library, especially at larger scales. Even the fastest measurements exceeded one second at 50K records, highlighting that large hierarchical removals remain a costly operation regardless of implementation.

Dataset	Syncfusion	Bryntum	DHTMLX
5K Tasks	133.3 ms	311.9 ms	96.8 ms
10K Tasks	972.1 ms	660.3 ms	219.6 ms
25K Tasks	1,188.5 ms	3,216.1 ms	494.2 ms
50K Tasks	4,550.6 ms	6,108.7 ms	1,245.7 ms

Delete operation latency (milliseconds)

Deep hierarchies

Large project schedules can contain nested work breakdown structures rather than flat task lists. To measure hierarchy operations, the benchmark tested expanding and collapsing all tasks across 10 levels of nesting.

At 50K tasks:

Operation	Syncfusion	Bryntum	DHTMLX
Expand all	69.6 ms	6485.7 ms	500.7 ms
Collapse all	43.9 ms	3592.6 ms	196.1 ms

The benchmark showed a substantial difference between the three implementations. Syncfusion and DHTMLX remained relatively responsive, while Bryntum required multiple seconds to complete bulk hierarchy actions in this benchmark configuration.

Dependency recalculation

Dependency processing was the most computationally expensive workload.

Even the best-performing measurements became substantial at larger sizes.

Tasks	Syncfusion	Bryntum	DHTMLX
25K	15.9 s	62.2 s	20.6 s
50K	47.5 s	NA	84.7 s

Note: NA (Not Available) indicates that the scenario could not be completed successfully due to excessive execution time or application instability.

Dependency & critical path recalculation (seconds)

These results reinforce an important lesson: large dependency networks are expensive regardless of vendor.

Teams building dependency-heavy planning systems should benchmark their own scheduling topology before committing to a component. The synthetic chains used in this benchmark help provide consistency, but they cannot represent every real-world project structure.

Note: These tests used the dependency structure generated by the benchmark dataset. Because dependency topology can vary substantially between projects, these results should be treated as workload-specific rather than universal performance limits.

How the Gantt libraries handle 100,000 tasks

The final scenario combined volume and hierarchy depth.

Workload	Syncfusion	Bryntum	DHTMLX
25K / 5 levels	6.7 s	40.6 s	9.1 s
50K / 10 levels	14.4 s	97.6 s	32.3 s
75K / 10 levels	26.8 s	NA	74.1 s
100K / 10 levels	44.4 s	NA	122.2 s

In this benchmark environment, Syncfusion completed the 100,000-task workload in 44.4 seconds, while DHTMLX required 122.2 seconds. Bryntum did not complete the largest reported scenarios

Combined scale + hierarchy stress test (seconds)

What developers should take away?

The key takeaway is that Gantt performance depends on the workload:

Large schedules: Focus on initial rendering time.
Frequent task edits: Compare update and delete latency.
Dependency-heavy projects: Pay closer attention to recalculation performance than rendering alone.
Projects with more than 50,000 tasks: Test with your own data rather than relying on benchmark results alone.

Benchmark summary (all times in seconds)

Scenario	Syncfusion	Bryntum	DHTMLX
Initial rendering (50K tasks)	10.2	91.2	54.2
Record update (50K tasks)	0.021	3.0	0.148
Delete (50K tasks)	4.551	6.109	1.246
Expand all (50K tasks)	0.070	6.486	0.501
Collapse all (50K tasks)	0.044	3.593	0.196
Dependency recalculation (50K tasks)	47.5	NA	84.7
Stress test (100K tasks, 10 levels)	44.4	NA	122.2
Scrolling (FPS)	Not compared	60	60

Key takeaway: Syncfusion recorded the lowest times in five of the six scenarios compared, with DHTMLX fastest for deletes. Bryntum did not render the 50K dependency recalculation or the 75K and 100K stress workloads. Results reflect synthetic data in one test environment, so validate them against your own workload.

Conclusion

A Gantt chart that performs well with a small dataset can behave very differently when it manages thousands of tasks and dependencies. Testing against your own workload matters as much as reading benchmark results.

Syncfusion ran this benchmark to show how Syncfusion React Gantt Chart, Bryntum Gantt, and DHTMLX Gantt handle demanding scheduling operations. The results reflect one test environment and dataset structure, so use them as a starting point and rerun the tests on your own hardware and data.

Ready to evaluate Syncfusion React Gantt Chart? Explore the live demos, read the documentation, or start a free trial to test it with your own schedules.

For existing Syncfusion customers, the latest version of Essential Studio is available from the License and Downloads page. New users can explore its capabilities through the 30-day free trial.

If you have questions or feedback, reach out through our support forum, support portal, or feedback portal.

Related Blogs

Why Modern AI Apps Feel Faster: Streaming UX Patterns That Actually Work

Jollen Moyani — Mon, 12 Oct 2026 12:31:18 +0000

TL;DR: Learn how to design responsive AI streaming interfaces by measuring TTFT and time to useful content, choosing the right streaming transport, handling partial responses, building safe Generative UI experiences, and monitoring performance in production.

An AI application can generate a response quickly and still feel slow. Users may wait without feedback, watch the layout shift as text arrives, or struggle to recover when a connection interrupts an otherwise useful answer.

Unlike a conventional request that returns a completed result, an AI interaction may deliver partial text, retrieve information, call tools, and continue generating. The frontend must manage these stages without losing the user’s context.

Streaming helps by making output available before the entire response is complete. However, a responsive experience depends on more than displaying text as it arrives.

This guide explores how to measure streaming latency, choose a suitable transport, handle incomplete responses, build safe Generative UI experiences, and troubleshoot performance issues.

Note: The code examples are illustrative rather than complete production implementations. In a real application, route requests through a backend you control. Keep provider credentials, authorization, and privileged tool execution on the server.

Why streaming matters in AI applications

A conventional application often follows a predictable sequence:

Request → Processing → Result

An AI interaction can take a less predictable path:

Request → Partial response → Tool call → More response → Completion

It may also stop unexpectedly after producing useful output.

The frontend therefore needs to communicate more than the final result. It should acknowledge the request, show meaningful progress, preserve useful output, and let users stop or retry when needed.

For example, an assistant generating a long explanation can display the first useful paragraph while the remaining content is still being generated. Users can begin reading instead of waiting for the entire response.

That improvement matters most when early output is meaningful, and the application can safely handle incomplete responses.

Measure the latency users actually experience

Time to First Token (TTFT) measures the delay before the first response token becomes available at a defined measurement point. For an AI application, that point might be the provider, backend, or browser. The measurement boundary matters when comparing results.

TTFT is not the same as the time when users first see content or receive information they can act on. These are separate milestones:

Time to first token: When the first token becomes available at the chosen measurement point.
Time to first visible content: When response content is actually rendered in the interface.
Time to useful content: When the response first provides information users can act on.
Time to completion: When the response finishes.

A fast first token does not guarantee that the answer will feel responsive. The response might contain a long preamble, or the frontend might delay rendering the content.

Several factors can increase the delay before useful content appears:

Model prefill and prompt size
Provider-side queueing
Network latency
Backend orchestration
Retrieval and tool initialization
Buffering between the server and browser
Frontend decoding, parsing, and rendering

Track TTFT alongside time to useful content and total completion time. For production monitoring, percentile measurements such as P50, P95, and P99 can reveal slow requests that averages hide.

Define the measurement boundaries consistently. Receiving a token at the browser is not the same as rendering it on screen, so instrument those events separately when possible.

Actual latency versus perceived latency

Actual latency describes how long an operation takes. Perceived latency reflects how responsive the application feels while the operation is in progress.

The interface can improve perceived responsiveness by acknowledging requests quickly, showing meaningful progress, and displaying useful output as it becomes available.

If TTFT is low but the interface still feels slow, investigate rendering work, layout instability, buffering, and progress feedback before attributing the problem to the model.

When should you use streaming?

Streaming is not necessary for every AI feature. A regular request-response pattern may be simpler for short, predictable outputs such as classification labels, autocomplete suggestions, or brief validation messages.

Streaming becomes more useful when:

Responses are long enough that users benefit from reading early.
Retrieval or tool execution introduces noticeable delays.
The response evolves through multiple stages.
Partial output remains useful if the connection fails.
The interface needs to display structured events during generation.

The decision should depend on what users gain from receiving the result progressively. Streaming also introduces extra work around cancellation, state management, error handling, and rendering, so use it where those trade-offs make sense.

Choose the right streaming transport

Once streaming is useful for the interaction, choose a transport that matches the communication pattern.

Approach	Best suited for	Main trade-off
`Server-Sent Events (SSE)` consumed through `EventSource`	One-way server-to-browser events over HTTP	`EventSource` offers limited control over request methods, headers, and payloads
fetch with `ReadableStream`	POST requests, custom headers, and application-specific streaming formats	The application must handle stream reading, decoding, and parsing
`WebSockets`	Continuous, bidirectional communication	Requires additional connection and lifecycle management

SSE and EventSource are related, not separate transport choices.

SSE is the event-stream format and communication mechanism.
EventSource is the browser API commonly used to consume it.

Server-sent events with EventSource

Server-Sent Events provide a way for a server to send a sequence of events to a browser over HTTP. They can be a good fit for text generation and other interactions where the server primarily sends updates to the client.

The browser’s EventSource API handles SSE event parsing and provides reconnection behavior. However, it does not offer the same request customization as fetch, which can be a limitation when an endpoint requires a POST request, custom headers, or a request body.

Automatic reconnection also does not guarantee that an interrupted AI generation will resume from the exact point where it stopped. Resuming requires suitable server-side support, such as an event identifier or application-level continuation mechanism.

Fetch with ReadableStream

Using fetch with a ReadableStream gives the application more control over the request and response. This can be useful when the endpoint expects a POST request, authentication headers, a JSON body, or a custom event format.

The trade-off is that the client must correctly decode and parse the response. It also needs to handle cancellation, connection failures, and incomplete messages.

A network read does not necessarily correspond to one complete application event. A read may contain part of an event, one event, or several events. The parser must buffer data until complete messages can be identified.

Use a well-tested streaming parser when possible rather than spreading protocol-specific parsing logic throughout the UI.

WebSockets

WebSockets support communication in both directions over a persistent connection. They can be appropriate for voice interactions, collaborative sessions, and applications that continuously exchange events.

For many text-generation experiences, HTTP streaming is sufficient. WebSockets become more useful when the interaction itself requires ongoing communication in both directions.

Handle the frontend problems that make streaming feel unreliable

Receiving data progressively does not guarantee a good user experience. The frontend must keep the interface readable, stable, and recoverable while the response changes.

Show progress before the first response arrives

Even a streaming request can have a noticeable delay before its first useful output. If the screen remains blank, users may assume that the request was lost.

Show a clear processing state as soon as the request is accepted. Depending on the application, this might be a simple status message or a more specific indicator such as Searching or Retrieving information.

Only show intermediate states that reflect meaningful application events. Avoid suggesting that an operation is happening if the application cannot verify that it is.

Keep the layout stable as the response grows

A long response can move buttons, shift surrounding content, and pull the viewport away from the user’s current reading position.

Reserve space where practical and avoid unnecessary layout changes. Auto-scroll only when the user is already near the bottom of the response. If they scroll upward to read earlier content, preserve their position and offer a Jump to latest action.

Batching UI updates can also reduce rendering work. The right update frequency depends on the framework, response size, and rendering cost. Updating once per animation frame is one option, not a universal requirement.

The aim is to keep new content readable without making the rest of the page feel unstable.

Render incomplete Markdown carefully

Streaming Markdown presents a separate challenge because the content may not yet form a complete document.

An incoming response might contain an unfinished code block, an incomplete link, unmatched emphasis markers, or a partially generated list. Reprocessing the entire document after every token can cause flickering and unnecessary rendering work.

A streaming-aware renderer can buffer incoming text, update on a controlled schedule, and preserve completed blocks where possible. Incomplete content should be treated as provisional until enough input is available to render it reliably.

Treat model-generated HTML as untrusted input. Render plain text safely by default, and use appropriate sanitization if the application supports rich HTML. Never insert raw model output directly into innerHTML.

Let users stop or retry a response

Long-running interactions should not leave users stuck waiting for an answer they no longer need.

Provide controls appropriate to the application:

Stop to cancel the current request.
Retry to attempt the request again after a failure.
Regenerate when the user wants another response.

A browser request can be aborted with AbortController:

JavaScript

const controller = new AbortController();

const responsePromise = fetch("/api/chat", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ message: "Explain AI streaming UX" }),
  signal: controller.signal
});

// When the user selects Stop:
controller.abort();

This illustrates how to attach a cancellation signal to a request; it does not implement a complete streaming lifecycle. Production code must consume the response body, handle abort and network errors, update the interface, and release any resources as appropriate.

Aborting the browser request does not, by itself, guarantee that backend processing or upstream model generation has stopped. If the application needs to stop that work, the backend must support cancellation and propagate it to the relevant operation.

Preserve partial responses after failure

Suppose an assistant has already generated several useful paragraphs when the connection fails. Removing those paragraphs can make the interruption feel like data loss.

Keep the visible output and communicate its status clearly. Distinguish between a completed response, a canceled response, and an interrupted response so users know what happened.

Retry behavior should also be designed deliberately. A retry may restart the entire generation rather than continue from the interruption. Resuming requires support in the backend and the relevant protocol or application logic.

Make it clear whether the next attempt will restart or resume when that difference affects the user’s work. Avoid presenting a restarted answer as a continuation of the previous response.

Check for buffering between the server and browser

The backend may produce output progressively while an intermediary buffers it before sending it to the browser. In that situation, users receive several tokens at once instead of seeing them arrive progressively.

If the browser’s received-data timing does not match the server’s output timing, inspect proxy, CDN, compression, and response-buffering configuration. Confirm that the deployment path supports the intended streaming behavior rather than assuming that a streaming endpoint guarantees progressive delivery.

Build safe generative UI experiences

AI interfaces do not have to display only text. With Generative UI, a model can return structured information that the application maps to approved interface components.

For example, rather than returning a weather description as plain text, a system might provide structured data that the frontend renders as a weather card. The same approach can support charts, forms, status panels, data views, and approval cards.

The important boundary is that the model proposes content or a UI state; the application decides what it will render and which actions are permitted.

Validate structured output before rendering

Define the components your application supports and the data each component expects. An illustrative registry might look like this:

JavaScript

const registry = {
  displayWeather: weatherSchema,
  showChart: chartSchema,
  showApproval: approvalSchema
};

The schema definitions are application-specific placeholders, not built-in APIs.

When a structured response arrives:

Identify the requested component or action.
Check that it exists in the approved registry.
Parse the payload.
Validate the payload against the expected schema.
Render the corresponding component only after validation succeeds.

Reject unknown component types and invalid payloads. Do not let the model introduce arbitrary UI components simply by naming them in its response.

For streamed structured data, also account for incomplete payloads. Buffer data until the relevant message or structured unit is complete, or use a protocol designed to represent incremental updates. Do not treat a partial JSON object as a validated component configuration.

Keep privileged actions on the server

A structured response might propose an action such as sending an email or modifying a record. The browser should not execute that action merely because the model requested it.

Instead, display the proposed action and ask for user confirmation when the action’s impact or risk warrants it. Send the request to the backend, where the server validates the arguments, checks authorization, and applies the appropriate safeguards before execution.

For operations that affect external systems or modify important data, consider idempotency and audit logging as well. These controls help prevent unintended side effects and make the operation traceable.

User confirmation is an additional safeguard, not a replacement for server-side authorization.

Make streaming interfaces accessible and trustworthy

A responsive interface should communicate what is happening without overwhelming users or making unsupported claims.

Provide evidence for factual responses

When the application uses retrieval or external sources, place citations close to the claims they support. Users should be able to determine which source supports a statement without having to match every claim against an unrelated list at the end.

If the system proposes an action rather than simply presenting information, make the proposed change and its consequences clear before the user confirms it.

Announce updates meaningfully

Screen readers can struggle with streamed responses if every token is added to a live region. Announcing each small change can interrupt reading and make the experience difficult to follow.

Separate the visual rendering loop from the screen-reader announcement strategy.

Consider these practices:

Create live regions before streamed content arrives.
Use polite announcements for ordinary progress and response updates.
Reserve assertive announcements for urgent errors where appropriate.
Announce meaningful chunks rather than every token.
Keep completion, cancellation, and error messages in a separate status region.
Test the behavior with the browsers and assistive technologies your application supports.

For example:

HTML

<div id="live" aria-live="polite"></div>
<div id="status" role="status"></div>

These elements illustrate a possible structure, not a complete accessibility implementation. The application must still control what is announced and when. A code snippet alone does not establish WCAG conformance.

Show observable application states

Status messages such as Searching, Retrieving information, Waiting for approval, and Generating response can help users understand the application’s progress.

Use states that correspond to events the application can observe. Avoid presenting unverifiable internal model reasoning as a factual explanation of what the system is doing.

Measure and debug streaming performance in production

A single request completed metric does not reveal where users experience friction. Track enough of the interaction to distinguish generation delays from frontend and transport problems.

Metric	What it helps you investigate
TTFT	Delay before the first token becomes available at the defined measurement point
Time to first visible content	Delay before response content appears in the interface
Time to useful content	When the response first provides meaningful information
Time to completion	Total response duration
Interruption rate	How often streams end unexpectedly
Cancellation rate	How often users stop generation
Retry rate	How often users need another attempt
Tool-call success and failure	Reliability of structured AI operations
Client rendering cost	Browser work during streaming

Define each metric consistently and separate server-side timings from browser-side timings when possible. This makes comparisons more useful across requests and releases.

Diagnose where the delay occurs

Suppose users report that an assistant feels slow even though backend generation time looks normal.

Start by comparing TTFT, time to useful content, browser rendering performance, and the timing of data received by the client.

High TTFT: Investigate request handling, provider queueing, model prefill, retrieval, and network delays.
Low TTFT but late useful content: Inspect the response structure and the sequence of retrieval or tool operations.
Timely content but a sluggish interface: Examine rendering frequency, Markdown processing, layout instability, and main-thread work.
Output arriving in bursts: Check buffering between the backend and browser.

For example, if server logs show that output is generated progressively but browser timestamps show that chunks arrive together, investigate the delivery path before changing the model or rewriting the frontend.

This approach narrows the investigation before you make changes. The measurements help identify where to look; they do not establish a cause on their own.

Production checklist for AI streaming UX

Before releasing a streaming AI interface, review the following items.

User experience

Show a clear processing state before the first response arrives.
Keep the layout stable while content grows.
Preserve the user’s reading position.
Provide Stop and Retry controls where appropriate.
Preserve useful partial output after failures.
Distinguish completed, canceled, and interrupted responses.

Streaming and transport

Handle partial network reads correctly.
Decode incoming data incrementally and parse complete protocol messages.
Check proxy and CDN buffering.
Handle timeouts and interrupted connections.
Define retry and cancellation behavior.
Make it clear whether retries restart or resume generation.

Security

Keep provider credentials on the server.
Treat model output as untrusted input.
Escape text and sanitize supported rich HTML appropriately.
Validate structured payloads and tool arguments.
Authorize privileged actions on the server.
Log important side effects where required.

Accessibility

Create live regions before streamed content arrives.
Announce meaningful chunks instead of every token.
Separate response announcements from status messages.
Test with supported assistive technologies and browsers.

Observability

Measure TTFT and time to useful content.
Track cancellations, retries, and interruptions.
Monitor browser rendering performance.
Track structured tool-call failures.
Compare server generation timings with browser receipt and rendering timings.

Frequently Asked Questions

Q1: Do all AI applications need streaming?

No. Streaming is most useful when responses are long, delayed, or useful before completion. For short and predictable outputs, a conventional request-response implementation may be simpler.

Q2: Does streaming make an AI application faster?

Not necessarily. Streaming can improve perceived responsiveness by displaying useful output before the full response is ready. It does not automatically reduce the time required to generate the complete answer.

Q3: What is the difference between TTFT and time to useful content?

TTFT measures when the first token becomes available at a defined measurement point. Time to useful content measures when the response first provides information the user can act on. Tracking both helps distinguish a quick initial response from an answer that becomes useful quickly.

Q4: When should I use WebSockets instead of HTTP streaming?

Use WebSockets when the application needs ongoing, bidirectional communication, such as voice interactions or collaborative sessions. For many text-generation experiences, HTTP streaming is sufficient.

Q5: What should happen when a stream fails midway?

Preserve the output already displayed, communicate that the response was interrupted, and provide an appropriate recovery option. Whether the next attempt can resume or must restart depends on the backend and streaming protocol.

Q6: Is streaming text enough for modern AI interfaces?

Not always. Some applications also need structured UI components, tool-call status, citations, approval flows, and recovery from partial results. Choose the interaction model according to what users need to understand and accomplish.

Conclusion

Good AI streaming UX is about more than displaying tokens as they arrive. The interface needs to communicate progress, preserve useful output, stay stable as content grows, and give users control when things go wrong.

Start by measuring TTFT, time to first visible content, and time to useful content. Then make the streaming lifecycle explicit, handle incomplete data correctly, validate structured output, and keep privileged actions on the server. Test accessibility and monitor browser performance alongside backend timings.

With those foundations in place, you can build AI experiences that remain understandable and useful even when responses take time, involve tools, or fail partway through.

Related Blogs

What’s New in Syncfusion .NET MAUI 2026 Volume 3: New Controls and Features

Jollen Moyani — Fri, 09 Oct 2026 14:47:11 +0000

TL;DR: Syncfusion Essential Studio 2026 Volume 3 (v35.1.37) introduces five new preview controls for .NET MAUI: TreeGrid, Data Pager, Diagram, Grid Splitter, and Interactive Viewer. The release also adds a multirow layout for DataGrid, new scheduling and charting capabilities, Markdown and streaming support in AI AssistView, and marks Rich Text Editor as production-ready.

Building .NET MAUI applications involves handling UI requirements such as displaying hierarchical data, navigating large datasets, creating interactive diagrams, and designing flexible layouts. Implementing these capabilities can add to development time and maintenance effort.

Syncfusion Essential Studio 2026 Volume 3 introduces five new preview controls, TreeGrid, Data Pager, Diagram, Grid Splitter, and Interactive Viewer, to address these needs. The release also enhances DataGrid, Scheduler, Charts, AI AssistView, and SignaturePad, while making Rich Text Editor production-ready.

Explore the key updates and the breaking changes to review before upgrading to v35.1.37.

.NET MAUI 2026 Volume 3 at a glance

Here’s a quick look at the major updates:

Control	What’s new
TreeGrid (Preview)	Display hierarchical data in a grid
Data Pager (Preview)	Navigate data through pages and load data on demand
Diagram (Preview)	Create interactive diagrams with nodes and connectors
Grid Splitter (Preview)	Build resizable application layouts
Interactive Viewer (Preview)	Zoom, pan, rotate, and reset content
DataGrid	Multirow column layout
Scheduler	Hierarchical resources, appointment overlap controls, and iCalendar support
Charts	Gradient line series, trackball enhancements, and axis styling
AI AssistView	Markdown, response streaming, and prompt libraries
SignaturePad	Check whether a signature has been provided
Rich Text Editor	Now production-ready, with a grouped toolbar and structured content support

The release introduces five new preview controls and enhancements to existing controls, while making Rich Text Editor production-ready. Let’s explore these updates and how they can help you build .NET MAUI applications.

1. TreeGrid

Have you ever needed to display parent-child data while still giving users the familiar experience of a data grid?

The .NET MAUI TreeGrid control is designed for this scenario. It displays self-relational and nested data in a tabular format, allowing users to expand and collapse hierarchical records. You can also use features such as sorting, filtering, selection, and frozen columns.

For example, you could use TreeGrid to display:

Organization structures.
Product categories and subcategories.
Project tasks and subtasks.
File or folder hierarchies.
Other parent-child datasets.

Key capabilities

Bind self-relational and nested collections.
Use automatically generated or manually defined columns.
Expand and collapse nodes interactively or programmatically.
Sort by one or multiple columns.
Filter data programmatically.
Freeze columns.
Customize the appearance of the grid.

TreeGrid (Preview)

2. Data Pager

Displaying a large collection at once can make data harder to navigate and require loading more records than users need.

The .NET MAUI Pager simplifies navigation through large datasets by dividing records into pages and loading data on demand. It also integrates with data-bound controls such as DataGrid.

Key capabilities

Standard page navigation.
On-demand data loading.
Configurable navigation modes.
Programmatic page navigation.
Horizontal and vertical layouts.

Data Pager (Preview)

3. Diagram

Need to show relationships, processes, connections, or other visual structures?

The new Diagram control provides a canvas for building interactive diagrams using nodes, connectors, annotations, and reusable symbols. It also supports drag-and-drop editing, customizable connection ports, a symbol palette, and serialization.

You can use it for scenarios such as:

Flowcharts.
Process diagrams.
Organization charts.
Visual editors.
Relationship diagrams.

Key capabilities

Predefined shapes, templates, and paths.
Straight and orthogonal connectors.
Annotations and labels.
Customizable connection ports.
Symbol palette.
Save and load support.
Export support.

Diagram (Preview)

4. Interactive Viewer

Sometimes a standard image or content view isn’t enough. Users may need to zoom in, move around, or rotate content to inspect details.

The .NET MAUI Interactive Viewer adds these interactions to .NET MAUI views. You can use it with images, maps, diagrams, documents, and other visual content that benefits from closer inspection.

Key capabilities

Zoom and pan.
Rotate content.
Reset the view.
Display any .NET MAUI view.
Support light and dark themes.
Customize interactions through events.

Interactive Viewer (Preview)

5. Grid Splitter

Do you want users to control how much space different areas of your application use?

The new Grid Splitter lets users resize adjacent rows or columns by dragging a splitter. You can also allow panes to expand or collapse and set minimum and maximum sizes.

This makes it useful for:

Dashboards.
Document editors.
Image viewers.
Master-detail layouts.
Workspace-style applications.

Key capabilities

Interactive pane resizing.
Expand and collapse actions.
Horizontal and vertical orientations.
Minimum and maximum pane sizes.
Nested splitter layouts.
Runtime event support.

Grid Splitter (Preview)

What’s new in existing .NET MAUI controls?

The release also enhances several existing controls with new capabilities for data presentation, AI interactions, scheduling, visualization, and content editing.

DataGrid

Wide grids can become difficult to use when each record contains many fields.

The new Multi-Row Column Layout lets you arrange related fields across multiple row levels instead of placing everything into one wide row.

Multi-Row Column Layout

For employee, product, or order records with many fields, this layout helps organize related information without forcing every field into a single wide row.

AI AssistView

AI responses are no longer limited to plain text. Your application may need to display headings, lists, links, code blocks, and progressively generated responses.

With the latest AI AssistView updates, you can render Markdown content and stream AI responses as they are generated.

Markdown rendering and response streaming

A new prompt library also helps you organize reusable prompts by categories and topics.

Prompt library

What you can now do

Render Markdown in AI responses.
Display generated responses progressively through streaming.
Organize reusable prompts with a prompt library.
Create more structured AI conversations.

SignaturePad

The SignaturePad now includes an IsEmpty property that lets you determine whether a user has provided a signature.

You can check this property before moving to the next step or submitting a form. For workflows that require a signature, it provides a simple way to validate whether the user has entered one.

Scheduler

If your application manages multiple resources, overlapping appointments, or different calendar systems, the Scheduler now gives you more control.

The .NET MAUI Scheduler adds support for hierarchical resources, appointment overlap controls, major and minor time-slot ticks, Month Agenda view, and iCalendar import and export.

Key updates

Hierarchical resources: Organize resources using parent-child relationships.

Hierarchical resource view

Appointment limits: Control how many overlapping appointments are displayed at once.

Limit concurrent appointments

Major and minor ticks: Make time slots easier to read in scheduling views.

Major and minor time slot ticks

Month Agenda: View appointments in an agenda-style format within the month view.

Month agenda view

iCalendar support: Import and export appointments using .ics files.

Import and export appointments using iCalendar support

Charts

Charts also receive several improvements in this release.

You can now use gradient support for line series to create smoother color transitions.

Gradients in line type series

Trackball support has also been extended to stacked column charts, making it easier to inspect and compare data points.

Stacked column trackball

Annotation ZIndex support for controlling layers.

Annotation ZIndex

Axis range styling for highlighting specific data ranges.

Axis range styling

Additional updates include:

Legend title support.
Accessibility improvements across chart controls.

Rich Text Editor:

One of the important milestones in this release is that the .NET MAUI Rich Text Editor is now production-ready.

The release also adds a mobile-friendly, grouped toolbar through the IsGrouped property. Related toolbar actions can be presented together in a touch-friendly interface on Android and iOS, helping reduce toolbar clutter.

Grouped mobile toolbar

This makes formatting commands easier to access on mobile devices while keeping the editing interface organized.

.NET MAUI Rich Text Editor

The Rich Text Editor also supports structured content through schema-based block nodes and provides a unified Value property for HTML, plain text, and schema block node content.

Users can also convert selected text to uppercase or lowercase through the toolbar.

So, while the five new controls are still in preview, you can now consider the Rich Text Editor for production .NET MAUI applications.

Before you upgrade: Breaking changes and .NET support

Planning to move your application to v35.1.37?

Before updating your packages, review the following changes to identify any updates needed in your existing code.

Data Pager package change

The SfDataPager control has moved from Syncfusion.Maui.DataGrid to Syncfusion.Maui.DataPager.

Update the package references and namespaces in your C# and XAML code to use the new package.

Rich Text Editor API changes

The Rich Text Editor now uses a unified Value property for content. The previous HtmlText and Text properties are no longer publicly accessible. The Value property supports HTML, plain text, and schema block node content, with the format determined by the TValue enumeration.

Before upgrading, replace references to the previous content properties with Value and the appropriate content format.

The release notes also identify obsolete configuration APIs, including DefaultTextColor, DefaultFontFamily, DefaultFontSize, and UseHybridWebView. Check the official migration guidance for their required replacements.

Color Picker collection change

The PaletteColors property now uses ObservableCollection instead of List.

Update the collection type and related code wherever PaletteColors is assigned or modified.

.NET 9 support timeline

Syncfusion has announced that support for .NET 9 in its .NET MAUI controls will end following the release of .NET 11 GA in November 2026.

If your projects target .NET 9, plan a framework upgrade alongside the control upgrade to maintain access to future updates and support.

For complete migration details, review the official What’s New and release notes documentation before upgrading.

Frequently Asked Questions

Q1: Which .NET MAUI controls are production-ready?

The Rich Text Editor is now production-ready. The five controls introduced in this release, TreeGrid, Data Pager, Diagram, Grid Splitter, and Interactive Viewer, remain in preview.

Q2: Does .NET MAUI 2026 Volume 3 support .NET 9 and .NET 10?

Yes. The release supports both .NET 9 and .NET 10. However, Syncfusion has announced that .NET 9 support will end following the release of .NET 11 GA in November 2026.

Q3: Are there breaking changes in v35.1.37?

Yes. Breaking changes affect Data Pager, Rich Text Editor, and Color Picker. Review the package, API, and collection changes described above and consult the official release notes before upgrading your application.

Conclusion

Syncfusion .NET MAUI 2026 Volume 3 introduces five new controls for hierarchical data, large datasets, diagrams, interactive content, and flexible layouts. It also brings updates to DataGrid, Scheduler, Charts, AI AssistView, SignaturePad, and Rich Text Editor.

These enhancements give developers more options for building data-driven interfaces, interactive experiences, and content-editing workflows.

If you’re upgrading to Essential Studio^® 2026 Volume 3, review the breaking changes and .NET support timeline before updating your application.

Explore the latest .NET MAUI controls and try the new features in the interactive demos.

New to Syncfusion? Start with the .NET MAUI free trial.

If you have questions or feedback, reach out through our support forums, feedback portal, or support portal.

Related Blogs

Struggling with Complex Document Tasks? Explore Syncfusion Essential Studio 2026 Volume 3

Jollen Moyani — Thu, 08 Oct 2026 13:53:20 +0000

TL;DR: Building collaboration, review, and automation into document solutions can require significant custom development. Syncfusion Essential Studio 2026 Volume 3 adds real-time collaboration, PDF comparison, AI-assisted document operations, form recognition, enhanced review tools, and spreadsheet capabilities across the PDF Viewer, DOCX Editor, and Spreadsheet Editor.

Need more than basic document functionality?

Document solutions often require capabilities that go beyond viewing and editing. Collaboration, document comparison, form recognition, automation, and spreadsheet validation can all become part of the same process.

Supporting all these capabilities can require multiple layers of custom development.

Syncfusion^® Essential Studio 2026 Volume 3 introduces new capabilities across the PDF Viewer, DOCX Editor, and Spreadsheet Editor to simplify document-centric development.

From real-time collaboration and PDF comparison to AI-assisted document operations, form recognition, and spreadsheet validation, this release adds capabilities for building more complete document solutions.

Let’s explore what’s new and how these capabilities can help you build document solutions faster.

What’s new in Essential Studio 2026 Volume 3

This release brings new capabilities for collaboration, document review, automation, and spreadsheet data management.

PDF Viewer: Real-time collaboration, link annotations, document comparison, AI-assisted document operations, form recognition, digital signatures, thumbnail navigation, and document modification tracking.
DOCX Editor: Author-based comment highlighting, customizable colors for tracked changes and revision types, and AI-assisted document operations.
Spreadsheet Editor: Rich text formatting, text overflow, real-time collaboration, AI-assisted spreadsheet operations, data validation, find and replace, charts, expanded APIs, and worksheet tab controls.

Together, these updates support key document scenarios such as collaboration, review, automation, and data management.

PDF Viewer: Simplify collaboration, review, and document processing

Displaying a PDF is often just the beginning of a broader document process. Once users need to review, approve, annotate, compare, or process documents, additional capabilities become essential.

Web PDF Viewer

Collaborate on PDFs in real time

Contract reviews and approval processes often involve multiple users working with the same document. Managing separate copies can lead to duplicate annotations, conflicting changes, and outdated versions.

The Web PDF Viewer now supports real-time collaboration for annotations, form fields, and page organization. Multiple users can work on the same PDF simultaneously, while changes made by one participant are automatically synchronized with others.

This provides a shared document experience that helps teams review and edit PDFs without managing separate document copies.

Real-time collaborative editing in Web PDF Viewer

Add links for easier PDF navigation

Long PDFs can be difficult to navigate when users need to move between sections or access related resources.

The PDF Viewer now supports web-link and document-link annotations. Users can create, edit, and delete interactive links that open external websites or navigate to specific pages and locations within the same PDF.

This can be useful for technical documentation, manuals, compliance records, and other lengthy documents.

Adding navigation and reference links in PDF Viewer

Add custom text stamps to document reviews

Document approval processes often need clear status markers such as Approved, Rejected, or Needs Revision.

With custom text stamps, users can create personalized stamp annotations using custom text instead of static images. They can configure the stamp title, font, text color, background color, and optional author, date, and time information, with a live preview during creation.

For example, a compliance reviewer can apply a review-status label directly to a policy document while preserving the review context for future reference.

Adding custom text stamps in PDF Viewer

Compare PDF versions and identify changes

Comparing lengthy versions of contracts or policies manually can make it difficult to identify the changes that matter.

The PDF Viewer now supports semantic text comparison between two PDF documents. It identifies added, deleted, and modified text and provides detailed difference information through a dedicated API.

Instead of manually reviewing both documents page by page, users can focus on the content that changed.

This can be especially useful for legal agreements, HR policies, regulatory documents, and other documents that go through frequent revisions.

Automate PDF tasks with AI agents

PDF-related tasks often involve repetitive operations such as content extraction, page navigation, annotation management, form processing, and data redaction.

With WebMCP tools, AI agents can interact with PDF documents and automate operations such as:

Document navigation
Content extraction
Annotation management
Form field operations
Redaction
Document actions

These capabilities also support document analysis, summarization, and automated form processing.

Developers and users remain in control through review, approval, customization, and undo/redo support. This makes it possible to automate routine PDF operations while keeping important decisions with the user.

Blazor Smart PDF Viewer

Turn scanned forms into interactive documents

Scanned forms often require users or developers to manually recreate fields before the documents can be used digitally.

The Blazor Smart PDF Viewer now supports form recognition for scanned or image-based PDF documents. It can detect text boxes, check boxes, radio buttons, and signature fields and convert them into interactive PDF form fields while preserving their positions.

For registration, onboarding, customer-intake, or application-processing solutions, this can help turn scanned forms into usable digital documents.

Scanning form elements in Blazor PDF Viewer

.NET MAUI Smart PDF Viewer

Simplify PDF processing with AI

Processing PDFs often involves repetitive tasks such as filling forms, identifying sensitive information, and extracting insights from lengthy documents.

The .NET MAUI Smart PDF Viewer, available in preview, introduces AI-powered capabilities for Smart Form Fill, Smart Redaction, and Document Summarization. These features can help users populate form fields, identify and redact sensitive information, and generate concise summaries directly within their applications.

This can simplify document processing while helping users work with PDF content more efficiently.

Adding and validating digital signatures in .NET MAUI PDF Viewer

Navigate PDFs with thumbnail previews

Large PDFs can be difficult to navigate on smaller screens.

The .NET MAUI PDF Viewer now supports thumbnail previews of PDF pages. Users can open a thumbnail pane on desktop and tablet devices or a dedicated thumbnail view on mobile devices, then select a thumbnail to jump directly to a page.

This provides a more visual way to browse and navigate lengthy documents.

Page navigation with thumbnail preview option

Track document modifications with a unified property

Document-based applications often need to know whether a PDF has changed before allowing users to save, close, or submit it.

The .NET MAUI PDF Viewer now provides the centralized IsDocumentModified property to indicate whether the loaded PDF has been modified since it was loaded or last saved.

The property tracks supported changes such as annotation updates, form field edits, signature changes, comments, redactions, and import actions. This removes the need to subscribe to multiple feature-specific events when checking whether a document has changed.

DOCX Editor: Improve document review

Managing PDFs is often just one requirement within a larger document solution. DOCX-based applications also need clear review tools when multiple contributors edit and comment on the same document.

Web and Blazor DOCX Editors

The DOCX Editor updates in this release focus on author visibility, tracked changes, revision types, and AI-assisted document operations across Web and Blazor platforms.

Highlight comments by author

When several people review a document, identifying each person’s comments can become difficult.

The DOCX Editor now supports avatar-based colors for comments. Comment markers and pane borders use the author’s avatar color, while the corresponding commented text is highlighted with the same color when a comment is selected.

This makes it easier to distinguish and track comments from multiple authors during collaborative review.

Avatar-based comment highlighting in DOCX Editor

Customize colors for tracked changes

Documents with many revisions can become difficult to review when every change looks the same.

The DOCX Editor now lets you specify custom colors for tracked changes. Each user’s revisions can be displayed using colors selected from a defined set, providing clearer visual separation between changes made by different authors.

This can make collaborative review easier to follow in contracts, proposals, policies, and technical documentation.

Custom colors for tracked changes in DOCX Editor

Distinguish different revision types

Not all document changes have the same meaning. Insertions, deletions, and table-row changes may need to be identified separately during review.

The DOCX Editor supports separate colors for insertion and deletion revisions and for inserted and deleted table rows. Each revision type can use a specific color or author-based coloring.

This provides a clearer way to distinguish the types of edits made during collaborative document review.

Web DOCX Editor

Automate DOCX tasks with AI agents

Many document processes involve repetitive editing tasks such as inserting content, replacing text, updating formatting, managing bookmarks, protecting documents, and exporting files.

With WebMCP tools, AI agents can interact with the DOCX Editor to automate these operations:

Content insertion
Find and replace
Formatting
Bookmark management
Document protection
File exporting

Users can then review the changes before they are finalized.

For example, an HR application could use approved templates to update employee agreements while allowing a reviewer to verify the final document before distribution.

Spreadsheet Editor: Boost spreadsheet productivity

Document management often extend beyond PDFs and DOCX files. Spreadsheets are equally important in applications that manage business data, reporting, budgeting, and operational processes.

The Spreadsheet Editor introduces updates across Web, Blazor, and WinForms for formatting, collaboration, AI-assisted operations, validation, visualization, customization, and worksheet presentation.

Web Spreadsheet Editor

Create richer spreadsheet content

A single spreadsheet cell may need to contain text with multiple formatting styles.

The Web Spreadsheet Editor now supports rich text formatting, allowing users to apply bold, italic, underline, strikethrough, font family, font size, and font color to selected portions of text.

Multiple formatting styles can coexist within the same cell, along with existing subscript and superscript support.

Display overflowing cell content

Long cell content can be difficult to read when it is limited by the cell boundary.

The Web Spreadsheet Editor now supports text overflow, allowing content to extend beyond cell boundaries when adjacent cells are empty. The feature supports plain text, rich text, hyperlinks, and merged cells.

When neighboring cells contain data, the overflowing content is automatically clipped to maintain a clean worksheet layout.

Text overflow support in Spreadsheet Editor

Collaborate on spreadsheets in real time

When multiple users work with the same workbook, keeping everyone synchronized is essential.

The Web Spreadsheet Editor now supports collaborative editing, allowing multiple users to view and edit the same spreadsheet while seeing real-time updates, user presence, remote selections, and editing indicators.

The collaboration support also handles synchronization of workbook actions, late-join synchronization, missing-action recovery, and conflict resolution for concurrent spreadsheet operations.

Text overflow support in Spreadsheet Editor

Automate spreadsheet operations with AI agents

Beyond data entry, spreadsheet processing often involves repetitive analysis, formatting, calculations, and data transformations.

With WebMCP tools, AI agents can interact with the Spreadsheet Editor and automate these operations across workbooks. Developers and users can retain control through review, approval, customization, and undo support.

This provides a way to automate structured spreadsheet processes while keeping AI-assisted changes under user control.

Blazor Spreadsheet Editor

Improve spreadsheet data accuracy with validation

A small data-entry mistake can affect calculations and reports across an entire spreadsheet.

The Blazor Spreadsheet Editor now supports data validation for whole numbers, decimals, dates, times, text length, lists, and custom formulas. These rules can be applied to selected ranges to help ensure that users enter valid data.

For HR, finance, and operations applications, this allows data rules to be enforced directly within the spreadsheet.

Data validation in Blazor Spreadsheet Editor

Find and replace data across worksheets and workbooks

Large workbooks can make it difficult to locate and update specific values manually.

The Blazor Spreadsheet Editor now supports find and replace feature, allowing users to search within a worksheet or across an entire workbook, navigate to matching cells, and replace individual or all occurrences.

The feature also supports case-sensitive, exact-match, and row- or column-based searches.

Find and replace in Blazor Spreadsheet Editor

Visualize spreadsheet data with charts

Spreadsheet data is often easier to understand when it is presented visually.

The Blazor Spreadsheet Editor now supports creating charts from selected data ranges to highlight trends, comparisons, and relationships. Users can create column, bar, area, pie, line, and scatter charts and customize chart elements, row and column orientation, and themes.

Charts also update dynamically when the source data changes, helping users keep visualizations aligned with their underlying data.

Charts in Blazor Spreadsheet Editor

Customize spreadsheet behavior with expanded APIs

Standard spreadsheet behavior may not always match an application’s requirements.

The Blazor Spreadsheet Editor now provides expanded event support for spreadsheet lifecycle changes, user actions, menu interactions, and formatting operations. These events allow applications to validate or customize actions, track operation outcomes, and tailor spreadsheet behavior.

This provides greater control when building interactive spreadsheet experiences for planning, operations, and reporting applications.

WinForms Spreadsheet Editor

Create a more focused spreadsheet workspace

Not every application needs users to move between multiple worksheets.

The WinForms Spreadsheet Editor now lets you show or hide worksheet tabs. The sheet tab visibility can be controlled through the UI or API, helping reduce visual clutter when users only need to work with a specific sheet.

For focused data-entry applications, this provides a cleaner workspace with more room for worksheet content.

Controlling worksheet tabs in WinForms Spreadsheet Editor

Frequently Asked Questions

Q1: How are comments from different reviewers identified in a DOCX document?

The DOCX Editor uses author-specific avatar colors to highlight comments and related text, making feedback easier to track during reviews.

Q2: What are the benefits of rich text formatting within spreadsheet cells in the Web Spreadsheet Editor?

Rich text formatting lets you apply bold, italic, underline, colors, and different font sizes within a single cell. This improves readability and highlights key information without using multiple cells.

Q3: How does the Web PDF Viewer simplify navigation and document reviews in PDF files?

The Web PDF Viewer supports web links, document links, and PDF comparison, enabling easier navigation and quick identification of document changes.

Q4: Can different versions of PDF documents be compared in the Web PDF Viewer?

Yes. Semantic PDF comparison highlights meaningful changes between documents, helping reviewers quickly identify updates.

Q5: What AI-powered document processing features are available in the .NET MAUI PDF Viewer?

The .NET MAUI Smart PDF Viewer supports AI-powered form field detection, data extraction, and document understanding to help automate PDF processing with less manual effort.

Q6: How is real-time collaborative editing supported for PDF documents and spreadsheets?

Syncfusion supports simultaneous editing with real-time updates, user presence indicators, and synchronized collaboration for PDFs and spreadsheets.

Build complete document solutions with less custom infrastructure

Consider a contract management platform where a scanned agreement needs to become an interactive PDF form. Multiple reviewers need to collaborate on the document, legal teams need to track revisions in DOCX files, and business teams need to manage related information in spreadsheets.

Supporting these requirements independently can quickly increase development effort.

Syncfusion Essential Studio 2026 Volume 3 brings capabilities across the PDF Viewer, DOCX Editor, and Spreadsheet Editor for collaboration, review, AI-assisted automation, document processing, data validation, and visualization.

These capabilities help reduce custom development so you can focus on building the application-specific features your users need.

Explore what’s new in Syncfusion Essential Studio 2026 Volume 3

The 2026 Volume 3 release adds capabilities for building richer document experiences across web, desktop, and mobile applications.

Explore the complete release to see how the latest PDF Viewer, DOCX Editor, and Spreadsheet Editor features can fit into your applications.

New to Syncfusion? Start a free 30-day trial to evaluate the latest Essential Studio capabilities in your applications.

Already using Syncfusion? Download the latest version from the License and Downloads page.

If you have questions or suggestions, feel free to reach out through our support forum, support portal, or feedback portal. We are always happy to help you!

Related Blogs

Introducing the .NET MAUI Interactive Viewer Control for Interactive Content

Jollen Moyani — Wed, 07 Oct 2026 11:47:35 +0000

TL;DR: The new .NET MAUI Interactive Viewer control makes it easier to explore detailed visual content with built-in zooming, panning, rotation, and view reset. Learn how to add interactive viewing experiences for images, diagrams, technical drawings, floor plans, and other graphical content in .NET MAUI applications.

When visual content needs closer inspection, a single fixed view may not provide enough flexibility. Users may need to zoom in on a specific detail, pan across the content, rotate the view, or return to the starting position. Handling these interactions can add extra implementation work when an application requires a complete viewing experience.

The new .NET MAUI Interactive Viewer control, introduced in Essential Studio^® 2026 Volume 3, brings these capabilities together in a single control. It provides configurable viewing interactions for applications that need users to inspect and navigate detailed visual content in .NET MAUI applications.

In this blog, we’ll explore the Interactive Viewer’s key capabilities and walk through how to integrate it into a .NET MAUI application.

Key features

The .NET MAUI Interactive Viewer provides:

Zoom and pan interactions
Content rotation
View reset
Light and dark theme support
Support for hosting any .NET MAUI view

Let’s look at how to use these capabilities.

Zoom and pan content

Detailed content is often difficult to inspect when it is restricted to its original size. Users may need to zoom into a particular area and then move around the content without leaving the viewing context.

The Interactive Viewer provides zoom and pan interactions for this scenario, making it suitable for images, diagrams, floor plans, and other detailed content.

The MinimumZoomFactor and MaximumZoomFactor properties allow developers to define the minimum and maximum zoom levels. The IsZoomEnabled and IsPanEnabled properties can also be used to control zooming and panning.

Zoom and Pan in .NET MAUI Interactive Viewer

Rotate content

Some visual content needs to be viewed from different orientations. For example, users may want to rotate an image, diagram, or technical drawing to inspect it from another orientation.

The Interactive Viewer provides rotation support alongside its zoom and pan capabilities.

The Rotate() method rotates the hosted content 90 degrees clockwise with each call, allowing you to view the content in different orientations.

Rotate content support in .NET MAUI Interactive Viewer

Reset the view

After zooming, panning, or rotating content, users may need to return to its original state.

The Interactive Viewer provides a reset operation that restores the view by resetting the zoom level, pan position, and rotation changes.

Reset support in .NET MAUI Interactive Viewer

Support light and dark themes

The Interactive Viewer supports light and dark application themes, so it integrates with applications that use them.

Dark theme support in .NET MAUI Interactive Viewer

Host any .NET MAUI view

The Interactive Viewer is not limited to images. It can host any .NET MAUI view, allowing developers to add interactive viewing capabilities to different types of visual content. For example, you can place a diagram or custom graphical view inside the viewer and explore it using zooming, panning, and rotation.

Content viewing support in .NET MAUI Interactive Viewer

Common use cases

Because the Interactive Viewer can host visual content beyond basic image viewing, you can use it in a range of scenarios.

Common use cases include:

Large image and photo viewers
Interactive product image viewing
Floor plans and diagrams
Technical drawings and blueprints
Medical images and diagnostic reports
Monitoring applications that require detailed visual inspection

Developers can also host custom layouts and other .NET MAUI views when an application requires interactive handling for custom content.

For complete API details and customization options, refer to the .NET MAUI Interactive Viewer documentation.

Getting started with the .NET MAUI Interactive Viewer

Let’s add an image to the Interactive Viewer and configure its zoom range.

Create a project and install the package

Start by creating a new .NET MAUI application in Visual Studio. Then, install the Syncfusion.Maui.InteractiveViewer package using the NuGet Package Manager to add the Interactive Viewer control to your project.

You can also install the package using the .NET CLI:

.NET CLI

dotnet add package Syncfusion.Maui.InteractiveViewer

Register Syncfusion Core

Then, register the Syncfusion Core handler in the MauiProgram.cs file:

using Syncfusion.Maui.Core.Hosting;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();

        builder.ConfigureSyncfusionCore();

        // ...

        return builder.Build();
    }
}

Add the namespace and control

Import the Interactive Viewer namespace into your XAML page:

XAML

xmlns:interactiveViewer="clr-namespace:Syncfusion.Maui.InteractiveViewer;assembly=Syncfusion.Maui.InteractiveViewer"

Then, add the SfInteractiveViewer control and place an image inside it:

XAML

<interactiveViewer:SfInteractiveViewer
    x:Name="interactiveViewer"
    MinimumZoomFactor="1"
    MaximumZoomFactor="4">

    <Image
        Source="interactiveviewerimage.png"
        Aspect="AspectFit" />

</interactiveViewer:SfInteractiveViewer>

In this example, MinimumZoomFactor and MaximumZoomFactor define the zoom range for the image.

Run the application to interact with the image using the supported viewing operations.

The Interactive Viewer can also host other .NET MAUI views when an application requires interactive handling for custom content

GitHub reference

To explore the control with a working example, refer to the Interactive Viewer demo on GitHub. For API details, configuration options, and additional examples, see the .NET MAUI Interactive Viewer documentation.

Frequently Asked Questions

Q1: When should I use the Interactive Viewer instead of implementing gesture recognizers manually?

The Interactive Viewer is useful when an application requires multiple viewing interactions, such as zooming, panning, rotation, and resetting the view. These capabilities are provided through a single control, reducing the need to implement the viewing interactions separately.

Q2: Can I display custom layouts and controls inside the Interactive Viewer?

Yes. The Interactive Viewer can host any .NET MAUI view, not just images. This allows developers to use it with layouts, custom controls, dashboards, diagrams, and other visual content.

Q3: Can I control the zoom range?

Yes. The Interactive Viewer provides zoom-related properties that allow developers to configure the viewing experience. The MinimumZoomFactor and MaximumZoomFactor properties define the supported zoom range, while ZoomFactor can be used to control the current zoom level.

Q4: Can I respond to zoom or pan changes?

Yes. The Interactive Viewer provides the ZoomFactorChanged and ScrollChanged events, allowing applications to respond to changes in zoom level and pan position.

Q5: Can I rotate the content programmatically?

Yes. The Rotate() method rotates the hosted content 90 degrees clockwise with each call.

Conclusion

Interactive content often requires several coordinated operations, including zooming, panning, rotation, and view reset. Implementing these behaviors independently can add gesture and transformation logic to an application.

The .NET MAUI Interactive Viewer brings these interactions together in a single control and can host both images and other .NET MAUI views. With configurable zooming, rotation, reset, events, and theme support, it provides a flexible way to add interactive content viewing to .NET MAUI applications.

To explore the control further, refer to the Interactive Viewer documentation and demo. You can explore the complete What’s New and Release Notes documentation to discover the features most relevant to your project.

For existing Syncfusion customers, the latest version of Essential Studio is available from the License and Downloads page. New users can explore the capabilities through the 30-day free trial.

If you have questions or feedback, reach out through our support forums, feedback portal, or support portal.

Related Blogs

Explore the Syncfusion Showcase App Browser: Discover Application Examples

Jollen Moyani — Tue, 06 Oct 2026 12:38:02 +0000

TL;DR: Discover how real-world applications are built using Syncfusion UI components across web, desktop, and mobile platforms. Explore showcase examples by industry, use case, platform, or component, see how controls such as DataGrid, Charts, Scheduler, Diagram, and Document Editor work together, and access demos and source code to accelerate your next project.

Choosing the right UI component is only the beginning. The bigger question is how those components fit together when building a complete application.

That’s where real application examples can make a difference. The Syncfusion Showcase brings together 50+ examples built using Syncfusion UI components across web, desktop, and mobile platforms, covering scenarios such as sales, healthcare, business process modeling, and document management.

You can explore these Syncfusion Showcase App based on the platform, component, industry, or use case that interests you. You can also run available live demos, explore application workflows, and view source code where provided.

More than templates: Built with Syncfusion components

Unlike traditional template galleries that primarily provide ready-made UI layouts, the Syncfusion Showcase features applications built using Syncfusion UI components.

This means you can explore more than the visual design of an application. You can see how reusable components such as DataGrid, Charts, Scheduler, Kanban, Diagram, Document Editor, and PDF Viewer are combined to build complete application experiences.

Each application also helps you identify the Syncfusion components used, allowing you to move from an application example to the relevant component documentation, demos, and code examples.

This makes the Showcase useful not only for finding application inspiration, but also for understanding which reusable components you can use to build a similar application.

Explore applications across platforms

The Showcase includes applications associated with React, Angular, JavaScript, Vue, WPF, .NET MAUI, ASP.NET Core, ASP.NET MVC, and Blazor.

Platform availability varies by application. Each application’s details show the platforms available for live demos and source code.

For example, the Webmail showcase provides live demos and source code for Angular, JavaScript, JavaScript ES5, ASP.NET Core, and ASP.NET MVC. Other applications offer different platform combinations that you can explore individually.

Discover applications based on what you need

How you explore the Showcase can depend on where you are starting.

Explore by industry for scenarios such as sales, healthcare, finance, construction, and retail. Use use case filters to find relevant workflows, or explore by component to see how a Syncfusion component is used across different applications.

You can also filter by platform to find examples for your preferred technology.

For example, if you are building a sales application and want to see how Charts are used in that context, you can narrow the collection by the relevant industry and component.

You can combine these options to narrow the collection around a specific requirement. For example, you can search for sales-related applications that use Charts and then explore the available examples for selected platforms.

See how components work together

The Showcase provides a broader view of Syncfusion components by bringing multiple capabilities together within an application.

Let’s take Sales CRM & Pipeline Intelligence as an example. It combines DataGrid, Charts, Kanban, and AI AssistView to support a sales-focused application involving accounts, opportunities, and forecasts.

Appointment Planner takes a different approach, combining Scheduler, DataGrid, and Charts for a clinic scheduling scenario.

For workflow visualization, BPMN Editor uses the Diagram component to design, visualize, and refine business processes.

The Document Explorer brings together File Manager, Document Editor, Spreadsheet, and PDF Viewer to create a shared workspace for browsing, viewing, and editing documents.

These examples show the range of application scenarios available in the Showcase and how different Syncfusion components can be used together.

Explore the application beyond the interface

An application example can tell you more than what is visible in its interface.

Open an application’s details page to learn about its purpose, workflows, intended users, business value, and the Syncfusion components used. You can then try the available demo and explore source code where provided.

The demo and source-code options are listed separately because they can differ by platform. An application may provide a live demo for one platform while offering source code for several platforms.

Sales CRM and Pipeline Intelligence app

Continue exploring through component tags

Sometimes, the first application you find leads to another question: Where else is this component being used?

Component tags let you continue that exploration.

Selecting a component such as Diagram can lead to other showcase applications involving visual modeling. Exploring DataGrid can reveal applications that use structured data views within different workflows.

Instead of stopping with one example, you can use these connections to discover related applications across the collection.

Explore a few Syncfusion Showcase apps

The collection includes applications covering different scenarios and component combinations. Here are a few examples to explore:

Sales CRM and Pipeline Intelligence

Explore a sales application for managing accounts, opportunities, and forecasts with DataGrid, Charts, Kanban, and AI AssistView.

Appointment planner

Explore a clinic scheduling application that combines Scheduler, DataGrid, and Charts for appointment planning and utilization insights.

BPMN Editor

Explore business process modeling with the Diagram component, including process design and refinement.

Document Explorer

Explore a document workspace that combines File Manager, Document Editor, Spreadsheet, PDF Viewer, and Image Editor.

Frequently Asked Questions

Q1: Can I Use a Showcase App as the Starting Point for a Commercial Project?

A showcase can provide implementation ideas, but access to its source code does not automatically grant every permission needed for commercial use. Review the repository’s license and the applicable Syncfusion licensing terms before reusing or distributing code.

Q2: Are Showcase Applications Ready for Production Deployment?

Treat each showcase as an example for evaluation, not as a guarantee of production readiness. Before deployment, review authentication, authorization, data validation, accessibility, error handling, performance, and dependency security based on your requirements.

Q3: How Should I Compare Implementations on Different Platforms?

Evaluate the same workflow across each available implementation, including behavior, accessibility, responsiveness, and integration needs. Similar application names do not guarantee feature parity, and demo availability may differ from source-code availability.

Q4: Can I Deploy an Example to My Existing Hosting Environment?

That depends on the example’s framework, build output, backend services, and runtime requirements. Follow the repository instructions and confirm that your hosting environment supports those requirements before planning a deployment.

Q5: Can I Connect an Example to My Own Backend or Database?

That depends on the design of the specific implementation. Review the application’s data layer and API contracts carefully, keep credentials on the server, apply appropriate access controls, and test changes with nonproduction data before connecting business systems.

Q6: Should I Enter Real Customer Data Into a Public Demo?

Avoid entering confidential, personal, or production data into a public demo unless its data-handling terms explicitly support your use. Synthetic data and controlled environments are safer for evaluating workflows that involve sensitive information.

Q7: Do These Examples Replace Component Documentation?

No. Showcase applications help you understand workflow context. Component documentation remains the best source for supported APIs, configuration details, limitations, and version-specific behavior.

Q8: How Can My Team Keep an Evaluation Reproducible as the Examples Change?

Record the repository URL, commit or release reference, dependency versions, and the workflows your team evaluated. A saved gallery link can preserve your discovery criteria, but it does not freeze a live demo or repository contents.

Explore the Syncfusion Showcase

The Syncfusion Showcase brings together application examples across platforms, industries, use cases, and components.

Whether you are exploring a particular technology, looking for a component in a broader application context, or browsing examples for a specific business scenario, the collection provides different ways to discover relevant applications.

Explore the Syncfusion Showcase and discover application examples built with Syncfusion UI components.

Related Blogs

Build Agent-Driven UI Designs Faster Using Syncfusion A2UI Composer

Jollen Moyani — Thu, 01 Oct 2026 15:20:53 +0000

TL;DR: Syncfusion A2UI Composer helps developers turn natural-language prompts into Syncfusion A2UI Composer helps developers turn natural-language prompts into structured A2UI definitions that can be previewed, refined, and used in application experiences.

Start from a prompt or template, preview the result using Syncfusion components, refine it through AI-assisted changes or direct JSON editing, and copy the resulting A2UI definition into your application. Composer handles the design-time experience, while Syncfusion A2UI Components handle runtime rendering across supported environments including React, Angular, Blazor, and .NET MAUI.

AI applications often need more than text responses.

A user might ask for last quarter’s sales by region, an inventory overview, a customer summary, or an appointment workflow. In these cases, the useful result may be an interactive grid, chart, form, scheduler, or combination of components rather than another block of text.

Turning an interface idea into a working experience often takes several iterations. Developers need to decide which components to use, arrange the layout, review the result, and make changes before the interface is ready to use.

A2UI Composer provides a visual way to simplify this process. Instead of starting with UI implementation, developers can describe the experience they want using a natural-language prompt or start from a ready-made template.

Composer generates a structured A2UI definition that can be previewed, refined, and edited before it is used in an application. With support for Syncfusion components, developers can explore and shape AI-powered interfaces while working with familiar UI building blocks.

Composer is the design-time part of the Syncfusion A2UI workflow. It helps you define and refine the surface; the runtime renders that definition inside the application.

Two halves of the same A2UI workflow

Syncfusion separates interface authoring from application rendering.

	Design time	Runtime
Tool	A2UI Composer	A2UI Components + renderer
Purpose	Prompt or template → preview → refine → A2UI definition	Agent/backend emits A2UI messages → renderer maps them to Syncfusion UI
Result	Reusable, inspectable interface definition	Interactive application UI

Composer is an optional authoring path. Teams can use it when they want to design and refine the expected interface structure first, then use that definition directly in the application or bind it to the agent workflow.

What is A2UI?

A2UI is a declarative approach for describing user interfaces as structured data instead of framework-specific UI code. A renderer interprets the definition and maps it to supported UI components.

For example, an A2UI definition can describe a button, its content, and an interaction event without defining the complete framework-specific UI implementation.

This separation is what allows Composer to stay focused on interface authoring rather than on one specific application framework.

Meet Syncfusion A2UI Composer

Syncfusion A2UI Composer is an AI-powered interface authoring environment that helps teams transform natural-language prompts into structured, reusable interface definitions.

It is designed for prompt-to-UI and AI-assisted design workflows, helping developers move from an initial idea to an interface that can be previewed and refined.

The resulting definition can then be taken into a supported application environment or used as the expected UI structure in an agent workflow

How A2UI Composer works

Composer brings together prompts, visual refinement, and structured interface definitions in one workflow.

A typical Composer flow is:

Describe: Start by describing the interface you need or selecting a starter template.

For example:

Create an inventory dashboard showing stock levels, low-inventory alerts, and warehouse performance metrics.

Preview: See the generated interface rendered with Syncfusion components.
Refine: Adjust the layout, components, and data through AI-assisted changes or direct JSON editing.
Copy: Take the resulting A2UI definition into your application.

Describe → Preview → Refine → Copy

This provides a practical path from an interface idea to a structured definition without starting with a complete application implementation.

A2UI Composer workflow

Explore the A2UI Composer Experience

Composer includes focused areas for generating, refining, exploring, and reviewing A2UI interfaces.

Create: Generate an interface from a natural-language prompt or a starter template.
Workspace: Refine the interface with AI, edit A2UI JSON directly, and review the live preview in the same authoring environment.
Gallery: Browse reusable starter experiences and open them in Composer. Starter examples include:
- Operations Dashboard
- CRM Overview
- Finance Summary
- Inventory Tracker
Playground: Experiment with individual components and structured definitions without creating a full interface.
Catalog: Explore the Syncfusion component adapters currently supported by A2UI

Composer Workspace

The Workspace provides the tools needed to refine an interface after its initial generation.

AI Assistant

Use natural-language instructions to request interface changes, such as layout updates, additional fields, styling adjustments, or supported changes to the interface. Composer applies the requested changes to the definition.

JSON Editor

For direct control, the JSON Editor provides access to the underlying A2UI definition. Developers can inspect and edit the generated structure while reviewing the result.

Live Preview

The Live Preview renders the interface as changes are made, allowing developers to review the result without switching between the definition and rendered experience.

Together, these capabilities create a workflow for creating, reviewing, and refining A2UI interfaces.

Building and refining an interface in the A2UI Composer Workspace

Build with supported Syncfusion Components

A2UI Composer uses supported Syncfusion components as building blocks for generated interfaces.

These include:

Data and visualization: Data Grid, Tree Grid, Charts, Maps, and HeatMap.
Input: TextBox, ComboBox, and Dropdown.
Scheduling: Scheduler, Calendar, and Gantt Chart.
Navigation and layout: Menu, Breadcrumb, Pager, Tabs, Cards, and placeholders.
Documents: PDF Viewer, DOCX Editor, and Spreadsheet Editor.

Component availability is defined by the supported A2UI catalog. Do not assume that every Syncfusion component is currently available through A2UI; check the catalog when designing an interface around a specific control.

From Composer to an application

Composer focuses on creating and refining the interface definition. The resulting A2UI definition can then move into a supported application workflow.

The process can be represented as:

At runtime, Syncfusion A2UI Components process the structured messages, map them to supported Syncfusion components, connect the required data, and handle user interactions.

Use Composer definitions across supported platforms

A2UI Composer itself is not tied to React. It produces the structured definition; the runtime platform determines how that definition is rendered.

Syncfusion currently provides A2UI runtime integration for:

Platform	Package
React	@syncfusion/ej2-react-a2ui
Angular	@syncfusion/ej2-angular-a2ui
Blazor	Syncfusion.Blazor.A2UI
.NET MAUI	Syncfusion.Maui.A2UI

Support for more platforms is planned.

This means the same Composer workflow can feed supported runtime implementations without making Composer itself framework-specific.

How the runtime uses the definition

Once the A2UI definition reaches the application, the runtime takes over.

Depending on the platform integration, it can:

Validate incoming A2UI messages before rendering.
Map definitions to supported Syncfusion components.
Connect structured data to interactive controls.
Process surface updates.
Route user actions back to the application or agent workflow.

This keeps the interface definition separate from the application rendering layer.

Platform integration is a separate step

Composer stops at the structured definition. Integration into the application remains an engineering step.

For example:

React applications install and configure the React A2UI runtime.
Angular applications use the Angular A2UI runtime and catalog.
Blazor applications register the A2UI services and renderer.
.NET MAUI applications use the corresponding MAUI A2UI package.

This separation lets Composer remain platform-neutral while each supported runtime integrates with its own application environment.

How A2UI Composer differs from traditional AI UI Builders

Many AI-powered UI tools focus on generating application code from prompts.

While this can accelerate prototyping, the generated code still needs to be reviewed, modified, tested, and maintained.

A2UI Composer takes a different approach by generating structured interface definitions that can be rendered through supported A2UI runtimes.

Traditional AI UI generation	Syncfusion A2UI Composer
Generates application UI code	Generates structured A2UI definitions
UI implementation is part of the generated output	Interface definition is separated from rendering
Generated code requires review and maintenance	Definitions can be refined and reused
Focuses on implementation generation	Focuses on interface composition

The key difference is the focus on structured interface composition rather than generating a new UI implementation for every request.

Why this pattern matters?

For application teams, the value is not only faster interface creation.

Structured: A2UI definitions make the interface explicit and inspectable, giving the agent and application a clearer interface contract.
Reusable: Supported components and interface patterns can be reused across multiple agent workflows.
Consistent: Agent-driven interfaces can use the same Syncfusion building blocks already used in the application.
Governable: The application controls the supported catalog and runtime instead of allowing an agent to generate arbitrary application markup.

A practical A2UI experience

Consider an inventory application.

Start with:

Create an inventory dashboard showing stock levels, low-inventory alerts, and warehouse performance metrics.

Composer generates an initial definition and preview.

- You can then refine it with requests such as:

Add a supplier filter.

or:

Move the low-stock items into a separate section.

The Workspace updates the structured definition, and the Live Preview lets you review the result.
Once the definition is ready, copy it into a supported application workflow or use it as the UI structure expected from the agent.

This demonstrates the role of Composer clearly: design and refine the experience before runtime integration.

AI-generated flight search form in the SkyBook application

AI-generated flight results rendered in the SkyBook application

AI-generated flight booking confirmation in the SkyBook application

Where to start

If you want to...	Start with...
Create an interface from a prompt	Create
Start from an existing example	Gallery
Refine AI output and edit JSON	Workspace
Test individual components	Playground
Check supported components	Catalog
Render the resulting definition	A2UI Components for your application platform

Conclusion

Syncfusion A2UI Composer provides a visual way to turn interface ideas into structured A2UI definitions.

With prompts, templates, AI-assisted refinement, JSON editing, live preview, and supported Syncfusion components, developers can create and refine reusable interfaces before integrating them into application workflows.

Composer remains platform-neutral at design time. The resulting A2UI definitions can then be rendered through supported Syncfusion A2UI runtimes for React, Angular, Blazor, and .NET MAUI.

This separation gives teams a clear workflow: design the surface in Composer when needed, then render it through the application runtime that matches their technology stack.

Try A2UI Composer

Open Syncfusion A2UI Composer, start from a prompt or template, preview the result, refine the definition, and take the resulting A2UI JSON into your application workflow.

Try Syncfusion A2UI Composer and explore a structured path from an interface idea to an agent-driven application experience.

Introducing Syncfusion A2UI: Build Agent-Driven Interfaces with Reusable UI Components

Lucy Muturi — Thu, 01 Oct 2026 12:03:06 +0000

TL;DR: Syncfusion A2UI (Preview) helps developers build agent-driven application experiences using structured UI definitions and reusable Syncfusion components. Instead of generating a complete UI implementation for every request, the agent describes the interface while the application controls how it is rendered. Syncfusion A2UI Components provide the runtime experience across React, Angular, Blazor, and .NET MAUI, while A2UI Composer offers an optional visual path for designing and refining the interface definition first.

AI applications are moving beyond text-based responses. Instead of simply returning an answer, an AI agent may need to display data, visualize information, collect input, or help users complete a workflow.

This creates a challenge for developers. When AI generates a new UI implementation for every request, the resulting interfaces can require additional development and maintenance. Enterprise applications also need to work with the UI components and application experiences they already use.

This is where A2UI (Agent-to-UI) comes in. Instead of generating the complete UI implementation, an AI agent can return a structured description of the interface. The application can then interpret that definition and render it using supported UI components.

Syncfusion^® brings this model into application development through two focused capabilities: A2UI Components for rendering structured interfaces at runtime and A2UI Composer for optionally designing and refining those interfaces before they are connected to the application workflow.

In this blog, we’ll explore what A2UI is, why it matters for enterprise applications, and how Syncfusion A2UI helps developers build agent-driven user experiences.

The challenge of AI-generated user interfaces

In AI applications, responses are often delivered as text, but many tasks require users to view data, interact with controls, or complete workflows.

Generating a new UI implementation for every AI request can increase development and maintenance effort, especially when applications already have established components and experiences.

This creates a need for a more structured approach where AI can compose interfaces from reusable UI building blocks instead of generating a new implementation for every request.

What is A2UI?

A2UI allows an AI agent to describe a user interface through structured definitions instead of generating the complete UI implementation.

The agent determines what the user needs, and the application processes the A2UI definition and renders it using supported UI components.

For example, an agent responding to a sales request could describe an interface containing a Data Grid and Chart. The application can then map those definitions to the corresponding UI components.

A simplified A2UI flow is:

User request

↓

AI agent

↓

A2UI definition/messages

↓

A2UI runtime and renderer

↓

Supported UI components

↓

Interactive UI

This approach separates the agent’s description of the experience from how the application renders it, allowing interfaces to be composed from reusable building blocks.

Why A2UI matters for application development

Enterprise applications already have established UI components, workflows, and data sources. A2UI provides a way to bring these existing building blocks into agent-driven experiences.

Reuse supported UI components

Applications can use supported components as reusable building blocks instead of creating a new UI implementation for every AI interaction. For example, a Data Grid can display records, a Chart can visualize data, and a Scheduler can present appointments.

Create task-focused experiences

AI agents can compose interfaces based on the user’s current request instead of relying only on predefined screens.

Keep rendering within the application

The agent provides a structured UI definition, while the application processes it and renders the supported components within its existing environment.

Support application modernization

Organizations can add AI-driven experiences around existing application capabilities and UI components without treating every AI interaction as a completely new application screen.

Together, these capabilities allow applications to explore adaptive, agent-driven experiences while continuing to use existing UI building blocks.

Introducing Syncfusion A2UI Components

Syncfusion A2UI Components turn structured A2UI definitions into interactive UI inside an application. The runtime maps the incoming surface to supported components, handles updates, and processes of user interactions as the experience evolves.

Supported platforms

Syncfusion currently provides A2UI support for:

Support for additional platforms is planned.

Read the full blog post on the Syncfusion Website

What’s New in Syncfusion Essential Studio 2026 Volume 3: A2UI, New JavaScript Document Libraries, and More

Lucy Muturi — Tue, 29 Sep 2026 15:57:32 +0000

TL;DR: Essential Studio 2026 Volume 3 introduces new capabilities for AI-powered applications, JavaScript document processing, dynamic forms, and cross-platform development. Highlights include the .NET Document Chunking Library, A2UI, JavaScript Excel and PowerPoint Libraries, Form Builder and Form Renderer, new UI controls, and expanded document collaboration.

Essential Studio 2026 Volume 3 at a glance

The Essential Studio 2026 Volume 3 expands the Syncfusion toolkit across AI, document processing, forms, UI development, and collaboration. Here are the updates worth exploring.

Release highlights

JavaScript libraries for Excel and PowerPoint.
.NET Document Chunking Library for AI and retrieval workflows.
A2UI for dynamically generated user interfaces.
WebMCP integration for connecting Syncfusion components with AI assistants.
Form Builder and Form Renderer for dynamic forms.
AI-powered PDF experiences.
New UI controls across .NET MAUI, Pure React, Blazor, and WinUI.
Collaboration capabilities for documents and spreadsheets.

New AI and AI-ready capabilities

Volume 3 introduces new ways to prepare enterprise content for AI retrieval, generate interfaces dynamically, connect AI assistants with web components, and add intelligent PDF experiences.

Prepare enterprise content for RAG with document chunking

Building a retrieval-augmented generation (RAG) or semantic-search application often starts with preparing documents for retrieval.

The new .NET Document Chunking Library (Preview) transforms PDFs, Word documents, Excel workbooks, PowerPoint presentations, and Markdown files into context-aware chunks while preserving document structure and metadata.

Developers can preserve document hierarchy, control chunk size and overlap, and retain metadata and citations, providing structured content for RAG, semantic search, and knowledge-retrieval workflows.

Create dynamic interfaces with A2UI

AI applications often need more than text responses. They may need forms, charts, grids, or other interactive experiences based on a user’s request.

With A2UI (Preview) for Blazor, React, Angular, Vue, and .NET MAUI, AI agents can dynamically generate interactive user interfaces using Syncfusion components. A2UI components provide the building blocks for these interfaces, while the new A2UI Composer provides a visual way to design and refine them.

Agents describe the interface they need, while the application controls how it is rendered. This enables adaptive experiences such as AI-generated forms, grids, charts, and schedulers without requiring the agent to generate the complete UI implementation.

Connect components with AI Assistants using WebMCP

WebMCP enables AI assistants to interact with Syncfusion React, Angular, JavaScript, JavaScript (ES5), and Vue components through natural language, with component capabilities exposed as tools. Developers can control tool exposure through selection, custom prefixes, and access restrictions.

Build intelligent PDF experiences

The Smart .NET MAUI PDF Viewer adds AI-powered capabilities for applications that work extensively with PDF documents. It can extract document information, detect and populate form fields, redact sensitive content, and connect to custom AI services, helping automate common PDF workflows.

Create Excel and PowerPoint files with JavaScript

Essential Studio 2026 Volume 3 introduces JavaScript Excel and PowerPoint Libraries (Preview) for browser and Node.js applications. These libraries allow developers to create and process Office documents programmatically without requiring Microsoft Office installations.

JavaScript Excel Library : Create and edit workbooks with formulas, ranges, charts, tables, validation, protection, and programmatic formatting.
JavaScript PowerPoint Library : Generate presentations programmatically with layouts, master slides, charts, tables, images, shapes, sections, and speaker notes.

Together, these libraries extend JavaScript-based document workflows for creating and processing Excel and PowerPoint files.

Build dynamic forms with Form Builder and Form Renderer

The new Form Builder (Preview) provides a visual drag-and-drop experience for designing dynamic forms. It includes 20+ controls, conditional logic, dependent fields, calculated expressions, validation, and schema generation.

Form Builder

Once a form is designed, Form Renderer (Preview) renders responsive forms directly from JSON schemas.

Together, Form Builder handles visual form creation while Form Renderer turns the resulting schema into a responsive runtime form. They can support onboarding processes, approval processes, surveys, and other form-driven business applications.

New UI controls across platforms

Volume 3 expands the UI library across .NET MAUI, Pure React, Blazor, and WinUI.

.NET MAUI

Volume 3 introduces five .NET MAUI controls:

Diagram for flowcharts, process designers, visual editors, and organizational charts.

.NET MAUI Diagram

TreeGrid for hierarchical data in a grid interface.

.NET MAUI TreeGrid

Interactive Viewer for zooming, panning, and rotating content.

.NET MAUI InteractiveViewer

Grid Splitter for resizable application layouts.

.NET MAUI Grid Splitter

Data Pager for navigating large datasets.

.NET MAUI Data Pager

Pure React

Pure React gains new File Upload, Sidebar, and TreeView components for file processing, navigation, and hierarchical data, respectively.

Blazor Sunburst Chart

The new Blazor Sunburst Chart(Preview) visualizes multilevel hierarchical data through concentric rings, with drill-down, selection, highlighting, theming, and tooltip support.

Blazor Sunburst Chart

WinUI Docking Manager

The new WinUI Docking Manager (Preview) supports docked, floating, tabbed, and auto-hidden windows for building flexible desktop workspaces.

Key enhancements across existing components

Beyond the new controls and libraries, 2026 Volume 3 includes enhancements across existing web, Blazor, .NET MAUI, document, and desktop products.

Here are some notable updates.

Web components [React, Angular, Vue, JavaScript, ASP.NET Core, ASP.NET MVC]

Charts: Cartesian Charts add smart data labels to reduce overlaps, while Stock Charts improve live updates, navigation synchronization, and streaming behavior.
DataGrid: The DataGrid adds formula cells, advanced filtering, and automatic row numbering, extending spreadsheet-like interaction for business data.
Gantt Chart: The Gantt Chart gains flexible scheduling, drag-to-create tasks, dependency restrictions, synchronized numbering, and improved hierarchical selection.
TreeGrid: TreeGrid adds DOM virtualization for large hierarchical datasets along with enhanced parent-child selection modes.

DOM virtualization in TreeGrid

File Manager: File Manager adds more control over folder behavior during drag-and-drop operations.
Modern Rich Text Editor: The Modern Rich Text Editor delivers a modern, extensible WYSIWYG experience for structured content, with ProseMirror providing the underlying document model and editing engine.
Headless Editor: The Headless Editor is a framework-agnostic editing foundation built on ProseMirror for modern rich-text and structured editing. It provides a modular architecture with extensible commands, extensions, schemas, NodeViews, events, and reusable editing services.

Blazor components

Blazor updates span AI experiences, data interaction, project planning, and barcode support.

Inline AI Assist is now production-ready, enabling contextual AI-assisted interactions within Blazor applications.
Barcode Generator adds GS1 Linear, GS1 QR Code, GS1 DataMatrix, and DotCode support.
Gantt Chart adds task constraints, multiple event markers, weekend controls, configurable view dates, and MemoryStream export.
DataGrid adds Excel-style editing, undo and redo, find and highlight, event-driven data binding, and custom printing.

Read the full blog post on the Syncfusion Website

Migrating Reactive Forms to Angular 22 Signal Forms: When and How

Jollen Moyani — Thu, 24 Sep 2026 17:05:51 +0000

TL;DR: If you plan to migrate Reactive Forms to Angular 22 Signal Forms, evaluate each form individually rather than treating the entire application as one migration project. Signal Forms provide a stable, signal-based approach to form management, but migrating every Reactive Form is not necessary. This guide shows you how to evaluate existing forms using a migration scorecard, decision matrix, and compatibility APIs to decide whether to migrate, coexist, or continue using Reactive Forms.

Angular forms have evolved, but adopting a newer form API doesn’t automatically mean replacing the one you already use. Before migrating to Signal Forms, it’s important to consider whether the change will solve a real problem in your application.

For a simple profile form with just three inputs, moving from FormGroup to a signal-based model might be relatively easy. However, if the form is already working well, migrating may not provide enough value to justify the effort.

The situation can be different for a complex, multistep form with dynamic fields, custom controls, and RxJS-based logic. A signal-based approach may help address certain state-management challenges, but the form’s existing dependencies also make migration more involved.

This is where Angular 22 Signal Forms come into the picture. Now stable, Signal Forms provide a signal-based approach to managing form values, validation, interaction state, and submission.

They also offer compatibility APIs for working with existing Reactive Forms, making it possible to consider an incremental migration rather than rewriting an entire form at once.

The goal isn’t to migrate every Reactive Form. It’s to understand where Signal Forms can provide meaningful benefits and where continuing with Reactive Forms, or combining both approaches, is the more practical choice.

For enterprise Angular applications, this leads to an important question:

Should you migrate an existing Reactive Form to Signal Forms, and if so, what migration approach should you use?

This guide explores these decisions through a form-level migration scorecard, a scenario-based decision matrix, and three implementation paths. The aim is to determine which forms should migrate, use both approaches, or stay with Reactive Forms.

Understanding the complexity of Angular Forms Migration

Reactive Forms may sometimes require more code, but that alone is not a strong enough reason to replace them. In a mature application, a form is often closely connected to other parts of the system.

For example, a FormGroup may be used with:

Shared validator packages
RxJS pipelines and subscriptions
Internal component libraries
ControlValueAccessor implementations
State-management adapters
Analytics and autosave subscriptions
Automated testing utilities
Schema-driven form builders
Accessibility and error-summary components

A checkout or account-opening form is more than a collection of input fields. It often acts as a connection point between user input, validation, business logic, application state, and supporting services.

Because of these dependencies, migrating the form requires careful planning. Teams need to evaluate validator behavior, custom controls, submission payloads, status styling, test utilities, accessibility behavior, and services that consume AbstractControl or form observables.

Angular provides compatibility APIs to support different migration approaches. compatForm can integrate existing Reactive Forms controls into a Signal Forms model, while SignalFormControl allows signal-based controls to participate in an existing Reactive Forms hierarchy.

This makes gradual migration and coexistence possible in suitable scenarios. The key is to identify the right migration boundary and decide which parts of the form should change, which should remain as they are, and how both approaches can work together.

Signal Forms vs. Reactive Forms: What changes?

Migrating to Signal Forms is not simply a matter of replacing FormGroup with form(). The two approaches organize and expose form state differently.

Reactive Forms organize form state around a control tree, while Signal Forms use a signal-backed data model as the source of truth.

In Signal Forms, passing a signal-based model to form() creates a typed field tree that reflects the model’s structure. Field values, validation results, interaction state, and other metadata can then be accessed reactively.

The code snippets in this article focus on the APIs and migration patterns being discussed. Some standard Angular component metadata and supporting imports may be omitted for brevity. When using a snippet in an application, include the imports and component configuration required by the APIs used in that example.

Reactive Forms begin with a control tree

Here, the form begins with a FormGroup containing individual controls. Validators are attached to those controls, and the form’s value and status are accessed through the Reactive Forms API.

TypeScript

readonly profileForm = this.formBuilder.nonNullable.group({
    displayName: ['', Validators.required],
    email: ['', [Validators.required, Validators.email]],
});

Signal Forms begin with application data

TypeScript

import { signal } from '@angular/core';
import {
    email,
    form,
    required,
} from '@angular/forms/signals';

interface ProfileModel {
    displayName: string;
    email: string;
}

readonly profileModel = signal<ProfileModel>({
    displayName: '',
    email: '',
});

readonly profileForm = form(this.profileModel, (path) => {
    required(path.displayName, {
        message: 'Display name is required',
    });

    required(path.email, {
        message: 'Email is required',
    });

    email(path.email, {
        message: 'Enter a valid email address',
    });
});

In this example, the profile data is stored in a signal. The form() function creates a field tree from that model, and validation rules are defined against typed field paths.

The corresponding fields use formField:

TypeScript

<label>
    Display name
    <input [formField]="profileForm.displayName" />
</label>

<label>
    Email
    <input type="email" [formField]="profileForm.email" />
</label>

@if (
    profileForm.email().touched() &&
    profileForm.email().invalid()
) {
    @for (
        error of profileForm.email().errors();
        track error.kind
    ) {
        <p>{{ error.message }}</p>
    }
}

The important difference is not simply shorter syntax. It is where form state lives and how that state is derived, validated, and exposed to the template.

Concern	Reactive Forms	Angular 22 Signal Forms
Source of truth	`AbstractControl` tree	Writable signal model
Form structure	`FormGroup`, `FormControl`, and `FormArray`	Typed field tree derived from the model
Derived state	Properties, `valueChanges`, and `statusChanges`	Signals and `computed()`
Validation style	Validator functions attached to controls	Schema rules applied to typed field paths
Template binding	`formGroup` and `formControlName`	`formField`
Dynamic values	Control-tree mutation	Model and signal updates
Existing ecosystem	Broad and mature	Stable, but newer
Incremental adoption	Existing architecture	Supported through compatibility APIs

This is why a migration cannot be evaluated only by comparing lines of code. A Signal Forms migration changes how the feature owns, derives, validates, and exposes form state.

When Signal Forms make sense in real projects

The technical differences become more meaningful when applied to real application scenarios. A form that benefits from signal-based state management may not have the same requirements as a stable form built around existing Reactive Forms utilities.

Signal Forms can be a natural fit when a component already uses signals, and its UI behavior depends on derived state.

Consider a quote form where the available plans depend on the selected region:

TypeScript

readonly quoteModel = signal({
    region: '',
    planId: '',
    employeeCount: 1,
});

readonly quoteForm = form(this.quoteModel, (path) => {
    required(path.region);
    required(path.planId);
    min(path.employeeCount, 1);
});

readonly availablePlans = computed(() =>
    this.planCatalog().filter(
        (plan) => plan.region === this.quoteModel().region,
    ),
);

The available plans are derived from the selected region in the signal-backed model. There is no separate subscription whose primary purpose is to synchronize the selected region with the plan list.

This approach can be useful when a form has meaningful UI state derived from editable data. However, it may offer limited value when an existing Reactive Form is stable, has little synchronization complexity, and only requires occasional maintenance.

When Reactive Forms may remain the better fit

Reactive Forms remain practical when the surrounding architecture depends on:

Imperative control-tree manipulation
Internal utilities accepting AbstractControl
Existing FormArray builders
Complex RxJS pipelines driven by valueChanges
Third-party controls verified primarily with Reactive Forms
Test helpers built around FormGroup
Runtime attachment or removal of validators

Signal Forms use a more declarative approach to validation and state. Therefore, migrating a form that relies heavily on imperative control operations may require an architectural redesign rather than a direct API replacement.

For example, a form with an extensive rules engine that repeatedly adds validators, sets errors, or enables and disables controls may need more than a field-level migration.

Performance should not be the default justification for migration either. Signals provide fine-grained reactive state, but actual form performance also depends on validator cost, asynchronous requests, template rendering, custom controls, and application-level computations.

Migrate for a clearer state model or lower maintenance complexity. Treat performance improvement as a hypothesis to measure, not a guaranteed outcome.

Use the Form Migration Scorecard before changing code

Do not assess the entire application as one migration unit. Evaluate each form or bounded workflow independently.

The following scorecard is a planning framework created for this guide. It is not an official Angular assessment tool. Teams should adapt the factors and thresholds to their architecture, application risk, and migration goals.

The scores and ranges below are illustrative planning aids created for this article; they are not Angular-defined or empirically validated migration thresholds. Use them to structure an evaluation, not as the sole basis for deciding whether to migrate.

Assign 0, 1, or 2 points for each factor.

Factor	0 points	1 point	2 points
Existing stability	Mature and rarely changed	Periodically modified	Frequently changed or fragile
Signal alignment	`RxJS/control-centric` feature	Mixed state model	Already uses signals extensively
Derived-state synchronization burden	Little or none	Several manageable derived-state subscriptions	Repeated subscriptions used primarily to synchronize editable values with local UI state
Validation model	Imperative or specialized	Mixed	Mostly declarative and model-based
Custom controls	Many unverified dependencies	Some adaptable controls	Native inputs or verified compatible controls
Dynamic structure	Runtime control engine	Moderate arrays or conditional fields	Predictable model-shaped nesting
Shared dependencies	Many `AbstractControl` utilities	Some reusable dependencies	Mostly isolated
Test migration cost	High regression risk	Moderate	Focused and well-contained
Business change rate	Frozen or maintenance-only	Normal roadmap changes	Active redesign or feature expansion
Learning value	One-off legacy feature	Useful team pilot	Reusable pattern for other features

Interpreting the score

0-6: Lower migration priority Migration may offer limited maintenance value relative to the rewrite and regression effort. Consider retaining Reactive Forms unless another project-specific requirement justifies the change.
7-12: Consider selective coexistence Consider selective coexistence or a small pilot with a clear boundary.
13-16: Potential pilot candidate Evaluate whether the form is suitable for a controlled migration.
17-20: Higher-priority candidate for evaluation The score indicates stronger alignment with the factors in this framework, but review business criticality, regression risk, compatibility requirements, and rollback options before deciding to migrate.

A good pilot is not necessarily the smallest form. It should be a representative, low-risk workflow containing enough real behaviors, such as conditional fields, derived state, or asynchronous validation, to test the proposed architecture.

A compliance-critical form may remain on Reactive Forms despite a high score. Similarly, a low-risk internal tool may be a reasonable pilot even with a lower score because rollback is easier.

The score should support the migration discussion, not replace engineering judgment or application-specific testing.

Apply the decision matrix to common enterprise scenarios

The scorecard helps evaluate migration suitability. The following matrix translates common scenarios into potential directions.

These directions are planning suggestions for the scenarios described, not universal migration rules. Validate them against the form’s actual dependencies, business requirements, supported Angular versions, and regression risk.

Scenario	Potential direction	Practical reason
New Angular 22 signal-based feature	Consider Signal Forms	Aligns form state with the surrounding reactive model
Stable legacy CRUD form	Consider keeping Reactive Forms	Rewriting may offer little business or maintenance value
New leaf field inside a large existing `FormGroup`	Consider `SignalFormControl`	Adds Signal Forms behavior at a control-level boundary while retaining the existing parent form
Mostly new form with one legacy address group	Consider `compatForm`	Preserves a proven Reactive Forms subsection
Form with extensive imperative validator mutation	Evaluate whether to retain the existing approach or redesign the validation model first	A direct migration may require an architectural redesign
Dynamic form platform built around `FormArray`	Evaluate carefully	Shared engine dependencies may outweigh local benefits
Form with many synchronization subscriptions	Consider as a pilot candidate	Signals and `computed()` may simplify derived state
Compliance-critical form with stable controls	Evaluate conservatively	Existing stability, regression evidence, and application requirements may take priority
Form scheduled for major product redesign	Consider migration as part of the redesign	This can avoid making separate structural changes
Shared library supporting several Angular versions	Check the required Signal Forms APIs against every supported Angular version before adopting them	Cross-version compatibility may determine whether migration is practical

Many enterprise applications will intentionally use both approaches:

Signal Forms for new signal-oriented features where the model fits
Reactive Forms for stable existing use cases
Compatibility APIs at selected migration boundaries

Architectural consistency is valuable, but forced uniformity can cost more than maintaining two clearly documented patterns during a transition.

Three ways to migrate from Reactive Forms to Signal Forms

1. Build new Forms with Signal Forms

This is a suitable path when a new feature:

Already models component state with signals
Has limited dependence on legacy form utilities
Can establish fresh testing patterns
Does not need to fit an existing form engine

The main challenge is establishing consistent team conventions.

Before adopting Signal Forms across multiple features, agree on:

Form-model naming
Validation-message ownership
Error-summary behavior
Submission handling
Test-helper patterns
Custom-control contracts
Accessibility expectations

This approach works particularly well when the first implementation becomes a reviewed reference pattern for later features.

2. Migrate top-down with compatForm

A top-down migration can be useful when most of a form is moving toward Signal Forms, but one or more existing Reactive Forms controls must remain in place.

compatForm is designed to support existing Reactive Forms controls as part of a Signal Forms model. This can be useful for established asynchronous logic, complex RxJS workflows, third-party integrations, or reusable Reactive Forms sections.

A possible example is a checkout form where customer information moves to Signal Forms while an established address component remains based on Reactive Forms.

Pay close attention to model and payload construction. When Reactive Forms controls are included through a compatibility model, do not assume that the resulting application data will automatically match the API payload you expect.

Define an explicit mapping or projection for submission when necessary.

This approach works best when the remaining Reactive Forms section has a clear boundary. Scattering individual legacy controls throughout a Signal Forms model can create an architecture that is harder to understand than either approach on its own.

3. Migrate bottom-up with SignalFormControl

A bottom-up migration can be useful when the parent FormGroup must remain in place, but an individual field would benefit from Signal Forms validation or state behavior.

TypeScript

import { FormControl, FormGroup } from '@angular/forms';
import { required } from '@angular/forms/signals';
import {
    SignalFormControl,
} from '@angular/forms/signals/compat';

readonly emailControl = new SignalFormControl(
    '',
    (path) => {
        required(path, {
            message: 'Email is required',
        });
    },
);

readonly accountForm = new FormGroup({
    displayName: new FormControl('', {
        nonNullable: true,
    }),
    email: this.emailControl,
});

Bind the signal-based field through its field tree:

HTML

<form [formGroup]="accountForm">
    <input formControlName="displayName" />
    <input [formField]="emailControl.fieldTree" />
</form>

This approach can be useful when replacing the parent form would be too costly, but a specific field requires signal-based behavior.

SignalFormControl does not support every imperative operation available on a standard Reactive Forms control. Angular documents imperative enable() and disable() operations, validator-manipulation methods such as addValidators(), removeValidators(), and setValidators(), and methods such as setErrors() and markAsPending() as intentionally unsupported for SignalFormControl.

With Signal Forms, these behaviors should instead be expressed declaratively through form rules. If the existing implementation depends heavily on these imperative operations, migrating the individual control may require changes beyond the control itself.

Also follow Angular’s API guidance for binding migrated controls. Add the SignalFormControl to the existing FormGroup, but bind its input through .fieldTree rather than using formControlName or [formControl] for that signal-backed control.

A practical enterprise migration sequence

1. Inventory forms and dependencies

Create a form catalog containing:

Feature owner
Business criticality
Control count
Dynamic-field usage
Custom-control dependencies
Async validators
valueChanges and statusChanges usage
Shared validator dependencies
Automated test coverage
Planned product changes

Apply the migration scorecard to each bounded workflow. This prevents pilot selection from being driven only by developer preference.

2. Establish a behavioral baseline

For each pilot, record:

Submission payloads
Validation behavior
Touched and dirty-state behavior
Async request frequency
Accessibility results
Relevant runtime traces
Existing defect or maintenance hotspots

Without a baseline, claims such as “cleaner,” “faster,” and “easier to test” remain subjective.

3. Define the model and boundaries

Decide what belongs to the editable form model before changing the template.

Avoid placing service responses, request lifecycle state, UI-only flags, and submission payloads into one oversized signal. A clearer separation is:

Form model: Editable user data
Computed state: Derived display options
Resource state: Server-backed lookups
Submission state: Request lifecycle
Domain mapper: Conversion to and from API contracts

This prevents the form from becoming an application-wide state store.

4. Port validation by behavior

Do not translate validator functions only by matching API names.

Determine whether each rule is:

Field-level
Cross-field
Conditional
Asynchronous
Server-authoritative
Display-only
Dependent on external state

Then express that behavior through appropriate Signal Forms rules.

For asynchronous validation, control request frequency and stale responses carefully. Client-side validation improves feedback, but the backend must continue to enforce security-sensitive and business-critical rules.

5. Test state transitions and integration contracts

Prioritize behavior-focused tests:

Invalid input produces an accessible message.
Corrected input removes the error.
Async validation does not submit stale data.
Dynamic rows retain the expected values.
Disabled fields behave correctly.
Submission produces the expected domain payload.
If the existing form moves focus to an invalid field, verify that the same expected behavior is preserved after migration.
Server errors remain distinguishable from client validation errors.

Also verify status-based CSS and test selectors. Reactive Forms automatically apply status classes such as ng-valid, ng-invalid, ng-touched, and ng-dirty, but Signal Forms do not apply these classes by default.

If existing styles or tests depend on them, configure the NG_STATUS_CLASSES compatibility preset through provideSignalFormsConfig(), or define custom status-class mappings.

Complete the pilot only after comparing the new implementation against the baseline. A successful build is not enough; the migration should demonstrate reduced maintenance complexity, clearer state ownership, or another measurable benefit.

Frequently Asked Questions

Can Signal Forms be adopted in a shared component library that supports older Angular versions?

Only if the library’s supported Angular versions expose the required Signal Forms APIs.

If the library must continue supporting applications on earlier Angular releases, keep Signal Forms integration in an Angular 22-specific entry point or adapter rather than making it part of the library’s common public API. Verify peer-dependency ranges, build targets, and consumer compilation before publishing the change.

How should route guards detect unsaved changes after migrating to Signal Forms?

Keep route guards independent of the forms API. Expose a feature-level contract such as hasUnsavedChanges() and implement it by comparing the current editable model with its initial snapshot or by using domain-specific change tracking.

This prevents routing code from depending directly on either a FormGroup or a Signal Forms field tree.

How can a team roll back a Signal Forms pilot safely?

Keep API contracts, domain mapping, and business services outside the form component. Avoid changing the backend payload during the first migration, and place the pilot behind a clear component or feature boundary.

If the pilot must be reversed, the team can replace the form-state implementation without undoing unrelated domain or API changes.

How should reusable test helpers support both Signal Forms and Reactive Forms?

Create behavior-oriented helpers that interact with fields through labels, roles, control names, or component harnesses rather than reading FormGroup or field-tree internals.

Shared tests should verify visible errors, field values, focus behavior, submission results, and disabled states. API-specific helpers can remain in thin adapters where direct state inspection is unavoidable.

How should server validation errors be mapped to Signal Forms fields?

Convert the server response into a stable application-level error format before exposing errors to the form.

Map field-specific errors to the corresponding field path and retain form-level errors separately for failures that do not belong to one input. Avoid coupling the UI directly to a backend error payload because API response structures may change independently of the form.

Conclusion

A successful migration should do more than replace one forms API with another. Its value becomes clear during the next validation change, feature request, or production fix.

Running Signal Forms and Reactive Forms side by side is reasonable when the transition is intentional. Rewriting stable forms purely for consistency rarely justifies the cost and regression risk.

When deciding whether to migrate Reactive Forms to Signal Forms, evaluate each form independently rather than treating migration as an application-wide requirement. Consider its existing dependencies, state-management model, validation behavior, testing requirements, and expected maintenance benefits.

The real test of migrating a Reactive Form to Angular 22 Signal Forms is whether the resulting form becomes easier to understand, change, and maintain, not simply whether the rewrite works.