moment.js and scope.$watch when objectEquality is true

[danielgatis]

Hi,
I have a object that have a moment.js property like this:

obj = { date: moment(), status: 'ok' }

so if i watch this object with objectEquality like this:

scope.$watch('obj', ..., true); 

i get this errors:
Error: [$rootScope:infdig] 10 $digest() iterations reached. Aborting!

To fix this i need to override angular.equals function to compare momentjs objects correctly.

function equals(o1, o2) {
  /* patch for moment */
  if (moment.isMoment(o1) && o1.toString() === o2.toString()) return true;
...
}

What is the best way to do this?

thanks.

[caitp]

It's not the angular equals function which is causing infinite digests --- these will happen when the actual value being compared changes too many times per digest cycle (sometimes called "model instability")

An example can be seen at http://plnkr.co/edit/AFnZYW403P4SN2xAvkWw?p=preview which intentionally modifies the value every time the $watch fires --- commenting out one of the two assignments in the $watch function will prevent from throwing.

[danielgatis]

ok, but look at this example (http://plnkr.co/edit/rYxlCM?p=preview) no assignments happens in the $watch function and still throwing an error.

[heikki]

Workaround without objectEquality: http://plnkr.co/edit/MjFelt?p=preview

[caitp]

ok, but look at this example (http://plnkr.co/edit/rYxlCM?p=preview) no assignments happens in the $watch function and still throwing an error.

No, interpolated expressions in text nodes are actually separate $watches --- In the case of this one in particular, it is actually executing an expression which evaluates to a new object every single time it is called. This, quite understandably, causes an infdig error to be thrown. The first $watch in your controller does not cause any problems, it is the {{moment.format(...)}} which does.

A good work-around for your issue is to write a filter for your momentjs needs, it's a very simple thing to do.

angular.module("moment", [])
.filter("time", function() {
  return function(input) {
    if (input instanceof Date) {
      return moment(input).format('hh:mm:ss')
    }
  }
});

like so

<p>{{ theDateInQuestion | time }}</p>

It's a pattern which works nicely

[danielgatis]

@heikki
so clever

@caitp
Ok I got it. But how I will show it without interpolation?

[caitp]

As stated, you can use filters, this is really what they're meant to do --- transform input in some fashion (such as formatting a date). The filter chain won't cause an infdig error, and can be used very cleanly in any angular expression. They're good things to use

[danielgatis]

ok! thanks

[heikki]

The first $watch in your controller does not cause any problems, it is the {{moment.format(...)}} which does.

@caitp Are you sure about that? Removing the binding from the view still gives errors. I think the real reason is that angular objectEquality check doesn't work for moment object.

http://plnkr.co/edit/ejMlOT?p=preview

[caitp]

Moment objects are nothing special, they are just objects (Which happen to contain a Date, which is treated specially by angular.equals())

The cause of infdig errors is, a $watched expression returns a different result each time it fires (if it does this, it is triggered again, and again, and again, etc...) --- The maximum allowed number of tries is (by default) 10, so it doesn't take very long for it to throw.

You can see filters used to circumvent this in both of the examples I've posted.

Here's another one: http://plnkr.co/edit/MjNWFI?p=preview

---

Hmm, actually I retract that statement, it seems to end up with newval being a simple object, and oldval being the actual Moment instance --- So perhaps $watch does have issues with new'd objects.

Regardless, there are certainly ways to work around it (one being, simply store a Date object rather than a Moment)

EXCEPT, the first example uses the objectEquality flag watching a Moment object, and does not suffer from this issue: http://plnkr.co/edit/AFnZYW403P4SN2xAvkWw?p=preview

So, maybe I need to study your example closer. At any rate, there are ways around this which don't require silly hacks.

Use filters! It's what they're there for.

[dobladez]

Here's you last referenced example, with the only change that the moment instance is stored in $scope.model.moment instead of $scope.moment, and the deep watch is set on model: http://plnkr.co/edit/RSGc9b5WZJgRRccBQn2k?p=preview

This happens even if you don't even use the moment attribute in your template... it's purely an issue with angular's copy() and equals() behavior with MomentJS. The root of this, it seems, is that angular.copy() does not preserve the objects' prototype: #5063

Thanks!

[dcartwright]

I was just tripped by this bug as well, it's still present in 1.3.0 beta 5. I patched my copy of angular.js using the fix in #5063, as suggested by @dobladez, and that resolved the issue. In my opinion, this issue should be re-opened until #5063 is landed (if it is).

[danielgatis]

In my opinion, this issue should be re-opened until #5063 is landed (if it is).

I agree

[gentooboontoo]

I am waiting for instructions if I should make #5063 backward-compatible with branch 1.2.x (and with IE8).