Repository navigation
loading, declaration and execution phases of modules and cyclic references problem ? #7282
Description
This question is related to TypeScript, ES6, SystemJs and ReflectJs specs, but I would like to know your thoughts about it.
So for a function declarations the sequence of code is not important, but for classes it is:
Example with single module
console.info(fnc()); // this is fine
console.info(new Cls()); //TypeError: Cls is not a constructor
function fnc(){
return "value"
}
class Cls {
constructor(){
//...
}
}A more complex example when classes located in different modules and have cross references in declaration phase like:
Example with multiple modules and static references
// one.ts
import {Two} from "./two"
class One {
static two = new One();
}
// two.ts
import {One} from "./one"
class One {
static two = new One(); //TypeError: One is not a function
}
//main.ts
import {One} from "./one"
import {Two} from "./two"
console.info(One.two)
console.info(Two.one)so this is throwing error when trying to create One instace, the expectation is to have One declared at the time of exection .
This can be hacked by using some cached getters, which can be somehow used to solve the main problem in runtime(loader) :
// cached.ts
export function Cached(target,key,desc){
var initializer = desc.get;
desc.get = function(){
return Object.defineProperty(this,key,{
value:initializer()
})[key];
};
return desc;
}
// one.ts
import {Cached} from "./cached";
import {Two} from "./two";
export class One {
@Cached
static get two():Two{
return new Two()
}
}
// two.ts
import {Cached} from "./cached";
import {One} from "./one";
export class Two {
@Cached
static get one():One{
return new One();
}
}
//main.ts
import {One} from "./one"
import {Two} from "./two"
console.info(One.two)
console.info(Two.one)I have prepared some demo to show hack on this problem, you can see bellow
Expected behavior:
Create and instance of Cls and out put it without errors.
Actual behavior:
Throws a TypeError because of undeclared class
Example of cyclic references problem in decoration phase
The other example is annotators cyclic references problem.
function Model(target){}
function Collection(target){}
function Field(target:any,key:any,desc?:any):any{
var type:any = Reflect.getMetadata("design:type",target,key);
document.write(`<pre>${target.constructor.name}.${key} : ${type?type.name:"<span style='color: red'>UNDEFINED ?</span>"}</pre>`);
}
@Model
export class User {
@Field id:String;
@Field name:String;
@Field projects:Projects; // Project Is not defined yet
}
@Collection
export class Users extends Array<User> {}
@Model
export class Project {
@Field id:String;
@Field name:String;
@Field author:User;
@Field contributors:Users; // Users will not be defined
// if we will change definition order
}
@Collection
export class Projects extends Array<Project>{}I think this is IMPORTANT because Dependecy Injection (java guice), ORM's or Serialization frameworks will use this feature deeply, and user code can contain cross referenced types.
So the main reason for this problem is that declaration, decoration and execution phases of classes mixed in output.
// decoration inside execution block and part of class declaration
__decorate([
Field,
__metadata('design:type', Projects)
], User.prototype, "projects", void 0);Potencial hack for this can be generate closure instead of direct type referance in metadata like:
__decorate([
Field,
__metadata('design:type', function(){return Projects})
], User.prototype, "projects", void 0);which can be adjusted after module execution, but I think this is just a hack, and the right way will be finnaly define
specification about Loading > Declaration > Annotation > Decoration and Execution phases of runtime which will support cyclic references.
Any thoughts ?
PS: AND AGAIN THANKS FOR TYPESCRIPT :)
Activity
DanielRosenwasser commentedon Feb 28, 2016
Sergey Mamyan (@casser) so I'm having a hard time reading through this post and finding the question 😄 - can you clarify what exactly you're asking here?
casser commentedon Feb 29, 2016
I just realize that links was broken, sorry :)
Question: Examples above are bugs or expected behaviors ?
Expected behavior:
Actual behavior: Demo
Expected behavior:
Actual behavior: Demo
Look At this repo for sources
DanielRosenwasser commentedon Feb 29, 2016
Ah, gotcha. Ron Buckton (@rbuckton) would know a lot better about the decorators. Though, is #4114 related?
As for using a class before its definition, yes, we should be reporting an error. See #21, #4341, and #5207. Apparently there was a fix out for it, but it was never taken in (#4343). Mohamed Hegazy (@mhegazy) what's going on with that?
mhegazy commentedon Feb 29, 2016
#5207 is the correct issue tracking this change
rbuckton commentedon Feb 29, 2016
This is a known issue with the
--emitDecoratorMetadataswitch, and your proposed solution is exactly what we have discussed as the resolution. Regardless of "use before definition" type errors, using--emitDecoratorMetadatawould still emit JavaScript that will result in an error in ES6 unless we wrap the metadata values in a function.pie6k commentedon Oct 30, 2017
Any solution to this? How can I wrap values of metadata in a functions?
It's very blocking for any project with decorators that have circular references.