[SchizoDuckie]

There is really no need for this. It adds nothing imo but another layer of sauce over what angular already does properly.

If your controllers are getting huge, go refactor into directives and services. I don't see how this would help since there isn't even inheritance?

also:

    app.controller('AppCtrl', ['$scope', '$location', '$http'], function($scope, $location, $http) {
    // ... 
    }]);

vs

    app.classy.controller({ name: 'AppCtrl', inject: ['$scope', '$location', '$http'],
      //...
    });

Congratulations, you have saved absolutely nothing (10 bytes? ) and just made it harder for me to understand your angular app.

One of the brilliant things about angular is that it provides a proper structure that anyone that needs to write angular needs to adhere to. If you start introducing layers upon layers of funkyness and glitter, you'll end up with something non-angular.

what I mean by that is: Classy introduces new conventions in a frameworks that already has a lot of conventions to keep track of while coding, and my biggest argument against this is that you introduce a dependency to Classy for all code based upon it, therefore you've created an extra layer of complexity to fix and track down when angular changes.

In my mind effort like this should go into the angular core to make it better.

[davej]

Thanks for the feedback. I would argue that the Classy example is more expressive and crucially it is DRY.

Edit:

> One of the brilliant things about angular is that it provides a proper structure that anyone that needs to write angular needs to adhere to

Angular doesn't provide structure for controllers, they are just javascript functions. If you want to add structure it is up to the individual developer to decide how to do it. Classy is just the way that I like to do it, Classy is opinionated so it won't be for everyone.

By the way, you can do inheritance but I haven't documented and fully tested it yet.

[SchizoDuckie]

Angular's dependency injection is still a matter of discussion and a lot of people are not completely happen with it. It'll also be made into something different for angular 2.0.

Still, besides that: DRY is IMO not about these 2 lines that you've refactored away here. It's about whole functions/classes that have similar functionality where you're repeating yourself.

Therefore, this would be a micro-optimisation with negative results on impact on performance most likely (since there's more overhead)

[sanderjd]

The point of DRY is to reduce the types of errors that repetition lends itself to. A very common member of that class of errors is "I should have repeated something, but I didn't". It is pretty easy to run into that error with Angular's injection - you can forget to add either the string or the argument, or (worse) you can get the order wrong. Eliminating the repetition fixes that class of errors, so I think it's well within the realm of "what DRY is about".

[bilalq]

I can see Classy adding value, but repetition with dependency injection is a solved problem if you use ngmin[1].

[1]: https://github.com/btford/ngmin

[sanderjd]

I disagree that ngmin is a full solution to the problem. It is a good and very helpful tool, but it's a hack and a pretty leaky one - I think it's often less of a hassle to just write all the explicit injection syntax myself than to fiddle with formatting to get ngmin to work and track down issues when it doesn't. Classy's solution seems much nicer to me.

[Cthulhu_]

I have no idea what you're talking about; I've never had any issues with ngmin or angular's default (i.e. non-array / string) injection methods.

[mcv]

I ran into this exact thing just a few days ago. I added a dependency to an existing controller, and it threw an error because I'd only added the dependency in one place instead of both.

This is absolutely one of the things that DRY is about.

[mcv]

> Angular doesn't provide structure for controllers, they are just javascript functions. If you want to add structure it is up to the individual developer to decide how to do it.

This is a pretty big one to me. Angular provides tons of structure all over the place, with only one real exception: controllers. Some of my controllers stick out like sore thumbs in my code. I like how Classy gives them some structure not unlike the structure that directives already have.

[airtonix]

I would argue that if your controllers are getting that complicated, then you're doing it wrong.

[lhorie]

Wouldn't you need to be doing `var self = this` in every function you have nested anonymous callbacks touching $scope though?

[davej]

Yes or function.bind() or fat-arrow in Coffeescript. It's usually best practice to move that kind of stuff into a service instead though.

[zoomerang]

Look a little closer - It's not about saving bytes. I ended up coming up something very similar for my projects and it made a notable difference in defect rate.

- Removes the need for positional arguments for constructor injection, so you only have to list your dependencies once. This one seems minor but can be a major frustration and a source of bugs when working with lots of services.

- Moves actions out of the scope and onto the controller itself, where they belong.

- Provides a clean template structure for other project members to work off that guides you to nicely structured and properly separated code (i.e. Watches in one section). This seems minor, but when you're working with multiple junior developers it starts to become a big deal very quickly.

You can do all this without using a third party project, but if you're new to Angular this is a nice bootstrap and helps guide you towards a solution that avoids a lot of warts in the framework.

[vladgur]

"- Moves actions out of the scope and onto the controller itself, where they belong"

Based on the Classy's docs, it doesnt "move" actions out of the scope and onto the controller, but the other way around. It adds controller's actions to the scope unless you prefix the names with an underscore.

Based on my experience debugging angular performance issues associated with expensive $digest cycles, I do NOT WANT it to happen automagically. I only want those functions on the scope that i explicitly place there.

[jonny_eh]

But angular only watches functions you tell it too. What's the harm in attaching a function to the $scope if it isn't used by an angular expression?

[syncsynchalt]

To be fair ngmin already fixes the injector problem, in most cases.

[sanderjd]

It's the "in most cases" that'll get ya!

[syncsynchalt]

The feature of angular-classy that looks appealing to me is reducing the constant repetition of $scope. You still need to use this.$ or this.$scope when manipulating scope variables, but at least it hides it in the case of definition of scope methods.