Skip to content

GridCore - DataHelperMixin - fix eslint & typescript errors - #34656

Merged
Tucchhaa merged 3 commits into
DevExpress:mainfrom
Tucchhaa:task1_26_2
Aug 5, 2026
Merged

GridCore - DataHelperMixin - fix eslint & typescript errors#34656
Tucchhaa merged 3 commits into
DevExpress:mainfrom
Tucchhaa:task1_26_2

Conversation

@Tucchhaa

@Tucchhaa Tucchhaa commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@Tucchhaa Tucchhaa self-assigned this Aug 5, 2026
Copilot AI review requested due to automatic review settings August 5, 2026 08:48
@Tucchhaa Tucchhaa added the 26_2 label Aug 5, 2026
@Tucchhaa
Tucchhaa requested a review from a team as a code owner August 5, 2026 08:48
Comment on lines -160 to -171
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();
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these methods were never used

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 DataSourceType constructor 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 checked DATA_SOURCE_LOADING_CHANGED_METHOD in this earlier. 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;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From code looks like we can type it

Suggested change
public _dataSource?: unknown;
public _dataSource?: DataSource;

or

Suggested change
public _dataSource?: unknown;
public _dataSource?: typeof DataSource;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove this skip

const dataSource = this._dataSource;
this._proxiedDataSourceChangedHandler = function (e) {
this._proxiedDataSourceChangedHandler = function dataSourceChangedHandler(e): void {
// @ts-expect-error _dataSource is loosely typed

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// @ts-expect-error _dataSource is loosely typed
// @ts-expect-error dynamic mixin method

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TS error is shown for dataSource var, because its type is unknown


protected getDataSource() {
return this._dataSource || null;
protected getDataSource(): unknown {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
protected getDataSource(): unknown {
protected getDataSource(): DataSource | null {

Copilot AI review requested due to automatic review settings August 5, 2026 12:46

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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-error can 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-error will cause a TypeScript error if the dynamic call isn’t actually producing a compiler error. A runtime typeof === 'function' check avoids depending on an expected compiler failure and keeps the code resilient to tsconfig changes.
      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-error here 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](),
        });

Copilot AI review requested due to automatic review settings August 5, 2026 13:10

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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-error will fail the build if the next line does not actually produce a TypeScript error (TS2578). With noImplicitAny: false in js/__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 the this binding).
    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-error will break the build if it’s unused (TS2578). Given noImplicitAny: false in js/__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-error is likely unused here (TS2578) because noImplicitAny is disabled in js/__internal/tsconfig.json. Replace it with an explicit cast and call to avoid depending on an expected compiler error and to preserve the this binding.
        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-error will cause TS2578 if it doesn’t actually suppress an error; with noImplicitAny: false this 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);
      }

@Tucchhaa
Tucchhaa added this pull request to the merge queue Aug 5, 2026
Merged via the queue into DevExpress:main with commit 3b35e9f Aug 5, 2026
103 of 104 checks passed
@Tucchhaa
Tucchhaa deleted the task1_26_2 branch August 5, 2026 14:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants