Emberjs big table


#1

I have a page with a few tables, in total there are a few after 1000 rows.

After the tables is ready, when I click to go on another page, the route is changing in the address bar, but nothing happens until a few seconds. Then the new page is rendered.

Why is that and what can I do? Thanks.


#2

@ioanszabo sounds like there could be a number of things delaying your new page render. Generally I think it’s going to be either data fetching for the new page (the model hook) or rendering time. You’ll want to do some investigation on network request times (can be done via the chrome network console or via timing logs in your code) and render times (the Ember Inspector chrome extension has a great render times panel). I guess maybe it’s possible that the teardown of the large table could be taking a while but I’ve never run into anything like that myself.


#3

Hi,

Yes, actually is when the table should tear down. Request is fetching quite fast. Can I do something about this?


#4

Hi @ioanszabo , I came across this problem several time and I solved it by choosing the following techniques : (Assuming the network is fast)

  • Reduce the number of items displayed per page (This really depends on the number of rows and row rendering time, you can use ember tools in chrome and see how much each time the component need to be displayed)
  • Hide all the rows contents by defaults and display it only when the user see it by using https://github.com/DockYard/ember-in-viewport
  • Select parts of the row to hide and display it only when the user demand it.
  • Take advantage of ember run loop, When the component receives data, it should display a loading animation until the component is rendered, To do this, you will need to display the loading animation in didReceiveAttrs() and inside this method, tell ember to stop the animation after it is rendered by using run.scheduleOnce('afterRender', this, () => {...});

#5

Thanks for the replies. As a conclusion Ember has issues in generating a table with 1000 rows. But this is not wrong? I mean 1000 rows is not that much. I saw reports with more than 1000 rows working relatively fast.


#6

@ioanszabo well it kinda depends on the table setup. 1000 rows is actually quite a lot if you’re using components to render the rows, and possibly even if you’re just using raw <tr> and <td> tags. We used to use raw HTML in our app and switched to Ember Light Table for rendering our tables and even with Glimmer 2 it still just takes time to render lots of components. This seems to be a common problem across SPA frameworks. The solutions seem to be using fancy javascript (see smoke and mirrors addon), using canvas tables instead of regular DOM tables, or using infinite scrolling and loading/rendering data over time instead of all at once.

So in conclusion, it’s not as trivial a problem as it sounds and many developers have struggled with it and there aren’t any really ideal solutions.


#7

I find Google’s articles on this topic helpful in understanding the interactions better: https://developers.google.com/web/fundamentals/performance/rendering/ Also, for how a popular ember table add-on is trying to solve the problem checkout this issue thread: https://github.com/offirgolan/ember-light-table/issues/12. There are a few good examples of


#8

Thank you guys for your answers. The ‘tear down’ process is costly also? I mean when I click to change route, it is changing in address bar but nothing happens until 1 - 3 seconds passes.