Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

$injector cannot instantiate ES6 classes #12597

Closed
mprobst opened this issue Aug 17, 2015 · 1 comment
Closed

$injector cannot instantiate ES6 classes #12597

mprobst opened this issue Aug 17, 2015 · 1 comment

Comments

@mprobst
Copy link
Contributor

mprobst commented Aug 17, 2015

This code (paraphrasing) fails with TypeError: Class constructors cannot be invoked without 'new':

class Foo { constructor() { } }
var foo = $injector.instantiate(Foo);

The reason is that ES6 disallows using fn.apply on class constructors.

@Narretz Narretz added this to the Backlog milestone Aug 21, 2015
klausw added a commit to GoogleCloudPlatform/PerfKitExplorer that referenced this issue Sep 30, 2015
This doesn't currently work right since Angular illegally calls
the constructor via apply() without "new". Known Angular issue:

angular/angular.js#12597
klausw added a commit to GoogleCloudPlatform/PerfKitExplorer that referenced this issue Oct 1, 2015
This doesn't currently work right since Angular illegally calls
the constructor via apply() without "new". Known Angular issue:

angular/angular.js#12597
@bisubus
Copy link

bisubus commented Oct 20, 2015

@mprobst I've encountered the similar issue before and ended up by splitting the solution into separate extension, ng-classified.

Just have checked #12598, I have a feeling that patching up instantiate is halfhearted job, it will just affect performance by propagating new everywhere and not targeting the classes. And other things that could benefit from classes will still get their TypeErrors (the world is bigger than controllers).

It is evident that I've managed it more drastically, it is $injector.invoke which is primarily responsible for calling class constructors directly. And I consider it the right idea to fix it there because it is a great opportunity to pull up mature 1.x to fit contemporary expectations (particularly excited by Angular 2) by using DI-enabled classes everywhere where 1.x would expect constructor functions, without breaking anything.

It's not that simple, what's good for extension, is bad for framework. Due to the fact that only Chrome/V8 native class implementation can be easily detected (even FF native classes appear as functions for now), I've had to introduce some conventions and add flag checks to avoid trying-catching TypeErrors on every invoke.

Is it acceptable to make $injector configurable on framework level? I'm not sure at all. But I think it is inevitable to provide some degree of configurability to deal with classes in future-proof manner while keeping the performance high for classless apps.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants