Grids - CustomLoadPipeline

[Tucchhaa]

No description provided.

[Copilot]

Pull request overview

This PR refactors grid data loading by extracting the “custom load” flow from DataSourceAdapter into a dedicated CustomLoadPipeline, and updates GridCore/TreeList call sites to use the new pipeline-backed APIs.

Changes:

• Introduced CustomLoadPipeline to encapsulate custom store-load option building, load execution (with timeout), and result customization.
• Refactored DataSourceAdapter to delegate load, loadFromStore, and new loadAll / processLoadedData helpers to the pipeline.
• Updated TreeList branch loading, virtual scrolling loading state logic, and added Jest coverage for the new pipeline behavior.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
packages/devextreme/js/__internal/grids/tree_list/data_source_adapter/m_data_source_adapter.ts	Uses the new loadFromStore(loadOptions) signature and avoids passing a custom store by loading fullData via ArrayStore.load.
packages/devextreme/js/__internal/grids/tree_list/data_source_adapter/m_data_source_adapter.test.ts	Updates the test stub to match the updated loadFromStore signature.
packages/devextreme/js/__internal/grids/grid_core/virtual_scrolling/m_virtual_scrolling.ts	Switches from direct _isLoadingAll access to the new isLoadingAll() API.
packages/devextreme/js/__internal/grids/grid_core/data_source_adapter/m_data_source_adapter.ts	Moves custom load responsibilities into CustomLoadPipeline; adds loadAll and processLoadedData as public helpers.
packages/devextreme/js/__internal/grids/grid_core/data_source_adapter/custom_load_pipeline.ts	New module implementing the extracted custom load pipeline.
packages/devextreme/js/__internal/grids/grid_core/data_source_adapter/tests/custom_load_pipeline.test.ts	New Jest suite covering the pipeline’s load behavior, totalCount handling, error reporting, and helper methods.
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_controller.ts	Refactors loadAll to rely on dataSource.loadAll() / dataSource.processLoadedData() instead of inlining customization logic.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (3)

Previously missed (1) — in code that hasn't changed since the last review.

packages/devextreme/js/__internal/grids/grid_core/data_source_adapter/custom_loader.ts:64

• Method name looks like a typo: schedulerLoadingCallbacks reads as if it relates to a scheduler rather than scheduling callbacks. Renaming to scheduleLoadingCallbacks would better match the existing naming (_scheduleLoadCallbacks) and the intent of the method.

This issue also appears on line 165 of the same file.

    this.schedulerLoadingCallbacks(d);

packages/devextreme/js/__internal/grids/grid_core/data_source_adapter/custom_loader.ts:12

• CustomLoadResult is used as the generic for DeferredObj<T>, but this loader resolves deferreds with heterogeneous arguments (data, extra). DeferredObj<T> types all resolve args as T (see core/utils/deferred.d.ts), so the union type here is misleading for .done((data, extra) => ...) call sites. Consider switching to resolving a single object { data, extra } (best), or make CustomLoadResult an untyped placeholder (e.g. any) until the API is refactored.

export type CustomLoadResult = RawItemData[] | LoadOperation['extra'];

packages/devextreme/js/__internal/grids/grid_core/data_source_adapter/custom_loader.ts:165

• Method name looks like a typo: schedulerLoadingCallbacks reads as if it relates to a scheduler rather than scheduling callbacks. Rename it to scheduleLoadingCallbacks to match intent and the call site.

  private schedulerLoadingCallbacks(deferred: DeferredObj<unknown>): void {

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Suppressed comments (1)

packages/devextreme/js/__internal/grids/grid_core/data_source_adapter/custom_loader.ts:12

• CustomLoadResult is used as the generic for DeferredObj<T>, but DeferredObj<T> requires all resolve arguments to be of the same type (resolve(...args: T[])). This loader resolves as (data, extra), where data is an array and extra is an object, so the current union type is misleading and can make .done((data, extra) => ...) callbacks fail type-checking at call sites (e.g., DataController). Until the pipeline resolves to a single object, use any here (or change the API to resolve a single combined result).

export type CustomLoadOptions = StoreLoadOptions & { isLoadingAll?: boolean };

export type CustomLoadResult = RawItemData[] | LoadOperation['extra'];

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

packages/devextreme/js/__internal/grids/grid_core/data_source_adapter/custom_loader.ts:12

• DeferredObj<T> assumes all resolve arguments share the same type T (see js/core/utils/deferred.d.ts: resolve(...args: T[])). CustomLoader.load()/loadAll()/processLoadedData() resolve as (data, extra), where data is an array and extra is an object, so CustomLoadResult = RawItemData[] | LoadOperation['extra'] is still misleading (it suggests either argument could be either shape, and it can hide typing errors at call sites). Prefer using unknown/any for the DeferredObj generic until the pipeline resolves a single object (e.g. { data, extra }).

export type CustomLoadOptions = StoreLoadOptions & { isLoadingAll?: boolean };

export type CustomLoadResult = RawItemData[] | LoadOperation['extra'];