Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    An Alternative Approach to Controllers

    John LindquistJohn Lindquist

    AngularJS makes your HTML very declarative. However, seeing the functions invoked in your HTML may not offer any clues as to what controller defines said functions. This video offers an approach to solving this problem by returning the controller in the controller definition so that we can opt for something like ng-click="SomeCtrl.doesSomething()" instead of simply writing ng-click="doesSomething()".



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson




    John Lindquist: I would argue that the number one benefit of AngularJS is that it makes your DOM and your HTML really declarative meaning that if you look at the HTML, you can tell what's going on in your app by the way you define components and behaviors inside of your elements and whatnot.

    Some people may argue that if you set up something like --I know I always default into a button -- NG click and you've put a method in here saying "say hi," like "OK," I realize I'm invoking a method called "say hi" but where is that actually being called? It could be inherited from a parent scope and that sort of stuff. There is a train of thought that if instead of...To do this right now, you'd have to say, "say hi." It's your function, and you say "alert, hi" and you should see this work.

    There's a train of thought that if instead of assigning this to scope, you actually assign it to the controller itself. Then what you can do is return and assign a property on the scope to this. Then return that, which would allow you to, instead of just saying "say hi" here, you could say "app controller. say hi." That way it's completely clear where that method is being invoked. You know it's on the app controller, it's easy to find, and it still works the exact same way. Then you can put scope changes in there and everything.

    It just kind of creates a level of extraction around by putting everything inside of the controller. It's still accessible through scope inheritance if you reference "app controller." It kind of creates that level of separation so you know exactly what's going on in HTML.

    I'm not really arguing for or against this. It's more of a personal taste. I've seen a few guys who really love this approach and some people think it's unnecessary. If you like it then go for it. I don't think there's any reason not to that I've found other than the general convention or that the examples you've seen around the Internet generally don't do this.

    Take it how you want and toy with it. See if you like it.