PrimeNG p-table lazy loading versus virtual scroller under concurrent sort and filter

Goal

Minimize UI latency when a user triggers rapid successive sort and filter actions on a large PrimeNG p-table dataset.

Constraint

Lazy loading sends a server request for every interaction and PrimeNG does not automatically cancel in-flight requests, so overlapping responses can race and overwrite newer data unless the application sequences them. Virtual scrolling keeps data local and renders only visible rows, but rapid concurrent sort or scroll events on a large local dataset can block the main thread. The trade-off is network round-trips per interaction versus main-thread rendering pressure, and behavior varies by PrimeNG major version.

Open questions

• Should server-side lazy loading use per-request cancellation or a sequence counter to discard stale responses?
• Is client-side virtual scrolling preferable when the dataset can remain local and pre-sorted despite possible main-thread pressure?
• Which approach better bounds worst-case latency when sort and filter actions arrive faster than responses complete?