Binding performance and "infinite scroll"?

462 views
Skip to first unread message

Michael Wills

unread,
May 18, 2012, 9:53:30 PM5/18/12
to ang...@googlegroups.com
Hi there,

New to Angular but I've been through several screencasts and experimenting with the fiddles. It's been a great learning experience so far.

In the videos it's often noted that exceeding 2000 bound items is excessive and that using $watch can be slow. I assumed using binding would be faster but I just realized that ngBind uses $watch itself.

If you're doing an "infinite scroll" kind of thing with long lists of elements with data binding, what would you suggest in this case, for example scrolling through long histories of data?

Thanks!

Michael

Andy Joslin

unread,
May 19, 2012, 12:20:54 PM5/19/12
to ang...@googlegroups.com
I guess there's only one way to find out... try it out

Andy Joslin

unread,
May 19, 2012, 12:21:20 PM5/19/12
to ang...@googlegroups.com
I don't have time now, but Vojta had an infinite scroll JSfiddle awhile back.  Just edit that to be more performance intensive.

Michael Wills

unread,
May 19, 2012, 3:39:27 PM5/19/12
to ang...@googlegroups.com
Good to know! Just dug for it.


An example use case is a twitter client. I use YoruFukurou. I haven't closed it in a couple days and have over 6700 tweets. It'd be easier to just have binding working for that many elements but of course that's a lot of watchers. But it's not too bad. It could mean just writing more optimized code and not using binding but using events for those areas where binding would be too heavy.

I was pondering a conditional check to see if a $watch expression needed to updated, i.e. if the DOM element is not visible because it's off screen or display:none, etc. I haven't seen a way to conditionally enable and disable watchers in the source. I'm still wrapping my head around the flow of things. Like in a twitter client example if I clicked an item to favorite it, IIRC, that event triggers the whole update since there could be cascaded events that cause various UI elements to update.

So one way might be to make a helper for $watch expressions that checks if an item should be updated or not. That check would still have some overhead but still more performant than updating everything visible or not.

Thanks much!

Michael

On Sat, May 19, 2012 at 9:21 AM, Andy Joslin <andyt...@gmail.com> wrote:
I don't have time now, but Vojta had an infinite scroll JSfiddle awhile back.  Just edit that to be more performance intensive.

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To view this discussion on the web visit https://groups.google.com/d/msg/angular/-/YVzxvr65sakJ.

To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/angular?hl=en.

Reply all
Reply to author
Forward
0 new messages