You could walk the call stack where the error happens to see what the property is that is being set to clue you in as to where. But, it’s likely within a didInsertElement hook.
It’s frustrating when you have potentially a large number of components on the screen to figure out which didInsertElement hook is doing a set
Thanks for the tip, but looking though all steps in the stack trace doesn’t help much:
DEPRECATION: You modified each(listOrderBy) twice in a single render. \
This was unreliable in Ember 1.x and will be removed in Ember 2.0
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:71525:7)
at raiseOnDeprecation (http://localhost:4200/assets/vendor.js:71611:7)
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:71525:7)
at handleDeprecationWorkflow (http://localhost:4200/assets/vendor.js:71663:9)
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:71525:7)
at deprecationCollector (http://localhost:4200/assets/vendor.js:71685:5)
at HANDLERS.(anonymous function) (http://localhost:4200/assets/vendor.js:71525:7)
at invoke (http://localhost:4200/assets/vendor.js:71537:7)
at Object.deprecate (http://localhost:4200/assets/vendor.js:71616:5)
or do you see something that I missed?
I suspect that in my template somewhere a given parameter is being changed more than once, but there are alot to choose from.
Or I could be firing off more than one bounded function properties?
To investigate this, I set a breakpoint at the only place where I’m call this.set('listOrder') and I see that it’s only reached once, sometimes not all all, but the deprecation message is still being generated.
We’ve had this a bit in our app with upgrading to Ember 2.x. There are two primary things that seem to cause this (for us):
A prior crash in the runloop (before the rendering cycle).
Modifying a property on a component in the didInsertElement hook and that property causes changes to something bound in the template.
I know this isn’t really helpful. One thing you could try is setting a breakpoint where the expectation is actually raised. I’ve found that part of the stack is usually helpful because it usually has the set call that trigger it in the stack.
Also set break point where the deprecation is being raised, but because it is in the run loop it’s impossible for me to know what and when that was put there previously.