PrimeNG Table Lazy Loading with Server-Side Pagination State Synchronization

Answer

For server‑side pagination with PrimeNG’s p-table you should bind [first] and [rows] as one‑way inputs. The table will update these values internally when the paginator changes, and you must manually reset first (to 0) and trigger a reload when the backend rejects an out‑of‑range offset or when filters/sorts change.

Confirmed facts (from research)

• One‑way binding ([first] and [rows]) prevents duplicate updates and stale state; two‑way binding ([(first)]/[(rows)]) can cause the paginator to overwrite values set by your code.
• If onLazyLoad receives a first value ≥ totalRecords, PrimeNG does **not** auto‑correct the offset; the table retains the invalid first until the application resets it and triggers a new load.
• There is no built‑in “silent reset” that skips a server call after a filter/sort change. The recommended pattern is to set first = 0 (and optionally adjust rows), then invoke the table’s load mechanism (table.load() or emit a new LazyLoadEvent) to fetch the first page.

Likely explanation

• Two‑way bindings create a feedback loop: the paginator writes to the bound property, your handler may write back, causing the onLazyLoad event to fire twice or with stale values.
• PrimeNG’s internal paginator only updates the UI; it does not validate the offset against the backend’s total count, so an out‑of‑range first leaves the table showing an empty page or disabled navigation until you correct it.
• After a filter or sort the table’s internal data source is considered stale, so a fresh server request is required unless you have cached data and explicitly guard against the request.

Steps to implement

1. Bind pagination as one‑way inputs:

   <p-table [value]="data" [lazy]="true" [first]="first" [rows]="rows"
            (onLazyLoad)="loadData($event)" [totalRecords]="total">
       ...
   </p-table>

2. In the handler, use the received first and rows to call your service. If the service returns an error indicating the offset is out of range, set first = 0 and call loadData({ first: 0, rows: this.rows }) (or table.load()) to recover.
3. When a filter, sort, or any other criterion changes:

   this.first = 0;
   // optional: adjust rows if page size changed
   this.table.load(); // or emit a new LazyLoadEvent

4. To avoid an unnecessary server call when you already have the filtered data cached, introduce a guard flag:

   private skipLazy = false;
   loadData(event: LazyLoadEvent) {
     if (this.skipLazy) {
       this.skipLazy = false;
       return;
     }
     // normal server request
   }
   // after filter/sort when data is cached
   this.skipLazy = true;
   this.first = 0;
   this.table.load();

5. Always update [totalRecords] with the backend’s total count after each successful response; this keeps the paginator’s page‑count and navigation buttons correct.

Missing diagnostic detail

Are you updating the [totalRecords] binding after every server response? If not, the paginator may show wrong page numbers or disable navigation even when the offset is correct.