Ngx-datatable: server side data with virtual scroll

Created on 8 Dec 2016  路  18Comments  路  Source: swimlane/ngx-datatable

ENHANCEMENT
I wonder or can't find in the doc if it's possible to have this with this lib 2 and 3 example: http://saulis.github.io/iron-data-table/demo/

The awesome of this angular2-data-table is virtualscroll is it possible to have virtuaclscroll but data from server and fetch data when we scroll to bottom of the table similar to link lib...?

Bug Moderate High

Most helpful comment

@deeg I would suggest a third solution that would keep the row detail intact for the current viewport and use a linear equation to calculate the row position when the page changes. This way you can allow for server side pagination with row detail. Following is what I would suggest:

  • Currently with or without server side pagination, the total number of rows are divided into pages. This helps with the pagination/pager feature in the datatable.
  • In case of both client side and server side pagination, total row count is available to the datatable component. Hence calculation of page count based on viewport size remains the same irrespective of server/client side pagination.
  • When the pagination type is server, the fenwick tree array size can be the same as the total number of rows that are available inside the page whereas for client side pagination, the algorithm can be set as is.
  • Translating scroll position to row position can utilize a linear equation just like how it was in the version you were using. const offset = (this.state.options.rowHeight * action.limit) * action.offset;. If the row window falls within the current viewport then re-initialize the fenwick tree cache.

I think the above can be implemented keeping the interface same i.e. get the row height, row position, scroll position. Currently I am starved for cycles given we have a production release for one of the applications I am working or else I would have submitted the PR myself. Hopefully the above should help you get started. Let me know once you submit the PR so that I can help with the reviews.

All 18 comments

Its possible, I'll make a demo later to show it.

any up here ?

Sorry, busy week. What API would you have in mind to handle this?

I think:
virtual scroll but we calla request first load to fetch 100items then when we are closed to bottom when scrolling so show a "loading bar" (for loading bar you can check this lib http://rintoj.github.io/angular2-virtual-scroll/ this 3th example called LOADING IN CHUNKS) then fetch new data and append new data to the existant..... arrayData , like this when we scroll again top we don't need fetch anything only when we are close to bottom when scrolling

something like this for api http://rintoj.github.io/angular2-virtual-scroll/#demo
i think two function can realize this scrolling() and scrollUp()

you actual example from server use"pager" but I don't want pager I expect your awesome virtual scroll, hope it's easy to achieve this cause I highly need it

one month I wait this example in docs ? load on scroll what'about ? thanks

Any hints how virtual scrolling and remote data (loaded in chunks as required) would work? I presume server side pagination rules out virtual scrolling which implies client side pagination?

When you can see the demo?

@amcdnl any news here (since 8 Dec 2016)?

I have this working with a very old version 0.9.3.

Every time I have tried updating I have had to wait because this issue has not been fixed. I took a very weak attempt at fixing it which can be seen in this PR here. There were issues with my solution, and probably needs a solution as described in the PR.

@amcdnl, is this wrong, is there actually a way to do it right now?

@java2kus - any thoughts on this?

@amcdnl, @java2kus was the one commenting in the PR about the calculation that needs to be added back in to calculate the virtual height of the scroller.

I have some free cycles at work to take another attempt at fixing it so I'm going to proceed as this is not yet possible. Please stop me if you learn otherwise in the mean time.

So I took a much deeper dive into this at the end of last week, and I wanted to come back with how I understand the current implementation, and discuss some possible solutions forward.

The main change that broke this feature was the addition of the row detail feature, which allowed rows to be one of two heights. Either the defined rowHeight, or the rowHeight + detailRowHeight.

In order to be efficient in calculating the new height of the scroller, a row-height-cache class was added in which used the fenwick tree to calculate the total height of a given set of rows, and get the row index for a given scroll position. It took me awhile to understand how this was working, but in the end it does seem really neat and allows you to calculate the heights and row indexes in O(log n) time.

Given all of this information I tried to update the current row-height-cache to work with the case of virtual scrolling WITHOUT loading all of the rows into the treeArray since there could be millions of rows on the server. The problem I see with the fenwick tree solution is it breaks down if all of the rows are not filled in the treeArray. Lets take the following example:

  • I load the table and the first page loads.
  • I then drag the scroller all the way down the page and load the very last page.

Since the pages are not next to each other in treeArray and there could be pages in the middle, the bit shifting technique which fenwick tree uses breaks down, unless there is something fundamental I'm not understanding. If you can suggest a way to make the fenwick tree work in this situation, please ping me and lets talk!

So the way I see it we have a coupple solutions:

  • Keep the fenwick tree solution in place for non server-side pagination and turn to another maybe less efficient technique of calculating height and positions.
  • Remove the fenwick tree solution in both cases and come up with a new technique which works in both situations.

@amcdnl, @java2kus I wanted to reach out to you guys to find out your thoughts before I moved too much further.

@deeg I would suggest a third solution that would keep the row detail intact for the current viewport and use a linear equation to calculate the row position when the page changes. This way you can allow for server side pagination with row detail. Following is what I would suggest:

  • Currently with or without server side pagination, the total number of rows are divided into pages. This helps with the pagination/pager feature in the datatable.
  • In case of both client side and server side pagination, total row count is available to the datatable component. Hence calculation of page count based on viewport size remains the same irrespective of server/client side pagination.
  • When the pagination type is server, the fenwick tree array size can be the same as the total number of rows that are available inside the page whereas for client side pagination, the algorithm can be set as is.
  • Translating scroll position to row position can utilize a linear equation just like how it was in the version you were using. const offset = (this.state.options.rowHeight * action.limit) * action.offset;. If the row window falls within the current viewport then re-initialize the fenwick tree cache.

I think the above can be implemented keeping the interface same i.e. get the row height, row position, scroll position. Currently I am starved for cycles given we have a production release for one of the applications I am working or else I would have submitted the PR myself. Hopefully the above should help you get started. Let me know once you submit the PR so that I can help with the reviews.

Any news here @amcdnl @deeg @java2kus

I ended up moving away from virtual scrolling with my server side pagination, so I am no longer working on this unfortunately.

Unfortunatly

how can we disable virtual scroll for server side pagination ?

[scrollbarV]="false"

Was this page helpful?
0 / 5 - 0 ratings