Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUGFIX beta] allow watching of ES5+ Getter #12491

Merged
merged 6 commits into from
Jan 21, 2016

Conversation

stefanpenner
Copy link
Member

Before this commit MandatorySetter enabled + current property being watched
resulted in get always fetching via meta.values. Although this typically works,
the default getter for a MandatorySetter already does this, so it is actually redundant.

Going further, when a user defines their own getter this code-path is incorrectly taken,
instead the original value (which originated from the getter) should be the consulted value.

This is blocking an ember-data fix, and likely causing grief for users who use ES5 getter/setters mixed in with our templates.

cc @krisselden

@rwjblue
Copy link
Member

rwjblue commented Oct 16, 2015

Looks great! Can you add a test to https://github.com/emberjs/ember.js/blob/master/packages/ember-metal/tests/accessors/mandatory_setters_test.js also?

I think this should likely be bug fix beta to allow for our normal beta testing cycle.

@stefanpenner
Copy link
Member Author

I think this should likely be bug fix beta to allow for our normal beta testing cycle.

This is breaking things in dev mode, and doesn't do anything radical to solve the issues. That being said, it may not be a critical fix on-our end.

@bmac is it alright if ember-data doesn't get this solution till 2.2?

@rwjblue
Copy link
Member

rwjblue commented Oct 16, 2015

is breaking things in dev mode, and doesn't do anything radical to solve the issues. That being said, it may not be a critical fix on-our end.

Yup, I understand that the bug exists in previously released versions (not just beta). Unless things are fundamentally broken in the wild (which would likely result in a large uproar) we should err on the side of using the normal beta process. This change is deep in the internals and a mistake in this area has the ability to cause massive issues that we may not be able to predict (we have had a number of [BUGFIX release] changes come back to bite us in the backside). Thankfully, this is exactly why we have a beta cycle.

@stefanpenner
Copy link
Member Author

@rwjblue yup just stating facts & checking with @bmac to see if this is critical or not to ed. If it is not, its good to go on beta.

@stefanpenner stefanpenner changed the title [BUGFIX Release] allow watching of ES5+ Getter [BUGFIX beta] allow watching of ES5+ Getter Oct 17, 2015
@stefanpenner
Copy link
Member Author

  • fix more stuff, our tests here aren't very good..

@bmac
Copy link
Member

bmac commented Oct 17, 2015

@stefanpenner this functionality is not critical for Ember Data. We shipped a work around for this issue in 2.1 so we can refactor the workaround away in a future release when Ember's support improves.

@stefanpenner stefanpenner force-pushed the fix-es5-watched-getter branch 2 times, most recently from e7c98e5 to 5c81e5e Compare October 18, 2015 15:00
@stefanpenner
Copy link
Member Author

@bmac I think this addresses everything I could think of, if you have time to confirm on your end that would be good.

––––

Turned out, as I worked on this I realized many other things were funky. I suspect this code can continue to be improved.

@rwjblue r?
@krisselden r?

@stefanpenner
Copy link
Member Author

  • b66a13f removed keys_test and moved them, I added some to that file, i should move them aswell

@mixonic
Copy link
Sponsor Member

mixonic commented Oct 18, 2015

So many new tests 👏

@stefanpenner
Copy link
Member Author

Test failures seem related to phantom, will investigate soon

@@ -38,6 +41,16 @@ export function DEFAULT_GETTER_FUNCTION(name) {
};
}

export function INHERITING_GETTER_FUNCTION(name) {
function IGETTER_FUNCTION() {
var proto = Object.getPrototypeOf(this);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me (just off the bat) that we need to do the same thing as was added in #12314 to lookup the getter through the entire prototype chain. As it exists here, I believe that a getter from a parent class will not be found.

Specifically, I think we should use lookupDescriptor, and add some tests around this behavior like these ones only for getter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so, this exists to simulate the behavior if no descriptor existed at this level. It aims to re-target get one step up the prototype chain.

In-case i mis-understood, here are the relevant tests (which may explain better when this aims to do then I can), -> Related tests->: https://github.com/emberjs/ember.js/pull/12491/files#diff-25946da80206a01a2f680ad806bb1780R370

Let me know if im not crazy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wait i believe i see it now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding another test

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a test, will investigate another time (time for bed)

@stefanpenner
Copy link
Member Author

After chatting with kris, he had a good idea, installing the mandatory setter for inherited properties in at the level defined (instead of at the leaf). Will explore this.

Before this commit MandatorySetter enabled + current property being watched
resulted in `get` always fetching via meta.values. Although this typically works,
the default getter for a MandatorySetter already does this, so it is actually redundant.

Going further, when a user defines their own getter this code-path is incorrectly taken,
instead the original value (which originated from the getter) should be the consulted value
* no longer rely on meta to store the value until next set after uninstalling MandatorySetter
* no longer incorrectly re-set on set to enumerable (enumerability should remain constant)
* test both enumerable / non-enumerable variants
@stefanpenner stefanpenner force-pushed the fix-es5-watched-getter branch 5 times, most recently from f12c519 to 3a522ca Compare January 10, 2016 23:53
@stefanpenner
Copy link
Member Author

@rwjblue @krisselden r?

@stefanpenner
Copy link
Member Author

I don't believe the IE9 failure is critical, but I will investigate it once I have IE9 handy. It appears to just be a IE9ism, and very specific tests one my part. I just need to go with IE9 and see how it handles this edge case and update the tests accordingly.

@stefanpenner
Copy link
Member Author

IE9 issue is fixed in my VM, lets see what sauce thinks.

@stefanpenner
Copy link
Member Author

@stefanpenner
Copy link
Member Author

It is worth noting, this will make development builds of ember run slower (but will leave prod builds the same). Unfortunately short of either taking a drastically different approach, or disabling mandatory setter entirely, I'm unsure of another approach.

It is possible for us to explore micro-related improvements, but...

stefanpenner added a commit that referenced this pull request Jan 21, 2016
[BUGFIX beta] allow watching of ES5+ Getter
@stefanpenner stefanpenner merged commit 2e7991e into emberjs:master Jan 21, 2016
@stefanpenner stefanpenner deleted the fix-es5-watched-getter branch January 21, 2016 19:17
@homu homu mentioned this pull request Jan 21, 2016
6 tasks
tricknotes added a commit to tricknotes/ember.js that referenced this pull request Feb 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants