Some days ago I’ve posted question on stack overflow concerning caching temporally rendered views in browser without any sucessfull response. As I did some research about this subject I can see that a lot of people is interested in similar functionality, as you can see here or even on this forum (I just can’t post more links right now). Here comes my question - is it possible in actual version of ember or is this involving changing ember core?
I was just looking into this and would like to revive the topic.
It takes several seconds to render the master-table kind of page in my app. OK, we can deal with that the first time. But every time they navigate away for a second, this view is thrown away and the user must wait anew.
I would like to yank out this specific view out of the normal lifecycle and store it away somewhere. All its DOM can remain hidden within the page, keeping the references. Then, when the user navigates back, I look into my “large views cache”, take this out and bring it back (perhaps updating the data through an ajax call).
Basically sacrifice memory for the performance.
Is it even worth my time trying to hack something like this together? Or is it completely hopeless?
I do not have completely idea how to begin such improvement.
If you really have troubles when rendering long lists/tables you should have a look at Ember.ListView.
This helps a lot.
If for whatever reason you can’t use this it is easy to create an infinite scrolling component that renders content bit by bit which also will reduce rendering time.
1 Like
Hey, having the same issues here, long list, takes to long to render… A infinite scrolling component that renders content bit by bit (but loads all models at once at the beginning) would be awsome! do you have any startpoint for such a thing?
There are all sorts of problems with dynamically rendered lists - scrollbars, browser search, vertical alignment etc… It’s only trivial to implement in trivial use cases. Even the best coders (eg. Discourse) are having problems with this.
Also, my problem is really that each row in the list has a lot of dynamic data crammed into it. So even a 100 rows list feels sluggish.
I really think some kind of global caching is the solution here. Once the list is loaded, it performs fine. It’s the build-up that’s the problem. I just don’t have the time right now to really dig into it.
Here’s an example on how one could implement an infinite-scrolling component that renders data bit by bit.
This should help with initial rendering time but as I said, if you can use Ember.ListView, use Ember.ListView.
For the use case I had I needed to support variable row heights which was not possible with Ember.ListView at that time so I used the infinite-scrolling approach. worked well.
I appreciate the advice on ways to ameliorate the impact of this one specific type of expensive-to-render view.
It is a derail though. The original poster did not mention having a long list, and there are a multitude of other reasons why a view could be expensive other than being a long list.
Do you have any advice on how to persist views that are expensive in ember, as opposed to advice on how to make one particular type of expensive view less expensive?
It’s easier to speak in specifics. Can you give an example use case where an expensive view could benefit from caching in a way that would be useful to you?
@tarasm Yes, I can. Please take a look at google spreadsheet. On the bottom you can switch between sheets but each of them is rendered only first time. Next time when you try to switch the sheet you do not have to wait so long.
http://content.gcflearnfree.org/topics/198/sheets_rename3.png
@estshy I know that ListView is getting this kind of optimization, but it’s not going to be caching rendered views. It will cache instantiated views and reuse them as necessary. Glimmer will provide diffing which will make repopulation of these views a lot faster. Between reusing views and diffing, we’ll get Google Spreadsheet like performance.
I think the changes that are coming should make manual caching of rendered views unnecessary.