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) {
// ...
}]);
app.classy.controller({ name: 'AppCtrl', inject: ['$scope', '$location', '$http'],
//...
});
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.
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.
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)
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.
- 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.
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.
I very much suggest everyone interested in Angular development to read what the guys at MeanJS.org[1] have to say about structuring modules. It helps me think about my app a lot better. The structure could be cleaned up a bit though (e.g. module A can use module B's filters at run-time, this is a bad thing IMO. There should be global and local filters).
TLDR; THANK YOU (Intermediary AngularJS learning–curve is friggin hard.)
I haven't found out how to do this yet. Not fixing it until it breaks, even if that means I'll have to re-write parts of the app.
Fun geek fact: The Mac OS style close/minimize/expand buttons on the code editor are written in CSS, they're not images. A bit of a pointless exercise but a fun little easter egg.
So long as non-Classy controllers are still operable (which I assume they are), then I should be able to port individual controllers one at a time without disturbing un-ported controllers, then this is exactly what Angular was needing, IMO.
As a side note, I am always impressed and insanely jealous of the nice websites that frontend libraries make for themselves. It makes sense since obviously folks with more frontend experience are writing the libraries, but I wish there were nice templates or tools to make such nice and informative pages. Would be cool to see stuff like python, boost, etc. with clean, responsive, easy to read web pages.
As a side-note (don't mean to hijack this thread) but I always wondered why a service doesn't exist that sits on top of GitHub that allows for reviews/commentary beyond just issues on all these cool GitHub projects. There are so many awesome projects that look really interesting and I want to integrate into a project I'm working on but have no way of really knowing how effective or relevant they are without actually trying it (which sometimes works out but sometimes ends up being a waste of time). Just a thought, wonder if anyone else here at HN sympathizes.
I see people using issues for this sort of meta-discussion on newer projects. Sometimes that feels wrong and sometimes it doesn't.
+1 for being interested in something more purpose-driven, if it could get adoption.
The other nice effect is the use of the injector instead of the repeated list of dependencies.
When not using coffeescript in angular, I could see making good use of this. Thanks !
It was originally inspired by this gist: https://gist.github.com/elado/8138516
The biggest problem I see though is if you want to save a reference to the unregister functions of the $watch callbacks.
Otherwise, this is a cool idea, although it falls a little short.
This is a valid criticism, thank you. I will try to put together a nice solution for this.
Of course you can always register/de-register watchers the normal way inside of the init method.
No problem with Coffeescript.
module.controller 'MainCtrl', class
constructor:($scope,bar,baz)->
$scope.message="foo"
@$inject = ['$scope','bar','baz']
And then angular internals get updated and it breaks...