I'm still not convinced about Angular's Dependency Injection thing. The problems it allegedly solves don't clearly outweigh the ones it certainly creates.
It claims to provide concern isolation, which facilitates testing and cleanliness. I don't think it helps that much.
But it has a middle-stage learning curve, more callbacks than I'd like, and implicitness of dependencies. For example, i.e. you need to know what $scope-like params are "supposed to contain" on every function that uses them.
Also, I find the naming spotty: "directive", "module", "injector", "compile" etc. lack specificity. They are not as bad as "Manager", "Data", "Info" and "Object", but they are not good.
For example, i.e. you need to know what $scope-like params are "supposed to contain" on every function that uses them.
You should never write code that communicates through $scope objects and expects certain values to be set. The only exception to this is the relationship between views and their respective controllers.
Outside of the controller-view relationship, nothing in AngularJS requires passing data in $scope objects, and you definitely shouldn't.
Why do you think dependency injection doesn't help exactly? I personally don't know of any other pattern to effectively test/mock things like HTTP interactions. It's also a pattern that's used by many, many other languages and frameworks - what's the alternative you're thinking about?
> The only exception to this is the relationship between views and their respective controllers.
My point exactly. The relationship between views and controllers is important. Using $scope there is sucky (also, its name is too generic).
> Why do you think dependency injection doesn't help exactly?
I think that dependency injection helps, and I use it all the time. I just don't like Angular's take on it.
It relies too much on anonymous functions. I think that 'new' (or equivalent) and 'globally accessible glasses or factories' (or equivalent) are just fine in lots of cases. They make the dependencies implicit, yes, but that's secondary to the fact that the code is much more readable.
It claims to provide concern isolation, which facilitates testing and cleanliness. I don't think it helps that much.
But it has a middle-stage learning curve, more callbacks than I'd like, and implicitness of dependencies. For example, i.e. you need to know what $scope-like params are "supposed to contain" on every function that uses them.
Also, I find the naming spotty: "directive", "module", "injector", "compile" etc. lack specificity. They are not as bad as "Manager", "Data", "Info" and "Object", but they are not good.