I want to make a grid with server side pagination sorting and filtering, i have all set on the back-end with Rails and active-models-serializers, currently i managed to do it with datatables.net plugin and plain JS/JQuery, but ATM i want to migrate the front-end to EmberJS, till the moment all i can find are some examples with ArrayController and Pageable-Mixings doing some kind of client side pagination which don’t work for me on this application. Is there any datables.net replacement in the EmberJS ecosystem?, any help is appreciated.
On my project we leveraged Ember Table but we had to extend it to handle our complicated use-case. You might find what you are looking for out-of-the-box.
Here’s how I use server-side (kaminari) pagination with Ember. https://gist.github.com/tcjr/6935684
2 Likes
@jasonmit, @tcjr I appreciate the help, let’s see what i can do with it, I wish there is a versatile table with all this features as Backbone and AngularJS has, I’m sure there are many people with complex grids requirements on their sites; I’m sure too many of them are not using EmberJS for the lack of full featured grids; sometimes there is not time to assemble all the peaces together by yourself. Do you agree?, I think we should start with a project regarding this, a 1-1 replacement to datatables.net written in EmberJS.
Here is a gist by @alexspeller where he extended Ember Table and implemented sorting/filtering/grouping etc.
It is using server side?, seems interesting to me, i will take a look to it, many thanks @jasonmit!!!.
When you say server side, you’re asking if it’s hitting an API and returning data that is rendering in the grid?
If so, yes. It’s essentially an ArrayController and you can redraw the content with events that bubble up to the router, make the AJAX request, and swap out the array controller’s content.
Hey guys, seeing some many examples and sites using client side pagination; now i wonder: why is so much focus on client side pagination?, is it suitable for large amounts of data?, AFAIK is not but i might be wrong (i might have missed http request gzipping and client side caching which can improve performance) can you please give your opinion?, imagine you have to show up to 10k rows of data.
That is where virtualization comes in, which is built into Ember Table. You can check out their second example which has 500k records.
If you’re worried about payload size that could potentially be a concern (I’m not sure how complex your models are).
Ember Table is agnostic to how it receives the data it’s rendering. You could easily implement pagination with basic routes or send it all down in one shot.
Thanks for everything @jasonmit!
Is there any place where i can read more on virtualization?
I’m not an expert in this but I can explain the gist of it. It only ever renders the number of rows that could fit inside the viewport, in this case the height of the table, into the DOM. The rest of the rows sit in memory (or lazy loaded via ajax calls) while emulating the rest of the rows by making the scrollbar appear as if there is content below or above the point where you are at. This is calculated based on the fixed row height * total count. Tt would be difficult to implement virtualization otherwise if the row height is not fixed.
As you scroll, it reuses the existing row views, instead of creating new ones and simply swaps out the row content with new content based on the scroll position.
@jasonmit +1, I appreciate the explanation.