Now
When using LazyDataSource with async back-end requests, there is no clear built-in guarantee of strict last-request-wins behavior for overlapping calls.
In practice, when request A is started and then request B is triggered (e.g. due to filter/search/sort/page changes), request A may still resolve/reject later and require app-level guarding to avoid stale side effects.
Because of this, each consumer may need to implement its own race-condition handling (request ids, abort logic, stale-result filtering, stale-error suppression) inside useLazyDataSource api callbacks.
This leads to:
- repeated boilerplate in many screens/components;
- inconsistent behavior between apps/pages;
- risk of stale errors/results affecting UI flow if local guards are missed.
To Do
Add built-in support in LazyDataSource for concurrent request handling with last-request-wins semantics.
Desired behavior:
- if request B starts after request A for the same data source/view state flow, request A becomes stale;
- stale request results should not update visible data state;
- stale request errors should not be propagated as active load errors;
- optionally use/carry
AbortSignal so stale in-flight requests can be cancelled where transport supports it.
A possible API direction:
- configurable strategy (default backward-compatible), e.g.
requestConcurrency: 'allow-all' | 'last-request-wins'
- or a dedicated flag, e.g.
ignoreStaleResponses: true (and matching stale error behavior).
Describe the solution you'd like (optional)
I’d like LazyDataSource to provide this behavior centrally, so app code can keep api implementations straightforward and focused on data mapping only.
Even a minimal first step would help:
- mark outdated requests internally;
- ignore outdated responses/errors when a newer request is active;
- document exact concurrency semantics in
LazyDataSource docs.
This would remove a common source of duplicated race-handling logic and make DataTable/LazyDataSource behavior more predictable across projects.
Now
When using
LazyDataSourcewith async back-end requests, there is no clear built-in guarantee of strict last-request-wins behavior for overlapping calls.In practice, when request A is started and then request B is triggered (e.g. due to filter/search/sort/page changes), request A may still resolve/reject later and require app-level guarding to avoid stale side effects.
Because of this, each consumer may need to implement its own race-condition handling (request ids, abort logic, stale-result filtering, stale-error suppression) inside
useLazyDataSourceapi callbacks.This leads to:
To Do
Add built-in support in
LazyDataSourcefor concurrent request handling with last-request-wins semantics.Desired behavior:
AbortSignalso stale in-flight requests can be cancelled where transport supports it.A possible API direction:
requestConcurrency: 'allow-all' | 'last-request-wins'ignoreStaleResponses: true(and matching stale error behavior).Describe the solution you'd like (optional)
I’d like
LazyDataSourceto provide this behavior centrally, so app code can keepapiimplementations straightforward and focused on data mapping only.Even a minimal first step would help:
LazyDataSourcedocs.This would remove a common source of duplicated race-handling logic and make DataTable/LazyDataSource behavior more predictable across projects.