Ember destroys dom, normal?

Performance
1

Hi,

as i´m still new, i don´t know if the following behaviour is normal:

I´ve a very simple table which is generated with #each. It shows 10 rows on every page. When i do a server side pagination to get the results 10-20, ember first destroys the complete dom an creates the new dom. This results in a flickering for a second. Why isn´t ember ember just changing the values?

thanks

2

i found a possible solution for me. but still would me interested in an answer for the question above.

To prevent the flickering i load the content from cache. when clicking on the “next page” button a server request is done to preload the page after the next page so all is smooth.

nextPage: (function() {
var page = this.get('page');
var totalPages = this.get('totalPages');
var start = (this.get('page') ) * this.get('perPage');
this.store.find("person", {
perPage:this.get('perPage'),
offset: start
 });

if(page < totalPages && totalPages > 1) {
  return page + 1;
} else {
  return null;
}
}).property('page'),
1 Like
3

I’m not sure I undertood your solution. Can you provide a JSBin or something?

About the flickering behavior, I think your noticing it because your are building your table inside the #each loop. Ember is detecting a change in the value of the property used over for the #each loop, so it delete the entire block and re-painting it. Other way, there is no way to know a priori if the number of rows are lesser than before, for example.

4

The effect doesn´t show in a jsbin.

The flickering shows up, cause the data from the server takes longer to load than from the ember store cache. So for example: when the table (10 rows per Page) loads for the first time it gets the first 20 rows from the server. Now when click on the next page button, page 2 shows without flickering cause the data is already in the store. Also the click on the next page button does a server request for the rows 20-30. So the data for the next page is preloaded before it gets requested by the user.

5

I think that is the best solution to the problem. It’s similar in concept to an infinite scroll.

Also I’ll consider bring all the data from the server at once. It is often a better user experience having to wait an entire second more the first time (and after that paginate on client) than having these kind of effects every change of page.

But this depends of a lot of factors, not last the number of models (and JSON size) you’re returning from server.

6

that was my first attembt. I don´t know exactly what the problem was, but starting with about 300 entries and using a filter ember doesn´t show the entries at all. After some browser refresh it works. But when using 500 entries nothing works. The data is in the store as it can be seen in the ember tool. The problem only exists when a filter is used.

7

@tellsapfel again, specifics would be needed to know exactly what it going on.

It sounds like you are returning a new array each time some other data changes. When you return a new array, Ember doesn’t know that the content of that array is the same and thus flushes all items from the collection view.

We provide array and reduce computed macros that can help you minimize this, such as filterBy. These tools re-use the same array and simply change its contents, minimizing the amount of view objects flushed when content changes.