Using ngController With ngRepeat In AngularJS

Posted February 15, 2013 at 4:20 PM by Ben Nadel

Tags: Javascript / DHTML

Reader Comments

I like the idea but performance concerns me. It is creating 1000 controllers for a 1000 item list. Yes, 1000 item list is extreme but you get my point.

Have you tested the performance of something like this on a larger list of items?

@John,

I think performance *can* definitely become a problem. I think it's one of those things where you need to roll with the punches. For the app I'm building, we just do "normal" approach first; then we when we performance becoming an issue, we take steps to fix that particular interface.

And, Yes, we have seem a few issues with performance, typically with large datasets and complex user interactions. But, for the most part, performance has not been a concern at all.

... and, for cases where things to become a concern, I've begun investing the use of more "delegate"-style approaches, such as using jQuery's event delegation:

http://www.bennadel.com/blog/2448-Using-jQuery-Event-Delegation-In-AngularJS.htm

... but, honestly, it hasn't been much a problem except for a few very complex UIs.

@Ben,

Yeah, I figured it would be pretty quick and I'm not against the idea (actually dig it) but that was the first thing that came to mind.

Keep rockin' Angular posts man. Loving them.

@John,

Thanks my man! I'll keep at it - hopefully get some good stuff out here :)

Reminds me of backbone where a list is often times is a view + model - even if just a smaller set of code.

It does give it much more of a OO approach

@Steve,

Yeah, I definitely like the granularity in the control. As I've been learning about AngularJS, I've created a few HUGE Controllers. It would be nice to go back and see if a good splitting / refactoring into smaller Controllers would feel good. Still trying to figure out where the balance is.

@Ben,

nice example, however I think this kind of selection can be easily achieved without having to instantiate a controller for each repeater item. Having the selection logic in one place makes it easier to read and understand (as you don't have to do this "implicit" parent scope method call, e.g line #245 in your example).

To illustrate my approach I made plunker with your (refactored) example: http://plnkr.co/edit/HUsWAwk2HlemssUncr5H?p=preview

Great blog!

Btw, I've found your blog via my github where someone posted link to this entry: https://github.com/matys84pl/angularjs-requirejs-lazy-controllers/issues/4

@Mateusz,

Definitely not all situations merit the use of a repeat-based controller. It's all about trade-offs. For example, in your Plunkr, you tie your dynamic class to an isSelected() method in the View. This means that AngularJS has to call that method every single time it runs a $digest (which can be very often). In this example, that work is fairly trivial; in a larger example with a larger collection, it may not be.

Sometimes, I use your approach, but I actually augment the "model" itself to use view-based properties. So, I'll actually just inject the "isSelected" property into the friend itself:

ng-class="{ selected: friend.isSelected }"

... then my select/unselect methods will just toggle the property on the friend object directly. This makes it very easy to read; but, it requires more upfront preparation to make sure that all your friends are injected with the default property.

Definitely, each approach has a pros/cons. I don't feel terribly strongly for any one.

@Ben,

Agreed on calling a method for every digest. I'm working with our team to use that sparingly.

Easy or "can" is not always the best "should" answer. Simply put, as you say, pros and cons.

I realized something else with this sample - what I originally thought was happening was that for each item in the repeater it would have it only controller AND partial view loaded.

This was what I was thinking reminded me of Backbone, but I think it's not the same. ie. in Backbone, you would have a collection and then for each item it has an object and it's partial view.

Now I see, it's just a second controller, but still same view, just spreading out the functionality across multiple controllers ?

ie. my sample - was let's say you had a controller that is loaded from a route and contains a list of 'people'.

Then for each person - you want to split that view/edit code out into it's own partial and controller to separate concerns.

PeopleController
ie ng-repeat=person in people

inside each person:
PersonController
it has a partial view

@Ben and @John,

of course I agree with you, it's never a black or white decision as you can have multiple solutions and all with their own drawbacks.

Regarding the digest cycle, your "{selected: isSelected}" and "isShowingNickname" also will be checked/validated every time. That's why I've used a map to store selected values to keep the complexity of the check at minimum.

friend.isSelected - I always try to avoid storing view specific (?) data in domain objects, but I have to agree that this is the simples possible way.

@Steve,

Yeah, exactly correct. The one caveat with AngularJS is that each "clone" of the ngRepeat loop gets its own $scope, which extends the $scope of its parent container. So, each "sub controller" that gets instantiated gets its own unique "sub $scope." This can be a bit funky when it comes to read/writes to the scope as it can lead to unexpected outcomes if you don't fully grasp prototypal inheritance and how properties get read vs. how they get written.

@Mateusz,

Ahh, sorry, I read your Plunkr too fast :) If you are caching the selectedness of a given friend in a hash, then yeah, that would be very performant. I love using hashes as look-up tables for things. Good move!

I recently jumped into Angular and Ben your blog has been extremely insightful. I've been trying to figure out whether to use ng-repeat with a cloned controller like you have here, or use a complex series of directives.

Basically our app is a 4 level form setup with a RESTful design. There are various templates possible for each level and we would need to be able to create new forms, load existing forms to edit/delete, and dynamically add/delete objects within each level.

Do you think it would make sense to have controllers for each object of each level? Here is an example of the code we're working with.

Example object previously loaded via REST:
example = {
...
"pages" : ['/api/alpha/page/1', '/api/alpha/page2', ... ],
...
}

In the HTML:
<div ng-repeat="pageURL in example.pages" ng-init="expand()" ng-controller="PageCtrl"></div>

In controllers.js:
function ($scope, $http) PageCtrl {
$scope.expand = function () {
$scope.response = $http({method:"GET", url:$scope.pageURL});
}
}

@Michael,

I'm glad you're enjoying the AngularJS posts. I've been loving AngularJS; but some of it is definitely complex! This (your) kind of nested data display is something I've been trying to think a lot about lately. In an app that I'm building, we have several displays where we have a "master" entity, and then several tabs, each of which has its own data. Trying to figure out where to use Controllers, Directives, and how granular to make those Directives has been an ongoing journey.

The more I play around with nested Controllers, the more I like them. But, with a nested controller, there is the question about where does the data come from? Does the master controller load the data and then simply use the nested controllers for help in display? Or, can the nested controllers also make requests for data such that they render a combination of inherited ($scope) data and $resource data?

I'm still grappling with this question. Currently, I tend to treat controllers as either 100% inherited data; or, 100% independent data. Meaning, a Controller either gets all of its data from the parent controller; or, it gets all of its data from the service layer. I haven't really experimented with a mixed-data-source approach yet; but, I feel like I need to think more deeply about it. The complete separation, one way or the other, has simply been the easiest way that I can think about the scope of the behavior.

Now, Directives are also very interesting.

I'd say when it comes to directives, try to think about the smallest behavior first, to see if you can create a directive that enables JUST that behavior. A lot of times, you can use 2 or more small, independent behaviors to create complex behavior.

When you need to "coordinate" lots of behavior, this small directive approach can start to fall short. When I get to that kind of a situation, I start to create UI "helpers". As in, "contact-form-helper", that will help coordinate the UI transitions and behaviors across a cohesive UI.

Sorry, I know I'm kind of rambling here; and that's because I don't really have a good answer. Sometimes, directives can be completely abstract; sometimes, they have to be tightly tied to a given interface. Some of it is trial and error; some of it is just learning to think more "generically" about behavior.

I'll try to come up with some more nested Controller examples as this is something I really want to investigate myself.

in order to have a per item behaviour, I used to contrive a directive. That was before I read this valuable post of you :)

@Aladdin,

Awesome - glad I could help provide an alternate implementation.

Post A Comment

Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Supported HTML tags for formatting: <strong>bold</strong>   <em>italic</em>   <code>code</code>
	Remember my information
	Subscribe to comments
	Send me a copy of this comment