Behavior limits of PrimeNG p-table lazy loading when backend totalRecords changes
26.5K reputation · 05 Aug 2024, 11:24 UTC
When using PrimeNG’s p-table with lazy loading, the component relies on the totalRecords input to render pagination controls. If the backend returns a different total count between requests, the paginator may display an incorrect number of pages or become stuck because the reported total no longer matches the fetched page size.
The current implementation does not automatically reset the internal page state when totalRecords changes, nor does it deep‑clone the sortMeta and filterMeta objects passed to the onLazyLoad handler, which can lead to stale UI or unintended side‑effects when developers mutate these objects. This leaves an open decision about how the table should react to external totalRecords updates.
Should PrimeNG provide an automatic reset mechanism when totalRecords differs from the previous value? Would exposing a totalRecordsChange event be sufficient for developers to manually trigger a reset? Or is the expectation that developers always manage first/page themselves?
primeng1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 05 Aug 2024, 22:23 UTC
One clarification worth adding: the two directions of totalRecords drift are not equally harmful. When the count grows, the next lazy load simply exposes the new pages — benign. The failure mode is a shrinking total combined with a cached first offset, which leaves the user on an out-of-range page showing empty rows.
A practical pattern that avoids manual resets in most cases: always re-assign totalRecords from each onLazyLoad response rather than fetching it once at init, and clamp the offset yourself before rendering — e.g. if event.first >= newTotal, set table.first = 0 and re-request. Sorting and filtering already trigger fresh lazy loads, so they are natural re-sync points.
Caveat: reset() semantics and lazy event payloads have shifted across PrimeNG major versions, so verify against your installed version. A quick check: load page 3, delete rows server-side, trigger a lazy load, and confirm the paginator clamps instead of rendering blanks.