Angular Infinite Digest Loop with promise.then() - angularjs

Question

The problem: Using a this.promise.then(function(){}) function inside a controller method seems to create a $rootScope:infDig loop although the returned value of that method does not change. It's worth noting that the infinite digest loop is gone when removing the .then() line (see code).
The code:
{{ getSelectedProjects() }} in the view and the following method in the attached controller
var vm = this;
vm.getSelectedProjects = function() {
if (angular.isUndefined(vm.hello)) {
vm.hello = "hello"
vm.promise = $q.when("hello i am a resolved promise")
}
vm.promise //In my original code, this promise is returned by a service (MyService.getPromise()). The resolved value of the returned promise may change which is why the service needs to be called at each digest cycle.
.then(function (ans) {
vm.hello = ans;
}); //remove .then(...) function and there is no infinite digest loop anymore
return vm.hello;
}
The question: Why is this creating an infinite digest loop although the returned value does not change ? How can I avoid it (I badly need the result of that promise)?.
My shaky thoughts: I guess it has to do with the fact .then() each time returns a new promise. The documentation does not state it, but if that promise is each time attached to the controller object (vm), this might be considered as a state change of the controller and trigger a new digest loop, which re-evaluates vm.getSelectedProjects() and again attaches a new promise to the controller, etc.
EDIT
My hypothesis in "shaky thoughts" does not seem fully correct or complete, as the problem persists with this code:
vm.getSelectedProjects = function() {
if (angular.isUndefined(vm.hello)) {
vm.hello = "hello"
}
$q.when("hello i am a resolved promise")//this object is not attached to the controller object
.then(function () {});
return vm.hello;
}

Answer 1

Based on the problems encountered and the comments we created coding guidelines for working with promises in our project. Found it interesting to share it as I haven't seen this documented anywhere.
Coding guideline: Working with promises
Use of promises
Promises are amazing objects, however a wrong use can create headaches. Therefore we have a few guidelines :
Do not use promises in views
Do not use promises in controllers, except in functions called by event handlers (click, init, etc.), the controller construction function (=executed only once) or in animations
If a promise result is used in a view, the model (or the manager) should contain a property that is empty by default and set to the resolved value when the promise is resolved. The controller just returns that value.
Implementation
This is the kind of structure that should be in the model, manager, or other service, as close as possible to the data source. NOT in controllers :
var myApiMethod = function() {
//We call "caching" the fact that this method is executed only if $scope.item is undefined.
If (angular.isUndefined($scope.item) {
$scope.item = {}
$http(xxx).then(function(value){
$scope.item = value;
});
return $scope.item
}
}
The controller then just returns the answer of myApiMethod. You might need to check if 'myService.myApiMethod() != {}'.
In the service we can define a caching behaviour (ex: retrieve data from backend every 2 hours, at a certain event clear the cache, etc. ). As long as there is only one single source of truth (coming from the service in this case, not from the controller) concerning the object to be returned you can easilly play around with this.
Argumentation
*Why not to use promises in views or in controller methods called by expression evaluations (e.g., {{ vm.getMyApiMethodResult() }} *:
Including promises in views is a feature that has been desactivated in Angular 1.x
If myApiMethod is put in the controller without the caching and then used in an expression evaluation (e.g., {{ myCtrl.getMyApiMethod() }} ), it will create an infinite digest cycle, because the resolution of the promise will trigger a new digest cycle, that will again call the vm.getMyApiMethod() function, etc. (more info in this SO answer )
Why not put myApiMethod in t he controller with the caching (like implementation above) to make sure myApiMethod is called only once and avoid the infinite digest loop? Three reasons:
if the response of myApiMethod() changes into a new object, $scope.item will not be updated.
Another drawback of this (that we used a lot in the past, you might still see wrong implementations in the code) is that it creates a lot of duplicate code as we need to duplicate this quite heavy code structure (that can become much more complex when several promises are involved) in all controllers calling myApiMethod()
If you "cache" in the controller, you might end up with different controllers returning different answers although they both return the answer from the same service 'myApiMethod' but at different moments in time.
Remember : This guideline only applies to controller functions called in expression evaluations. You might need promises in controller functions called by event handlers (click, etc.) and that's fine because these functions are not called at each of angular's digest cycles.