Returning cloned data from a service model fails with infinite recursion

[MihaiValentin]

I've got a service that acts as a model. In order not to expose the internal variable that holds data and make it by mistake modifiable by reference, when I return it, I do a angular.copy.

If the internal variable contains only primitives, that's fine. But if it contains also objects, it's not (I get 10 digest error).

Here is the fiddle: http://jsfiddle.net/aFBkP/1/

[Narretz]

Here's why: #705

In short, using functions to return the collection in ng-repeat is an anti-pattern. It's better to assign the collection to a scope property, and loop over that.

[MihaiValentin]

Thanks, but what if I don't want the data to be overwritten from outside? For example preventing someone from doing:

$scope.m.getItems().x = 7;

[Narretz]

You can still use $scope.data = model.getItems() where model.getItems() returns a copy of the data. What do you mean by overwritten? By the user in the ui, like an input?

[caitp]

👍 Narretz, might be good to link to the documentation for the digest loop so they get a better understanding of the cause of the issue.

[MihaiValentin]

Of course, adding a scope variable is fine, but I'd much rather prefer do use the model itself to do this.

I could just return data from my model, but then the following thing may happen: $scope.model.getItems()[0].x = 5;, while I would prefer to set data to it using setter methods.

Of course I control the whole application and I'll be careful not to do this, but it's just about the fact that returning the internal data through a get function automatically makes it susceptible to writing operations.

I was only curious if there is a way around this, that's all.

[tbosch]

A getter should not change the data it is using, it should be indempotent.

A better way would be to only clone the data when you are modifying it and keeping the clone in a separate field.

Won't implement this, sorry.

[xtofl]

Darn - I found it amazing that ng even supported binding to $scope functions... In fact, not allowing this enforces tight coupling:

$scope.allvalues = [{x:1}, {x:1}, {x:2}];
$scope.uniqueValues = function(){ 
   return [{x:1}, {x:2}];  /*would normally be calculated from allvalues*/
 };

If I want an ng-repeat="val in uniqueValues()", I have to make sure that each time I change allvalues, I also update the uniqueValuesArtificialProperty... kindof reimplementing data-binding alltogether, not? While in fact, the uniqueValues function is 'idempotent' in that it's output 'means the same' time and again.

This has to happen for all functions that change allvalues - isn't that an antipattern?...

Binding to functions being an antipattern, is there another pattern I could use instead?

[caitp]

You don't need tight coupling to keep the scope value in sync with the service, you can use $watch with the objectEquality flag set to true. However this would make the dirty checking much more expensive, so this is potentially a bad thing to do.

[xtofl]

Thanks for the $watch hint. It lead to a possibly more performant way to do this. Watching the input properties with an update-output-property function. Indeed the $watch reduces coupling, and allows to keep the inputs/output definitions close to one another.

var expression = function(prop1, prop2){ 
    return expression of prop1 and prop2;
};
var updateCalculatedProp = function(){
    $scope.calculatedProp = expression($scope.prop1, $scope.prop2);
}
$scope.$watch("prop1", updateCalculatedProp);
$scope.$watch("prop2", updateCalculatedProp);