GridCore - DataHelperMixin - fix eslint & typescript errors - #34656
Conversation
| private _loadSingle(key, value) { | ||
| key = key === 'this' ? this._dataSource.key() || 'this' : key; | ||
| return this._dataSource.loadSingle(key, value); | ||
| } | ||
|
|
||
| private _isLastPage() { | ||
| return !this._dataSource || this._dataSource.isLastPage() || !this._dataSource._pageSize; | ||
| } | ||
|
|
||
| private _isDataSourceLoading() { | ||
| return this._dataSource && this._dataSource.isLoading(); | ||
| } |
There was a problem hiding this comment.
these methods were never used
There was a problem hiding this comment.
Pull request overview
This PR updates the GridCore DataHelperMixin to eliminate blanket ESLint disables and address TypeScript typing issues by introducing explicit return types, safer member typings, and targeted @ts-expect-error suppressions for dynamic mixin hooks.
Changes:
- Replaced broad ESLint rule disables with explicit typings (
unknown, optional fields) and explicit method return types. - Refactored data source initialization to use a typed
DataSourceTypeconstructor path. - Simplified handler wiring (e.g., ready watcher via arrow function) and removed unused helper methods.
Suppressed comments (1)
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_helper_mixin.ts:152
this[DATA_SOURCE_LOADING_CHANGED_METHOD]is accessed dynamically without a cast or@ts-expect-error, which can still produce TypeScript indexing errors even though the caller checkedDATA_SOURCE_LOADING_CHANGED_METHOD in thisearlier. Align this with the other dynamic mixin calls in the file so the TS error is explicitly handled.
private _addDataSourceLoadingChangedHandler(): void {
this._proxiedDataSourceLoadingChangedHandler = this[DATA_SOURCE_LOADING_CHANGED_METHOD]
.bind(this);
// @ts-expect-error _dataSource is loosely typed
| public _dataSource: any; | ||
| // eslint-disable-next-line | ||
| export const DataHelperMixin = <T extends ModuleType<Controller>>(Base: T) => class extends Base { | ||
| public _dataSource?: unknown; |
There was a problem hiding this comment.
From code looks like we can type it
| public _dataSource?: unknown; | |
| public _dataSource?: DataSource; |
or
| public _dataSource?: unknown; | |
| public _dataSource?: typeof DataSource; |
There was a problem hiding this comment.
_dataSource has a complicated type:
In DataHelperMixin it's created as a DataSource: #34656
But DataController (that extends DataHelperMixin), reassigns _dataSource to a DataSourceAdapter type: _initDataSource -> setDataSource
So the runtime type of _dataSource changes over time, I think to implement that, we need to do some refactoring
| // TODO Get rid of this mixin | ||
| export const DataHelperMixin = <T extends ModuleType<Controller>>(Base: T) => class DataHelperMixin extends Base { | ||
| public _dataSource: any; | ||
| // eslint-disable-next-line |
| const dataSource = this._dataSource; | ||
| this._proxiedDataSourceChangedHandler = function (e) { | ||
| this._proxiedDataSourceChangedHandler = function dataSourceChangedHandler(e): void { | ||
| // @ts-expect-error _dataSource is loosely typed |
There was a problem hiding this comment.
| // @ts-expect-error _dataSource is loosely typed | |
| // @ts-expect-error dynamic mixin method |
There was a problem hiding this comment.
TS error is shown for dataSource var, because its type is unknown
|
|
||
| protected getDataSource() { | ||
| return this._dataSource || null; | ||
| protected getDataSource(): unknown { |
There was a problem hiding this comment.
| protected getDataSource(): unknown { | |
| protected getDataSource(): DataSource | null { |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
Suppressed comments (3)
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_helper_mixin.ts:73
- Same issue as above:
@ts-expect-errorcan break the TS build if it’s not masking a real compiler error. Use a runtime function check for dynamic mixin hooks instead of an expect-error directive.
const widgetDataSourceOptions = DATA_SOURCE_OPTIONS_METHOD in this
// @ts-expect-error dynamic mixin method
? this[DATA_SOURCE_OPTIONS_METHOD]()
: {};
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_helper_mixin.ts:93
@ts-expect-errorwill cause a TypeScript error if the dynamic call isn’t actually producing a compiler error. A runtimetypeof === 'function'check avoids depending on an expected compiler failure and keeps the code resilient totsconfigchanges.
if (NORMALIZE_DATA_SOURCE in this) {
// @ts-expect-error dynamic mixin method
this._dataSource = this[NORMALIZE_DATA_SOURCE](this._dataSource);
}
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_helper_mixin.ts:83
@ts-expect-errorhere is also risky for the same reason (unused expect-error breaks the TS build). Consider extracting the optional hook into a local variable and checking it’s a function before calling.
dataSourceOptions = normalizeDataSourceOptions(dataSourceOptions, {
fromUrlLoadMode: (DATA_SOURCE_FROM_URL_LOAD_MODE_METHOD in this)
// @ts-expect-error dynamic mixin method
&& this[DATA_SOURCE_FROM_URL_LOAD_MODE_METHOD](),
});
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (4)
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_helper_mixin.ts:61
@ts-expect-errorwill fail the build if the next line does not actually produce a TypeScript error (TS2578). WithnoImplicitAny: falseinjs/__internal/tsconfig.json, this dynamic index access is unlikely to error, so the directive is risky here. Prefer a typed/cast call without@ts-expect-error(and keep thethisbinding).
let dataSourceOptions = SPECIFIC_DATA_SOURCE_OPTION in this
// @ts-expect-error dynamic mixin method
? this[SPECIFIC_DATA_SOURCE_OPTION]()
: this.option('dataSource');
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_helper_mixin.ts:83
- This
@ts-expect-errorwill break the build if it’s unused (TS2578). GivennoImplicitAny: falseinjs/__internal/tsconfig.json, the dynamic index access often won’t error, making the directive unsafe. Prefer a casted function reference and call without@ts-expect-error.
dataSourceOptions = normalizeDataSourceOptions(dataSourceOptions, {
fromUrlLoadMode: (DATA_SOURCE_FROM_URL_LOAD_MODE_METHOD in this)
// @ts-expect-error dynamic mixin method
&& this[DATA_SOURCE_FROM_URL_LOAD_MODE_METHOD](),
});
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_helper_mixin.ts:73
@ts-expect-erroris likely unused here (TS2578) becausenoImplicitAnyis disabled injs/__internal/tsconfig.json. Replace it with an explicit cast and call to avoid depending on an expected compiler error and to preserve thethisbinding.
const widgetDataSourceOptions = DATA_SOURCE_OPTIONS_METHOD in this
// @ts-expect-error dynamic mixin method
? this[DATA_SOURCE_OPTIONS_METHOD]()
: {};
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_helper_mixin.ts:93
@ts-expect-errorwill cause TS2578 if it doesn’t actually suppress an error; withnoImplicitAny: falsethis is likely to become unused. Use an explicit cast to a callable and invoke via.call(this, …)instead of relying on an expected compiler error.
if (NORMALIZE_DATA_SOURCE in this) {
// @ts-expect-error dynamic mixin method
this._dataSource = this[NORMALIZE_DATA_SOURCE](this._dataSource);
}
No description provided.