d.ts: Function -> (() => void | string | any, etc) by mpreyskurantov · Pull Request #33163 · DevExpress/DevExtreme

mpreyskurantov · 2026-04-05T19:30:42Z

No description provided.

…e-all

Copilot

Pull request overview

This PR refines public TypeScript typings by replacing the overly-broad Function type with an explicit function signature for the keyExpr option across the core .d.ts files and the Angular/Vue wrappers.

Changes:

Updated CollectionWidgetOptions.keyExpr in core typings (dx.all.d.ts and ui.collection_widget.base.d.ts) from string | Function to a specific callback type.
Propagated the new keyExpr typing into Angular wrapper inputs/outputs for Tabs/List/Accordion.
Propagated the new keyExpr typing into Vue wrapper prop definitions for Tabs/List/Accordion.

Reviewed changes

Copilot reviewed 6 out of 8 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
packages/devextreme/ts/dx.all.d.ts	Updates `CollectionWidgetOptions.keyExpr` type in the aggregated TS declarations.
packages/devextreme/js/ui/collection/ui.collection_widget.base.d.ts	Updates the source `CollectionWidgetOptions.keyExpr` type used by many widgets.
packages/devextreme-vue/src/tabs.ts	Updates Vue Tabs `keyExpr` prop type to match new declarations.
packages/devextreme-vue/src/list.ts	Updates Vue List `keyExpr` prop type to match new declarations.
packages/devextreme-vue/src/accordion.ts	Updates Vue Accordion `keyExpr` prop type to match new declarations.
packages/devextreme-angular/src/ui/tabs/index.ts	Updates Angular Tabs `@Input()`/`@Output()` typings for `keyExpr`.
packages/devextreme-angular/src/ui/list/index.ts	Updates Angular List `@Input()`/`@Output()` typings for `keyExpr`.
packages/devextreme-angular/src/ui/accordion/index.ts	Updates Angular Accordion `@Input()`/`@Output()` typings for `keyExpr`.

Copilot · 2026-04-05T19:35:53Z

packages/devextreme-angular/src/ui/tabs/index.ts

    @Input()
-    get keyExpr(): Function | string {
+    get keyExpr(): (() => string) | string {
        return this._getOption('keyExpr');
    }
-    set keyExpr(value: Function | string) {
+    set keyExpr(value: (() => string) | string) {
        this._setOption('keyExpr', value);


keyExpr is typed as (() => string) | string, but for collection widgets this callback is used as a key getter and is invoked with the item data. This typing breaks common Angular usage like (item) => item.id and also forces the key to string.

Suggested fix: type it as ((item: TItem) => TKey) | string (and update the corresponding setter type to match).

Copilot · 2026-04-05T19:35:54Z

packages/devextreme-angular/src/ui/tabs/index.ts


     */
-    @Output() keyExprChange: EventEmitter<Function | string>;
+    @Output() keyExprChange: EventEmitter<(() => string) | string>;


keyExprChange is now EventEmitter<(() => string) | string>, but it should stay aligned with the keyExpr option type (a key getter invoked with item data and returning the key type). Otherwise the wrapper exposes an incorrect/breaking type.

Suggested fix: update to EventEmitter<((item: TItem) => TKey) | string> (or whatever final keyExpr type is chosen).

Suggested change

@Output() keyExprChange: EventEmitter<(() => string) | string>;

@Output() keyExprChange: EventEmitter<((item: any) => any) | string>;

Copilot · 2026-04-05T19:35:54Z

packages/devextreme-angular/src/ui/list/index.ts

    @Input()
-    get keyExpr(): Function | string {
+    get keyExpr(): (() => string) | string {
        return this._getOption('keyExpr');
    }
-    set keyExpr(value: Function | string) {
+    set keyExpr(value: (() => string) | string) {
        this._setOption('keyExpr', value);


keyExpr is typed as (() => string) | string, but this option is used as a key getter and is invoked with the item data. This typing breaks standard usage like (item) => item.id and also narrows keys to string.

Suggested fix: use ((item: TItem) => TKey) | string for both getter and setter.

Copilot · 2026-04-05T19:35:54Z

packages/devextreme-angular/src/ui/list/index.ts


     */
-    @Output() keyExprChange: EventEmitter<Function | string>;
+    @Output() keyExprChange: EventEmitter<(() => string) | string>;


keyExprChange is now EventEmitter<(() => string) | string>, which does not match how keyExpr is used (key getter invoked with item data). This is a breaking/inaccurate type for consumers.

Suggested fix: align it with the corrected keyExpr type, e.g. EventEmitter<((item: TItem) => TKey) | string>.

Suggested change

@Output() keyExprChange: EventEmitter<(() => string) | string>;

@Output() keyExprChange: EventEmitter<((item: any) => any) | string>;

Copilot · 2026-04-05T19:35:54Z

packages/devextreme-angular/src/ui/accordion/index.ts

    @Input()
-    get keyExpr(): Function | string {
+    get keyExpr(): (() => string) | string {
        return this._getOption('keyExpr');
    }
-    set keyExpr(value: Function | string) {
+    set keyExpr(value: (() => string) | string) {
        this._setOption('keyExpr', value);


keyExpr is typed as (() => string) | string, but in collection widgets this callback is treated as a key getter and invoked with item data. The zero-arg signature and forced string return type are both incompatible with common usage.

Suggested fix: type it as ((item: TItem) => TKey) | string for both getter and setter.

Copilot · 2026-04-05T19:35:55Z

packages/devextreme-angular/src/ui/accordion/index.ts


     */
-    @Output() keyExprChange: EventEmitter<Function | string>;
+    @Output() keyExprChange: EventEmitter<(() => string) | string>;


keyExprChange is now EventEmitter<(() => string) | string>, which doesn’t reflect actual keyExpr semantics (function should accept item data and return the key type). This will surface an incorrect public API in the Angular wrapper.

Suggested fix: align to EventEmitter<((item: TItem) => TKey) | string> (or whatever the final keyExpr type is).

Suggested change

@Output() keyExprChange: EventEmitter<(() => string) | string>;

@Output() keyExprChange: EventEmitter<((item: any) => string) | string>;

Copilot · 2026-04-05T19:35:55Z

packages/devextreme-vue/src/tabs.ts

    items: Array as PropType<Array<any | dxTabsItem | string>>,
    itemTemplate: {},
-    keyExpr: [Function, String] as PropType<((() => void)) | string>,
+    keyExpr: [Function, String] as PropType<((() => string)) | string>,


keyExpr is typed as (() => string) | string, but this option is used as a key getter and is invoked with the item data. The zero-argument function type is incorrect and will reject common usage like (item) => item.id.

Suggested fix: use a signature that accepts item data, e.g. ((item: any) => any) | string (or reuse the exact Properties["keyExpr"] type if available).

Suggested change

keyExpr: [Function, String] as PropType<((() => string)) | string>,

keyExpr: [Function, String] as PropType<Properties["keyExpr"]>,

Copilot · 2026-04-05T19:35:55Z

packages/devextreme-vue/src/list.ts

    items: Array as PropType<Array<any | dxListItem | string>>,
    itemTemplate: {},
-    keyExpr: [Function, String] as PropType<((() => void)) | string>,
+    keyExpr: [Function, String] as PropType<((() => string)) | string>,


keyExpr is typed as (() => string) | string, but it is used as a key getter called with the item data. The zero-arg callback type is incompatible with typical usage (item) => item.id.

Suggested fix: change to ((item: any) => any) | string (or use the component Properties["keyExpr"] type) to match runtime behavior.

Suggested change

keyExpr: [Function, String] as PropType<((() => string)) | string>,

keyExpr: [Function, String] as PropType<Properties["keyExpr"]>,

Copilot · 2026-04-05T19:35:55Z

packages/devextreme-vue/src/accordion.ts

    itemTemplate: {},
    itemTitleTemplate: {},
-    keyExpr: [Function, String] as PropType<((() => void)) | string>,
+    keyExpr: [Function, String] as PropType<((() => string)) | string>,


keyExpr is typed as (() => string) | string, but this option is treated as a key getter invoked with item data. A zero-argument function type will incorrectly reject standard patterns like (item) => item.id.

Suggested fix: type as ((item: any) => any) | string (or reuse the widget Properties["keyExpr"] type) to reflect actual usage.

Suggested change

keyExpr: [Function, String] as PropType<((() => string)) | string>,

keyExpr: [Function, String] as PropType<Properties["keyExpr"]>,

ui.collection_widget.base.d.ts: Function -> (() => string); regenerat…

9440665

…e-all

mpreyskurantov self-assigned this Apr 5, 2026

Copilot AI review requested due to automatic review settings April 5, 2026 19:30

mpreyskurantov requested a review from a team as a code owner April 5, 2026 19:30

mpreyskurantov added WIP Work in progress 26_1 labels Apr 5, 2026

github-actions bot added the .d.ts label Apr 5, 2026

Copilot started reviewing on behalf of mpreyskurantov April 5, 2026 19:31 View session

Copilot AI reviewed Apr 5, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

d.ts: Function -> (() => void | string | any, etc)#33163

d.ts: Function -> (() => void | string | any, etc)#33163
mpreyskurantov wants to merge 1 commit intoDevExpress:26_1from
mpreyskurantov:26_1-dts-function-dev

mpreyskurantov commented Apr 5, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Copilot AI Apr 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	@Output() keyExprChange: EventEmitter<(() => string) \| string>;
	@Output() keyExprChange: EventEmitter<((item: any) => any) \| string>;

	keyExpr: [Function, String] as PropType<((() => string)) \| string>,
	keyExpr: [Function, String] as PropType<Properties["keyExpr"]>,

Conversation

mpreyskurantov commented Apr 5, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 5, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants