Open stephentcannon opened 10 years ago
I did plan to do this initially, but ended up not needing it for my app.
It will require extra configuration to make collections accessible to reactive-table on the server, but I think it should be doable.
I deal with large collections. Tens to hundreds of thousands of records. So, I have to throttle things.
I am not using this in any production apps yet....but I am using it in a Card Issuing system that I am in the middle of building. Card issuing systems have massive records.
In my current production projects I am using my own pagination and filtering and tables but I like yours a lot. Maybe, if I have time maybe I can submit some PRs.
I was thinking server side filtering and pagination should be optional. It shouldn't be mandatory. Maybe as an add-on feature that isn't necessary out of the box.
It really wouldn't take much if I understand your package sufficiently.
I think it would require a method to return total number of records and usage of the skip limit. The field name is known by what is being sorted and keywords is from the filter record. Then just tell users to implement the Session vars that correspond if they want server side pagination and filtering.
Glad you like the package :)
I agree that it should be optional. I was thinking something along the lines of having users call a server-side function to register a collection with reactive-table. Any tables with unregistered collections could continue to do everything on the client.
If I remember correctly from my original experimentation, you do need something on the server-side to pass the collection in. I couldn't figure out a way to get the server-side collection based on the client-side one.
I've just implemented server-side filtering for the meteor-autocomplete package. Here's the server code - thought it might help. It returns the records from the server collection that match the autocomplete filter.
The luma-datatables package apparently does server-side filtering. It certainly does pagination.
Any update on this guys? It's really a MUST feature, Not only it does handle a lot of records but it's also a must if you wanna scale you up and make your app efficient!
I haven't had time to work on this yet, but I do plan to at some point - it's the biggest limitation of the package.
Hey guys, I'm finally working on this and you can try out 0.6.0-beta1.
You'll need to call ReactiveTable.publish on the server - here's some documentation: https://github.com/aslagle/reactive-table/tree/server#server-side-pagination-and-filtering-beta
I wanted to make ReactiveTable.publish similar to Meteor.publish, but it needs a collection instead of a cursor.
There are still some things to work on (it may not work with iron:router yet), but I'm curious what you guys think of this approach and if it will be fast enough.
I have been trying this out so far and it works well out of box. Data set size is 3,000 records and I am displaying two on screen, although I am passing in the whole collection...
0.6.0-beta2 fixes a bug where rows would be missing if they had been on the previous page the table had subscribed to, which was causing problems with iron:router.
I published version 0.6.0 - please let me know if you find any bugs :)
there is no documentation on server side pagination. is the client side pagination make server publish paginate automatically? or there is a custom setting for this?
The documentation is here: https://github.com/aslagle/reactive-table#server-side-pagination-and-filtering-beta
Any hints on how to make this work with Iron:Router?
You won't be able to wait on the subscription with iron:router since it's handled within the reactive-table package, but otherwise it should work fine.
I like this package but I can't figure out how to get it to work so that it does server side filtering and pagination.
Anything over a few thousand records gets clunky.
Any ideas?