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

Polyfill support for __proto__ in IE <= 10 #439

Merged
merged 4 commits into from
Jun 23, 2017

Conversation

buschtoens
Copy link
Collaborator

@buschtoens buschtoens commented Jun 22, 2017

Fixes #436.

This gives full support for stuff like this in IE <= 10:

Table.reopen({
  getFirstColumn() {
    return this.get('columns.firstObject');
  }
});

Juicy technical details

MDN on Object.prototype.__proto__

Internet Explorer

Classes (10 and below)

If you’re inheriting from a class then static properties are inherited from it via __proto__, this is widely supported but you may run into problems with much older browsers.

NOTE: __proto__ is not supported on IE <= 10 so static properties will not be inherited. See the protoToAssign for a possible work around.

babel-plugin-transform-proto-to-assign

This plugin allows Babel to transform all __proto__ assignments to a method that will do a shallow copy of all properties.

Detail

This means that the following will work:

var foo = { a: 1 };
var bar = { b: 2 };
bar.__proto__ = foo;
bar.a; // 1
bar.b; // 2

however the following will not:

var foo = { a: 1 };
var bar = { b: 2 };
bar.__proto__ = foo;
bar.a; // 1
foo.a = 2;
bar.a; // 1 - should be 2 but remember that nothing is bound and it's a straight copy

This is a case that you have to be aware of if you intend to use this plugin.

@buschtoens buschtoens changed the title Poylfill support for __proto__ in IE <= 10 Polyfill support for __proto__ in IE <= 10 Jun 22, 2017
@buschtoens buschtoens force-pushed the 436-ie10-fix-proto branch 2 times, most recently from 34fa94d to 19e6ff9 Compare June 22, 2017 08:38
let col = new Column();
assert.ok(col.someMethod());
});

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not really sure, if these tests make a lot of sense, since we don't run CI tests for IE anyways.

Also, they mutate the Classes. This means that all following test cases have access to someStaticMethod and someMethod. This might not be a problem now (and I doubt it ever will), but it could and feels kind of dirty.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think, I should rather write a specialized unit test for utils/fix-proto. This way, there's no mutation of global classes.

@buschtoens
Copy link
Collaborator Author

There's now a dedicated test for fixProto, asserting that ES6 classes that extend Ember.Object can be reopened after fixProto was used on them.

The testes for Column, Row and Table now merely assert that reopen and reopenClass are functions.

All these tests are pretty meaningless though, as we don't test in IE <= 10. But now we could verify regressions quickly, if someone reports this issue again. 🤷‍♂️

@buschtoens buschtoens merged commit 3daf20e into adopted-ember-addons:master Jun 23, 2017
@offirgolan
Copy link
Collaborator

@buschtoens I think we should just move to pure Ember.Object in the next major release because this is kinda getting gross lol.

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.

None yet

2 participants