4 ms·

- Everything you need to know about Angular is explained in ng-book or the like. Trying to learn the framework by reading blog posts isn't going to work. There'

- Everything you need to know about Angular is explained in ng-book or the like. Trying to learn the framework by reading blog posts isn't going to work. There's just too much to know, and it's impossible to understand what's really going on unless it's presented in a logical and comprehensive way. - Angular isn't designed to render large tables. Go with DataTables for jQuery instead, or if you don't need all the features there then maybe you can get away with ui-grid. In general though if you're running into performance issues because you have too many bindings, then you're probably using it for things it wasn't designed for. Also, don't forget 'track by' for improving ngRepeat performance: http://www.codelord.net/2014/04/15/improving-ng-repeat-performance-with-track-by/ http://www.codelord.net/2014/04/15/improving-ng-repeat-perfo...

dasil003 12y ago
Where is the disclaimer about data binding limitations? Tabular views with hundreds or even thousands of rows aren't inherently uncommon or non-performant. It's easy to sit here and say "wrong tool", but this is a pretty significant weakness IMO.
- Alex3917 12y ago
  There probably should be a disclaimer in the official docs somewhere, but if you Google for ngRepeat performance there are tons of discussions on this. It's also a perennial favorite topic for angular tech talks. There is also a lot of information on how to improve the performance if for some reason you really want to do this. That said, even if the performance were great right out of the box without using one-time bindings or tweaking the trackby parameter, it still wouldn't make sense to do large tables in angular because you don't have any of the other datatables functionality.
  - mgkimsal 12y ago
    "Trying to learn the framework by reading blog posts isn't going to work." "...but if you Google for ngRepeat performance there are tons of discussions on this."
mping 12y ago
Anyway, it's extremely easy to get around this, provided you are willing to update the table yourself. You just skip the two-way bindings for each table cell and update the cells for yourself. No big deal. If you try to glue angular and d3js I'd say that this is the common course of action - nobody's going to two-way bind every single property

dasil003 12y ago

Where is the disclaimer about data binding limitations? Tabular views with hundreds or even thousands of rows aren't inherently uncommon or non-performant. It's easy to sit here and say "wrong tool", but this is a pretty significant weakness IMO.

Alex3917 12y ago
There probably should be a disclaimer in the official docs somewhere, but if you Google for ngRepeat performance there are tons of discussions on this. It's also a perennial favorite topic for angular tech talks. There is also a lot of information on how to improve the performance if for some reason you really want to do this. That said, even if the performance were great right out of the box without using one-time bindings or tweaking the trackby parameter, it still wouldn't make sense to do large tables in angular because you don't have any of the other datatables functionality.
- mgkimsal 12y ago
  "Trying to learn the framework by reading blog posts isn't going to work." "...but if you Google for ngRepeat performance there are tons of discussions on this."

mping 12y ago

Anyway, it's extremely easy to get around this, provided you are willing to update the table yourself. You just skip the two-way bindings for each table cell and update the cells for yourself. No big deal. If you try to glue angular and d3js I'd say that this is the common course of action - nobody's going to two-way bind every single property