You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a property has been accessed directly on the prototype of a Construct object, further sets of that property will change both the instance on which the property is being set and the prototype. The result is that future instances of the Construct type will have the new value as the default value of that property.
Thanks for posting this. Can you share an example of this happening with "normal" code?
The issue with this example is that one shouldn't really access the prototype properties like:
Test.prototype.title
As this will invoke the title getter on the prototype and mess things up. The title getter MUST be on the prototype for can-define to achieve it's fast performance using "lazy" evaluation. (read more here)
By "normal" code, I'd like to see how this property is being read in your app. Are you reading from the prototype directly? If so, why?
The text was updated successfully, but these errors were encountered:
@RyanMilligan commented on Mon Jul 30 2018
How often can you reproduce it?
After a property has been accessed directly on the prototype of a Construct object, further sets of that property will change both the instance on which the property is being set and the prototype. The result is that future instances of the Construct type will have the new value as the default value of that property.
Steps to reproduce:
Expected results:
Both lines that start with "Default title" should have the default value ('test').
Actual results:
The second "Default title" line displays the title that was set on the middle object because the prototype has been changed.
If you remove the "Prototype: " line, then the issue will not reproduce and you'll see the expected results.
Environment:
@justinbmeyer commented on Mon Jul 30 2018
Thanks for posting this. Can you share an example of this happening with "normal" code?
The issue with this example is that one shouldn't really access the prototype properties like:
As this will invoke the
title
getter on the prototype and mess things up. Thetitle
getter MUST be on the prototype for can-define to achieve it's fast performance using "lazy" evaluation. (read more here)By "normal" code, I'd like to see how this property is being read in your app. Are you reading from the prototype directly? If so, why?
The text was updated successfully, but these errors were encountered: