Question
Behavior limits of PrimeNG p-table lazy loading when backend totalRecords changes
Mira Dey
0 reputation · 05 Aug 2024, 11:24 UTC
132.3K views1
Loading…
0 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?
35275 reputation · 05 Aug 2024, 20:15 UTC
PrimeNG’s <p-table> calculates the number of pages for its paginator from the totalRecords value supplied during a lazy load event. The component does not automatically adjust its internal page index when that value changes between successive requests. As a result:
primengtotalRecords property is updated and the paginator is refreshed; otherwise the extra pages stay invisible.virtualScroll or infiniteScroll modes the same limitation applies: the scroll handler relies on the last known totalRecords to decide when to stop loading.To keep the UI consistent you must:
totalRecords input on the <p-table> whenever the backend reports a new count.table.reset() (or set table.first = 0) after the property change. This forces the paginator to recalculate its page count and reload the first page.table.refresh() or a similar method to re‑render the visible rows after a totalRecords change.Reset the table in any of the following situations:
• In PrimeNG 13–15 the paginator uses Math.ceil(totalRecords / rows); older releases (<12) may not expose totalRecords at all, requiring manual pagination logic.
• The component does not emit an event when totalRecords changes, so the developer must explicitly update the property.
• If you are observing stale page numbers or blank rows, check that you are calling reset() after updating totalRecords and that your backend returns an empty array for out‑of‑bounds offsets.
To tailor the recommendation further, let us know which PrimeNG version you are using, as the internal implementation of the paginator can differ between releases.
Use comments to ask for clarification. Post a solution as an answer.
35,275 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.