Hacker News Reader

Comment by cheriot | Hacker News Reader

It's a well done write up and a great tutorial. I wouldn't use it as a source of best practices, though. The controllers are huge and interact with $http. And I can't think of a reason for a variable named "globalVariable" with a random set of attributes. The entire point of Angular's dependency injection is to avoid that.

View on HN

Yes Cheriot, you're probably right but we wanted to keep it easy to understand. How would you change it? Happy to improve it and make it more "best-practice" compliant and then share it here https://github.com/Stamplay/stamplay-foodme

I disagree with the OP,in a system with dependency injection,it doesnt matter where the injected stuff comes from,only the fact that they are injected is important.

You could have 20 services instead of one it would not make any difference. Since the details and dependencies of the services are encapsulated. I would,however separate the modal methods from the config variables, as it's 2 different concerns.But the rest is totally fine.

It's a matter of opinion beyond that, there are no "best-practices",other than the fact that one should not use any data that is not injected somehow , in a controller.

Same for $http.Of course one might want to abstract some business logic as the application grows,because at some point one might need to do complex stuffs when it comes to api calls(validation,...) but YAGNI over DRY. The code is still testable.

Again the only thing one should NOT do in a controller is DOM manipulation,beyond that anything goes.

I'd say you shouldn't pollute your controller with too much non-UI specific logic - oftentimes, it's worth splitting off some controller logic that is heavy into a service to test it in a more managable fashion & confine the messiness away from the controller.

When there are no authorities, there are no compliance issues :) The roll of controllers and link functions isn't to hold logic, it's to wire things together between the scope and services/models. For example, having a userStatus.getUserCall() is a step in the right direction. Now have the service check the response code and use the user data to create a single user object that can be returned/resolved. So your controller becomes userStatus.getUserCall().then(function(user) { $scope.user = user; }) or since angular templates are promise aware, you can reduce it to $scope.user = userStatus.getUserCall(). Now the NavbarCtrl and the MenuCtrl only need to share that one line rather than ~10!

Reply on news.ycombinator.com