This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Deep Watches up the prototype chain no longer fire #8040
Description
This is due to a change in the semantic of angular.copy at b59b04f.
The problem with deep watches is that oldVal is created by copying newVal but now both have the same prototype and so if a value on the prototype changes both oldVal and newVal change together so it is not possible to trigger a watch handler.
See the following two plunks:
At master : http://plnkr.co/edit/NUDQR9ZqYLi8kreoLcrk?p=preview
At 1.3.0-beta-13 : http://plnkr.co/edit/3cappcs8WVjBM6X1vsRn?p=preview
Activity
petebacondarwin commentedon Jul 1, 2014
One solution would be to create a new
flattenedCopy()function that is only used in$watch...gentooboontoo commentedon Jul 2, 2014
@petebacondarwin what do you think of 3b9656c? It's a quick proof of concept to try your idea, not sure if this is the right way to do it. Current tests still pass. I have to make a specific test based on your plunks.
petebacondarwin commentedon Jul 2, 2014
It looks pretty good. One question is where else this has an impact. At least it would also provide a migration path in case anyone was using the old
copyand expecting this flattening behaviour.myitcv commentedon Jul 2, 2014
What problems does this create out of interest? Were there test breakages as a result of b59b04f?
I can't actually foresee a situation where I would want to change the prototype (admittedly I'm coming from a background of prototypes being used almost exclusively for classes in CoffeeScript) after object creation.
IgorMinar commentedon Jul 2, 2014
upon further discussion it seems that this is not a a problem in real world scenarios as far as we are aware. closing..