Row selection currently flags each GridRow as selected. For paging, I might need to change it to keep an array of selected rows instead. Even if I did that, there would be possible errors because the selected row would not be in the rows collection.
@cbsm1th: FWIW, I would see paging and infinite scroll as different user representations of the same API
from an api viewpoint, ng-grid would be showing a subset of the data - for argument's sake there are 10,000 rows, and ng-grid currently has 100 of them.
when you scroll down (whether that's infinite scroll down, or press the next page button), ng-grid needs to hit some sort of callback or API to "get next 100"
The things I can imagine that would need to be covered are:
the basic api - declare paging active, set page size, get next page (or get page) callback
more advanced: hooks for filtering and searching - so whenever an ng-grid filter or search call is made, you now have to call server instead of issuing locally
UI effects - configure whether you want traditional paging or infinite scrolling
if infinite scrolling, some sort of magic that predicts when someone will hit the end of the current data set, and proactively gets the next chunk
I think there's a bit of thinking in whether we're doing paging just because we don't want to get_ all the data at once, or whether we're doing it because we don't want to _hold all the data at once
The former implies that we get it as people scroll, but we don't have to discard what we already have - and eventually we could end up with everything held client side if they scroll for long enough. This is potentially easier to implement, and deals with some issues like "what if they selected some stuff on earlier pages"
The latter implies that we throw away what we had as they scroll, and go back to the server to get it again later if we need it - if you have a really big data set it makes sense, but otherwise it may be a lot harder for not a lot of benefit
(Note, I'm probably not a user of pagination, I just happened to read and think about it a bit, so thought I'd share my 5c despite having no dog in this fight)
@PaulL1 thanks for the thoughts. You raise some very good points. I really like the idea of keeping it all in grid.rows and just rendering one page. would work well until we got into 10's of thousands of rows
I set a limit in our application. The user an pull back 4000 rows (50 rows at a time until it's all in the client) That's it (and that's a lot) . They want anymore, they change the app's search and go get a new set of data
Thanks for ya'lls input. I'll take it into consideration as I get started with this. I'm moving to a new place so I'll be working on it in a few days
@swalters: makes sense. For my application, I did a bit of performance testing and eventually concluded that size on the client end wasn't a material issue - the grid seems happy up to a few tens of thousands of rows
my app wouldn't often have that much, but it could. And the grid worked OK with it
benefit was I could just ignore paging, and do all filtering and the like client side, which was frankly a much better user experience. I have no intention of supporting free text search on my database, but it seems to go just fine on the UI
I also performance tested the database end - and in general out to a couple thousand rows it isn't an issue to just get them all, even though they're scattered around lots of data pages
in terms of transfer size, it's all JSON and compresses really well, so I still only had JSON files at about 300-400k
In short, at least in the near future, I ended up deciding I had no use case for it
But I do fully understand that other people do.....
Hi I need help to do pagination in angular 1.5
any can help , me
Pruthvi Raj Tony
Hi i want to check for duplicate rows in Ui grid For example:: there are 3 columns in the grid , in the 1st row if user select A, B, C and in the second row user select A, D, C and third row user select A,B,C #then i need to know there is a duplicate row with A, B, C Can I get some help with this.