cerialize: Error: decorator is not a function

When I try to use the @deserializeAs(Type) it fails with the error:

decorator is not a function

Code:

export class User {
    @deserialize id: string;
    @deserialize firstName: string;
    @deserialize lastName: string;
    @deserializeAs(Address) address: Address;

    displayName(): string {
        return this.firstName + ' ' + this.lastName;
    }
}

export class Address {
    @deserialize city: string;
    @deserialize country: string;
}

Any ideas?

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 1
  • Comments: 20 (10 by maintainers)

Most upvoted comments

I agree if this were possible it would be a great thing to have. Unfortunately, this is a JS problem and not a library one. The problem is that at parse time whichever one of your classes is parsed second, will not exist at the time the first one is parsed. C/C++ gets around this with forward declarations, C#/Java just have multi pass compilers that are smart enough to figure this out. Because JS is interpreted on the fly (ignore code generation for now), this is going to be a problem.

I’ll have to think about how to work around this

The problem was that I had an attribute referencing a type that was declared below in the same source file. Doh.

See my last comment on the issue here: https://github.com/rbuckton/ReflectDecorators/issues/29

This cannot work with annotations unless the library were written to handle some sort of async type loading. No matter what order you put things in either Workspace or Account will be undefined at the time the other class decorators are run, there is no way around that. The only way to make this work is to implement some other Api that can be run in a Serialize/Deserialize hook to re-gather the decorators.

You still have the circular reference problem, which you cannot solve without a custom json schema that can support value lookups for other keys in the json file {account: "Some Id defined elsewhere in your JSON"}, which is out of scope for this project and probably not even a great idea. You’re better off implementing an OnSerialize() method that will write an Id in the workspace’s account field instead of a serialized account instance or vice versa. Your backend will have this same circular reference issue so you’d need to solve it there as well in a similar manner.

TLDR: Circular references are going to be an issue for you even if it were possible to do what you are trying to accomplish. I’d recommend either 1.) Don’t serialize workspaces as part of account, use ids instead. 2.) Don’t serialize account as part of workspace, use ids instead.