Ngx-datatable: Enabling Vertical body scroll undesirably enables infinite Virtual paging along with it.

Created on 14 Jun 2017  路  5Comments  路  Source: swimlane/ngx-datatable

I'm submitting a ... (check one with "x")

[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Requesting here because nobody answered my stackoverflow question - https://stackoverflow.com/questions/44523109/how-to-disable-page-output-event-being-called-on-scroll-in-ngx-datatable

Current behavior
Enabling ScrollbarV by default fires (page) Pagination Output on body scroll irrespective of whether actual pagination button is clicked. This has become a bottle in my project as I want body scroll ( Otherwise my page becomes too long for large tables!) with fixed headers but not infinite Virtual paging.

Expected behavior
Infinite scrolling should be enabled by another Input and not by ScrollbarV. I am in the early stage of adopting ngx-datatable for my highly data-driven project. But, if I can't work around this I'll have to move to other tools

Reproduction of the problem
This is my HTML :
[limit]="page.size" (page)='setPage($event)' (scroll)="scrolled($event)">

This is SCSS :
.ngx-datagrid {
.datatable-body {
min-height: 700px;
}
}

This is my js for fetching the server side data :
setPage($event) {
console.log("page no ", $event.offset);
this.pageChange.emit($event.offset);
this.page.pageNumber = $event.offset;
}

What is the motivation / use case for changing the behavior?
We are using a really old back end java server that doesn't bear too many load data requests. Hence I wan't to disable infinite loading while retaining body scroll.

Please tell us about your environment:
Ubuntu, Visual Studio code , angular cli dev server.

  • Table version: 0.8.x
    latest

  • Angular version: 2.0.x
    4.x

  • Browser: [all]

  • Language: [ TypeScript ]

Most helpful comment

Does the new [virtualization]="false" parameter help in this case?

All 5 comments

The purpose of the page event is just to tell you that the content of the viewport has shifted by a multiple of whatever page size is. I suspect your problem is that you're expecting the page event to do more than that one job. It is up to you to determine when to fetch more data, not the table. If you want to reduce the number of requests for data you need to either make a single request on load, or if too large for that either cache the request in the browser using request headers or in your JS.

I agree with OP - it looks like the page() event is raised on both page change and scroll, even if the actual page # didn't change. I feel like its one job is to notify that page changed.

I agree too - simply adding an indication of where this page event originates (bodyScroll || footerScroll) would help. At the moment the page event kicks in as soon as I click in the table, reverting back to page 1.

Does the new [virtualization]="false" parameter help in this case?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rannaot picture rannaot  路  30Comments

tplk picture tplk  路  30Comments

tomzi8 picture tomzi8  路  31Comments

Codermar picture Codermar  路  37Comments

SnakeB picture SnakeB  路  53Comments