Сhanges and Future Plans: New Angular Configuration Components

If you've worked with the DevExtreme Angular components in the past, you likely encountered configuration components — those with dxo-
and dxi-
prefixes. These helper components simplify widget setup, align with Angular architectural principles, and enhance readability. They are especially useful for nested options — for example, configuring paging options for dx-data-grid
using the dxo-pager
component.
<dx-data-grid [dataSource]="dataSource">
<dxo-pager
[visible]="true"
[showPageSizeSelector]="true" >
</dxo-pager>
</ dx-data-grid>
They are also useful for setting up collection elements, such as defining toolbar items in dx-toolbar
using its child components like dxi-item
.
<dx-toolbar>
<dxi-item location="before" widget="dxButton" >
</dxi-item>
</dx-toolbar>
Let's take a closer look at how the legacy Angular configuration components work, focusing on dxi-item
as an example. This component is "universal". It is used not just within dx-toolbar
, but also in many other DevExtreme components (such as Form and List).
While this approach offers consistency (the same component can be used in multiple places), it does have drawbacks. dxi-item
requires entirely different sets of options depending on the parent component, complicating precise typing.
The following screenshot illustrates how an IDE presents the same general property list for dxi-item
in two different contexts. For instance, the expected properties for a form’s group item differs significantly from those used in a Gantt chart’s context menu item.

One of our main priorities is delivering full and robust TypeScript support. We're committed to ensuring that all DevExtreme components are strictly typed and follow modern TypeScript practices. This approach improves code completion in IDEs, allows early error detection, and increases confidence during refactoring.
As you might expect, enforcing strict typing in configuration components has proven to be a complex challenge. Adjusting typings for existing dxo-
and dxi-
components can affect many projects, potentially requiring significant changes after an upgrade to a new version of DevExtreme. Furthermore, the generic nature of our current configuration architecture makes it difficult to achieve the desired level of type precision.
New Configuration Components: What's Changed and Why It Matters
With DevExtreme v24.2, we introduced a new set of configuration components (built from the ground up). New components are strictly typed, can be seamlessly integrated into Angular applications, and were designed to improve the overall developer experience.
Each UI component ships with its own dedicated set of configuration components. This marks a major step forward in predictability and type safety. Here's what's changed and how it benefits you:
Clearer and More Context-Aware Configuration Components
Configuration component names now include their parent component's name. This improves code readability, prevents naming collisions, and makes templates more self-explanatory.
For example, dxi-item
is now:
dxi-toolbar-item
indx-toolbar
dxi-form-item
indx-form
dxi-context-menu-item
indx-context-menu
This naming convention helps IDEs recognize component context and gives developers a clearer view of the structure, making complex configurations easier to navigate and maintain.
Strict Typing and a Better Developer Experience
New configuration components now include only the properties that are relevant to their specific parent component. This eliminates instances wherein the IDE suggests a long, generic list of unrelated options. For example, dxi-data-grid-column
reveals only properties applicable to DataGrid columns. As a result, IDE suggestions are now far more accurate and useful:

Most new configuration properties are strictly typed, and others will be typed in the future. This means that any misuse of a component's API will be caught during compilation (long before it can cause issues at runtime).

What's Next: Full adoption of the new configuration components
New configuration components have significant advantages over the old architecture: they are robust, modern, error-resistant, and better aligned with TypeScript's type system. We are planning a phased transition of our entire DevExtreme Angular ecosystem to this new configuration model. To ensure a smooth and predictable migration for users, please consider the following timeline/key milestones:
DevExtreme v25.1 Release
- We will start updating all demo examples and help topics to use our new model.
- We officially recommend that all new Angular applications adopt our new configuration model from the start.
- All features introduced in the v25.1 release require new configuration components.
DevExtreme v25.2 Release
- Using legacy configuration components will trigger deprecation warnings, indicating that these components are obsolete.
- The legacy configuration system will no longer be updated with new features. As a result, any new functionality introduced in 25.2 and future releases will require the use of new configuration components.
- We will provide documentation, migration guidelines, and helper tools to make the transition to our new architecture as smooth as possible.
DevExtreme v26.1 Release
We will continue to support those users migrating to our new configuration components. Our goal is to ensure that everyone has the resources and guidance needed to complete the transition smoothly.
DevExtreme v26.2 Release
All legacy configuration components will be removed from our codebase.
Again, our goal is to make the transition as clear, manageable, and secure as possible. We will provide plenty of time, tools, and guidance to support this change.
We believe that strict typing is not just a trend — it's essential for scalable, predictable, and safe development. As always, we welcome your thoughts, comments, and suggestions: