Typescript: [New Feature] Initialize Classes by Using an Object Initializer

[mribichich]

Hi there, I come from a C# background and it has something great call Object Initializer. Which allows you to initialize an object inline, without specifying the object everytime.

C# docs:
https://msdn.microsoft.com/en-us/library/bb397680.aspx

I would be cool if the compiler could do something like this:

new MyClass { Field1 = "ASD", Field2 = "QWE" };

[RyanCavanaugh]

C# needs this because it doesn't have object literals, but JavaScript doesn't have that problem. MyClass should be defining an appropriate constructor if this initialization pattern is common.

class MyClass {
  constructor(initializers: ...) { ... }
}

var x = new MyClass({field1: 'asd', 'field2: 'fgh' });

[mribichich]

Ok I understand that, but I'm not suggesting to do it for the same reason, but it would be cool for fast initialization.

In your example it makes you have a constructor and a mapping inside.

But what I'm suggesting, the compiler would do it for you.

[kitsonk]

What about for all the people who don't want you to break their object constructors? What solution do you propose for them?

[OlegDokuka]

If they want their object constructor, they should use it, but just imagine how it would be cool if compiller would help you to build the object like in C#. Even groovy support this feature.

It is easier way to initialize object with intellisense supporting where when you type the word you get some hint, if property exist, of course .(like in C#).

Today when we initialize interface we get some hint of property that exist in this interface, and, I think, everyone say "It is cool", and what happens when object can be installed with similar way?

Back to the @kitsonk answer. This feature just syntaxis shugar, and user that want to use object mapping in their constructor should choose the way that they want, and that is all.

Thanks!

[DanielRosenwasser]

I'll also point out that the production for this would necessitate that the open curly brace be on the same line due to ASI rules.

For instance:

new Foo
{
    bar = 10
}

The above is a new-expression followed by a block statement body.

[CyrusNajmabadi]

@DanielRosenwasser Is correct. But i would not consider this an ASI issue. The concern here would be syntactic ambiguity. What was unambiguously a specific construct in ES6 could now have two meanings if we introduced a production like this. If we did really want this, we'd likely need something very syntactically unambiguous to avoid these problems.

Also, see https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
This violates our goal of "Avoid[ing] adding expression-level syntax."

[DanielRosenwasser]

Yes, I don't consider there to be an issue with ASI, I consider this to be an easy pitfall for users.

[RyanCavanaugh]

Maybe we need a label for "This is a nice idea to bring to ESDiscuss" :wink:

[OlegDokuka]

wooooohoooo!)))

[OlegDokuka]

May be it is possible to add special rule to compiler. As I understand correctly, the main problem is that the JS ASI provide a cause for this syntax, but I point on that TS convert to JS and JS syntax is just a part of TS.

[cervengoc]

I would like to +1 this idea. When I have a simple class with many properties and some methods, etc., I would love to have the initializer syntax.

Some wrote that it's possible using interfaces. But now I use a class with methods in it, so I cannot just switch to interfaces. And I don't want to repeat myself by declaring a completely identical interface with all the members being optional.

Here I've read that the solution is to introduce a specific constructor, but that's also not a nice way, because that would use an "implicit interface" for parameter typing, and at the end I would still repeat myself.

some claims that it's only a syntactic sugar. But allowing for example template string for ES5 is a kind of syntactic sugar too IMO.

Also, constraining the opening brace to be at the same line doesn't sound like a very big deal.

[TylerBrinkley]

I know this is a closed issue, but it's something I'd very much like to see for my code gen situation where I cannot simply switch to using interfaces or add a new constructor.

[dolanmiu]

What about this?

http://stackoverflow.com/a/33752064/3481582

var anInstance: AClass = <AClass> {
    Property1: "Value",
    Property2: "Value",
    PropertyBoolean: true,
    PropertyNumber: 1
};

[avonwyss]

I know it is closed, but I ask to reconsider and I'm also +1 for this feature - because there are at least two cases where this is not just syntax sugar as far as I can tell.

Example with Function:

interface Foo {
    bar: any;
    (): void;
}

// how to create a Foo?
var foo: Foo;
foo = () => {}; // cannot convert type ... has non-optional property bar which is not present
foo.bar = "initialized!";

Example with Array:

interface Foo<T> extends Array<T> {
    bar: any;
}

// how to create a Foo?
var foo: Foo<any>;
foo = []; // cannot convert type ... has non-optional property bar which is not present
foo.bar = "initialized!";

Having object initializers like C# has would allow these to be handled in a typesafe manner without having to use an any cast and thus losing the check that all mandatory properties of these instances have been added/assigned a value.

[TylerBrinkley]

Sorry @dolanmiu, I didn't see your post until just now. The problem with that solution is that the constructor is never called. I'm using TypeScript to generate json as input to Json.NET and my constructor guarantees that important type information is serialized, eg. the $type field.

[RyanCavanaugh]

// how to create a Foo?

No need for any:

var foo: Foo;
foo = (() => {}) as Foo;
foo.bar = "initialized!";

You could do something like this, which ensures you pass all required properties:

function mix<T, U extends {[k: string]: {}}>(func: T, properties: U): T & U {
    Object.keys(properties).forEach(k => (func as any)[k] = properties[k]);
    return func as T & U;
}

var foo: Foo;
foo = mix(() => {}, { bar: 'initialized'});

[avonwyss]

Thanks Ryan for the suggestion. Whether any or Foo is used in the cast was not my point, but the fact remains that it does need a cast and after that the type safety is no longer warranted for (e.g. TS assumes that the properties are there, but they may be missing at runtime).

I'll try out the mix approach; reading the code here makes me realize that it should work thanks to duck typing but I'll have to see if it does actually do what I need.

[MeirionHughes]

here is my solution: http://stackoverflow.com/a/37682352/1657476

Just have a all-optional fields parameter on the constructor:

export class Person {
    public name: string;
    public address: string;
    public age: number;

    public constructor(
        fields?: {
            name?: string,
            address?: string,
            age?: number
        }) {
        if (fields) Object.assign(this, fields);
    }
}

usage:

let persons = [
    new Person(),
    new Person({name:"Joe"}),
    new Person({
        name:"Joe",
        address:"planet Earth"
    }),
    new Person({
        age:5,               
        address:"planet Earth",
        name:"Joe"
    })
]

I think its a simple and effective work-around.

[grofit]

I like it being more like the c# approach where you do not have to write any additional boilerplate, and for a lot of POJOs where you basically just want to pre populate some fields then add other stuff later via API callbacks etc you have the flexibility to do so.

Like for example if I was to do:

export class Person
{
   public name :string;
   public address: string;
   public age: number;
}

Then I wanted to populate various parts I could do:

// Populate name and age
var person = new Person {  name: "foo", age: 10 };

// Which is basically the same as
var person = new Person();
person.name = "foo";
person.age = 10;

However if you do have a custom constructor you can run that instead or as well as, basically I would just want to remove the common boilerplate where you end up having to have really verbose constructors full of optional params and the need to new up and then allocate the next N lines to myInstance.property = someValue;.

So making the c# style object initializer just act like a shorthand for manually applying the fields individually that alone would save time and yield benefits to developers.

[aluanhaddad]

@grofit how dies @MeirionHughes preclude that in any way? You're able to run any kind of pre or post initialization logic you would like. Also, it's worth noting that POJOs are generally synonymous with object literals and that is for a reason.

[grofit]

To do what @MeirionHughes does you need to write the following in every class which you want to use in this way:

// OTHER CLASS GOODNESS
    public constructor(
        fields?: {
        // one line per field with name and type
        }) {
        if (fields) Object.assign(this, fields);
    }
// OTHER CLASS GOODNESS

Also it will only work in ES5 due to the Object.assign, which is fine for most people but some of us have to also support ES3 in the older browsers.

However that ES5 thing to one side, given the more c# style approach it means I don't need to write any boilerplate constructors which is basically the EXACT SAME LINES as written above describing the class members, i.e:

export class MyClass
{
    public myType: string; // here is my field

    public constructor(
        fields?: {
           myType: string // just a duplication of the above field
        }) {
        if (fields) Object.assign(this, fields);
    }
}

The compiler should know what fields (and their types) are available within the class being instantiated so I do not need to do any of the above code. Why write code yourself to fulfill a task when the compiler could easily do it for you, meaning less code to maintain and more succinct models. In almost all cases typescripts value to developers is its removal of boilerplate code, and this is EXACTLY what this feature would achieve.

[MeirionHughes]

I have to agree with @grofit. Also there are plenty of other cases of typescript having generally unsupported functionality; es7 async/await is a good example; effectively must be transpiled down to at least es6.

Someone needs to propose new Person { name:"joe" } in es9/10/11 then we can pretend the syntax is valid js and can be used in ts; the proposition seems rather basic:

var person = new Person {name:"Joe"};

should be transpiled to:

var person = new Person();
person.name = "joe"; 

As I see it, the issue is not that you cannot do this; just that the work around requires extra boiler-plate code per-class implementation.

There are lots of examples of new features making life easier: i.e. You don't NEED async/await... you could do it manually.

[MeirionHughes]

I thought about this again and the main issue with it is when you have a lot of nesting going on; I guess the initialisation of the objects would have to be flattened down, or use functions to generate them inline.

ts:

return new [
   new Person() {
        name:"Joe"
   },
   new Person() {
        name:"James"
        info: new Info(){
            authority:"High"
        }
   },
]; 

js:

let person_1 = new Person();
person_1.name = "Joe";
let person_2 = new Person();
person_2.name = "James";
let info_1 = new Info();
info_1.authority = "High"
person_2.info = info_1;

let array_1 = [person_1, person_2];

return array_1;

not amazingly difficult.

[aluanhaddad]

If the type just has properties, it should not be a class. If it needs methods or super calls, use a factory.

[avonwyss]

@aluanhaddad Please see my post Feb 8th for situations where this is needed for type-safety. Using a factory does just shift the problem into the factory method; how to implement the factory in a type-safe manner?

@MeirionHughes I agree that code generation would be simple, but not the way you suggest it. Your approach could lead to a whole lot of variables and also problems in more complex cases (see below)...
I would rather see code like this generated:

return new [
   (function() {
        var o = new Person();
        o.name="Joe";
        return o;
   })(),
   (function() {
        var o = new Person();
        o.name = "James";
        o.info = (function() {
            var o = new Info();
            o.authority = "High";
            return o;
        })();
        return o;
   })()
]; 

This approach would be straightforward to generate and because it remains a normal JS expression it would not break the semantics. To illustrate the point, take this example:

doSomething(Math.random() > 0.5
        ? new User() { name: "Peter" }
        : new Group() { members = [new User() { name: "John" }] }
    );

What code would your approach generate for this? It cannot know in advance which branch of the conditional statement will be used. The only way to solve this with a "flattening" approach is to generate explicit code for each conditional branch, which will result in up to 2^(number-of-conditionals) code branches, so that does not seem like a viable solution.

[aluanhaddad]

@avonwyss I see. I think a better alternative would be to have the compiler track mutations to the type across assignments. The problem with the Function and Array examples is that there is no way to express them declaratively in JavaScript and I fail to see how initializers would help in these cases.

[avonwyss]

@aluanhaddad My goal would primarily be to have type-safety when creating augmented functions and arrays, in contrast to objects which are created with the new where this would just be nice syntactic sugar for assigning several properties at once.

The compiler could and should tell me if I'm missing mandatory properties (especially when one starts using the nullability checks), however the necessity for a cast makes this plain impossible.

Syntax-wise, a new, array or function creation could be followed by an object literal which defines the properties and their values to be set on the result of the creation expression. Like so:

class Foo {
  bar: any;
}

const foo: Foo = new Foo() {
    bar: 0;
  };

type FnFoo {
  bar: any;
  (): void;
}

const fnFoo: FnFoo = () => {
    doSomething();
  } {
    bar: 10
  };

type ArrFoo<T> = Array<T> & {
  bar: any;
}

const arrFoo: ArrFoo<any> = [1, 2, 3] {
    bar: 20;
  };

Since the object creation is always also implying a call, wrapping the assignments into a function as shown in my previous comment should qualify as being a way to express that in JavaScript IMHO - if you don't think so you need to explain what you mean exactly

Also, with the introduction of readonly in TS2 (#12), it may be a good solution to allow read-only members to be assigned like this for functions and arrays since this can be seen as being part of the construction expression. As of now, it requires another cast to any to work... like this:

type ArrFoo<T> = Array<T> & {
    readonly bar: any;
}

const arrFoo: ArrFoo<any> = [1, 2, 3] as any;
(arrFoo as any).bar = 20;

[aluanhaddad]

@avonwyss actually I think that would be very valuable. I would like to avoid the new keyword if possible, but I think what you are proposing actually makes a lot of sense. Thanks for clarifying.

[linvi]

@RyanCavanaugh Your syntax is really not good, as it forces to have the field initializer within the constructor.

The goal of the C# syntax for field initialization is to have clear disctinction between the constructor and and how the fields are initalized.

The only way to do this currently with Typescript is to use

var user = new User();
user.name = 'nqdq';
user.email = 'dqkdq';
// ...

The C# sytax encapsulates the entire initialization within brackets that visually delimits the object initialization and therefore improve the code readability.

I personally think that this would be really a great improvement specially as Typescript does not support method/constructor overloading.

[roman-petrov]

+1 for this feature. It can save developers for writing a lot of boilerplate code, prettify code and improve program readability.

[aluanhaddad]

Honestly, the more TypeScript I write, the more I find myself wanting its features in other languages like C#. Like just the other day I was thinking "man I can't believe I can't say that this property is required and this one is optional".

[Knaackee]

What about the following.

No new feature is needed here. You can just initialize in the constructor.

Case 1: Every Property

export class Person {
    public id: number;
    public age: number;

    constructor(initializer?: Person) {
        // return if no initializer is passed in
        if (initializer === undefined) {
            return;
        }
        // apply 
        Object.keys(initializer).forEach((key, index) => {
            this[key] = initializer[key];
        });
    }
}

const myPerson = new Person({id: 2, age: 12});

Case 2: Just a subset of Properties

Instead of using Person as the initializer type, just use a interface or other object matching the properties.

export class Person {
    public id: number;
    public age: number;

    constructor(initializer?:{ age: number }) {
        // ... same as before ....
    }
}

const myPerson = new Person({id: 2, age: 12});

Instead of { age: number } you can use a interface or other object too.

Now, lets make it reusable

const initializeObject = <TTarget, TSource>(target: TTarget, source: TSource) => {
    if (target === undefined || source === undefined) {
        return;
    }
    Object.keys(source).forEach((key, index) => {
        target[key] = source[key];
    });
};

export class Person {
    public id: number;
    public age: number;

    constructor(initializer?: Person | { age: number}) {
        initializeObject(this, initializer);
    }
}

[linvi]

@Knaackee You do not seem to understand the difference between a constructor and an initializer.

The goal of the C# syntax for field initialization is to have clear distinction between the constructor and and how the fields are initalized.

In your example the constructor takes the responsibility of initializing all the fields. It means that if you want to build your object in 5 different ways, your ctor will be responsible to use 5 different logic to initialize the object, This is absurd.

Sometimes you want such responsibility to live outside of your constructor logic. This prevent the class code to be polluted by some code that it should not care about.

[Knaackee]

@linvi Iam aware of that. I just wanted to show a simple solution to set some properties in one line. I know that this is not the same as in c#.

[dolanmiu]

Initialisers are just syntactic sugar, you can have both a constructor AND initialiser code in C#

It just cleans up the code and makes it look nicer

It would be very nice to have this feature

Why has it taken this long for this feature to come through? Is this feature particularly difficult?

[RyanCavanaugh]

@dolanmiu this is tagged "Out of Scope" -- if you want it to happen, you should raise this with the ECMAScript committee as they control the syntax and semantics of class initialization

[linvi]

@RyanCavanaugh I do not understand. Typescript is not only reproducing ECMAScript. It is enhancing it. For example ECMAScript does not have interfaces or static typing, yet Typescript does.

Therefore why does this feature has to be out of scope? Specially when you see that people regularly request it for years.

[dolanmiu]

@RyanCavanaugh it is not supposed to be out of scope

Like I said above, object initialisation is only SYNTACTIC SUGAR

It does not affect the way ECMAScript does object construction at all. It is merely a shorthand notation. Which seems reasonable as a feature of Typescript.

Please read up on how C# does object initialisation

[mhegazy]

@dolanmiu, when considering new TS features, we follow the TypeScript desing goals. It is not about syntactic sugar or not, it is about goal 6. Align with current and future ECMAScript proposals..

The committee has reserved the syntax after : in declaration, and is guarantee not to step on it, so we have that are for adding syntactic features in the type declaration domain without conflicting with future versions of ECMAScript. For anything else, however, we do not have this guarantee. the committee could use this syntax in the future to mean something different; this would result in a breaking change for our customers, something we do like to avoid whenever possible.

For such proposals, we ask you present them to TC39 to avoid any potiential conflict with the ECMAScript standard.

[MeirionHughes]

Typescript 2.1 just made this a whole lot easier with the Mapped Types. You can now do:

class Person {
    public name: string = "default"
    public address: string = "default"
    public age: number = 0;

    public constructor(init?:Partial<Person>) {
        Object.assign(this, init);
    }
}

let persons = [
    new Person(),
    new Person({}),
    new Person({name:"John"}),
    new Person({address:"Earth"}),    
    new Person({age:20, address:"Earth", name:"John"}),
];

[linvi]

@MeirionHughes interesting, thanks for sharing.

[OliverJAsh]

@MeirionHughes Unfortunately this means you lose some type safety on properties without defaults:

{
    class Person {
        public age: number;

        public constructor(init?:Partial<Person>) {
            Object.assign(this, init);
        }
    }

    let persons = [
        new Person(),
        new Person({age:1}),
        new Person({}), // want this to error!
    ];
}

What we actually want is NamedProps = AllProps - PropsWithoutDefaults. I'm not sure mapped types have that flexibility?

[MeirionHughes]

yeah this was raised on my SO answer too; I think the only current sane solution there is to define any class member with defaults as optional. i.e.

class Person {
  public name?: string = "default";
  public age: number;

  public constructor(init: Person) {
    Object.assign(this, init);
  }
}

let people = [
  new Person(), //error
  new Person({}), //error
  new Person({ age: 10 }), //ok 
  new Person({ age: 10, name: "John" }), //ok
];

pro:

• a default instance of the class will have the optionals defined.
• an initialiser (casted) doesn't need the optionals defined
• an initialiser without the optionals wont override the defaults of the instance.

con:

• nothing stopping user to undefine / delete (explicitly) a field that is marked optional.

of course an argument could be made that if the fields are required to make an instance, then they should be true parameters of the constructor. i.e. constructor(age: number, others: Partial<Person>)

[OliverJAsh]

Another con there is name would be typed as string | undefined.

I think this really needs subtraction types, #4183

[rappinc]

When compiling this error appears: Cannot find name 'Partial'.
typescript version: 2.1.5

[wijnsema]

Eh, what about

class Person {
    public name: string
    public age: number
}

var p: Person = { age: 23, name: 'Ronald' }

Type safe, intellisense

[cervengoc]

@wijnsema Yes, type safe, inellisense, but not a Person instance actually, which is quite a drawback :) So for example your constructor will never run.

And note also, that to make this type-compatibility work, you have to define every member of the class, in your object literal, including methods for example.

[iddan]

Consider this syntax:

class Person {
    constructor({ name });
}

instead of

class Person {
    constructor({ name }) {
        Object.assign(this, { name });
    }
}

[aluanhaddad]

Consider this syntax:

class Person {
    constructor({ name });
}

instead of

class Person {
    constructor({ name }) {
        Object.assign(this, { name });
    }
}

That seems reasonable except that type annotations on destructured parameters are already extremely unpleasant to write and it is good for parameters to have type annotations so it doesn't buy you much.

Also by omitting

Object.assign(this, { name });

you are missing out on the opportunity to write

Object.feeze(Object.assign(this, { name }));

[iddan]

@aluanhaddad I do, but I always can go back to normal constructor. The thing is that you won't need type annotations on the destructor as they can be inferred by the class's annotations

[1TheMuffinMan]

I think this is pretty darn close to c# style object initializer.

export class EmailOptions {
    constructor(fields?: { replyTo?: string, fromEmail?: string, fromName?: string, recipients?: ContentVariable[], templateName?: string }) {
        if (fields) {
            this.replyTo = fields.replyTo;
            this.fromEmail = fields.fromEmail;
            this.fromName = fields.fromName;
            this.recipients = fields.recipients;
            this.templateName = fields.templateName;
        }
    }
    replyTo: string;
    fromEmail: string;
    fromName: string;
    recipients: ContentVariable[];
    templateName: string;
}

Usage:

let opts = new EmailOptions({
            fromEmail: '[email protected]',
            recipients: [new ContentVariable(this.email, 'to')],
            templateName: 'confirmation-to-user'
        });

[MeirionHughes]

@1TheMuffinMan doing it manually is useful if you have some fields that are required; if they're all optional (like in your case) just use the Partial trick:

export class EmailOptions {
    constructor(fields:Partial<EmailOptions>
       Object.assign(this, fields);
    }
    replyTo: string;
    fromEmail: string;
    fromName: string;
    recipients: ContentVariable[];
    templateName: string;
}

if you have just a few required fields, but the rest are optional... use a type union:

    constructor(fields:Partial<EmailOptions> & {replyTo: string} 
       Object.assign(this, fields);
    }

[1TheMuffinMan]

@MeirionHughes Ah, that is better. Thanks.

[kitsonk]

Also, if you don't want to have to worry about maintaining the type in two places in the last example, you could do this:

export class EmailOptions {
    constructor(fields:Partial<EmailOptions> & {replyTo: EmailOptions['replyTo']}) {
       Object.assign(this, fields);
    }
    replyTo: string;
    fromEmail: string;
    fromName: string;
    recipients: ContentVariable[];
    templateName: string;
}

[iddan]

neat @kitsonk!

[DKroot]

Going through this this discussion, I stumbled upon two points that were not obvious to me. Just wanted to mention them for other people who may find this discussion.

1. Object.assign(this, fields) works in ES6 / ES2015 only.
2. If a class constructor does not do any work (as in the example above) you don't need to call constructor at all. Instead you can simply do an object assignment:

class EmailOptions {
  replyTo: string; // Required field
  fromEmail?: string;
  fromName?: string;
  templateName?: string;
}

let opts:EmailOptions = {
  replyTo: '[email protected]',
  fromEmail: '[email protected]',
  templateName: 'confirmation-to-user'
};

[avonwyss]

@DKroot For 1. there are plenty of polyfills for older JS versions, so having access to this function is not really a problem.

However, 2. is not equivalent to a constructor call, even if you pretend that the constructor does nothing. If you do a opts instanceof EmailOptions you'll get false returned, whereas using the constructor will set the prototype correctly and then it would return true. This is an important difference.

[DKroot]

@avonwyss Good point. instanceof might certainly make a difference.

[FrogTheFrog]

@kitsonk Why don't you do it like this:

type ObjectFields<T> = {
    [P in keyof T]: T[P];
};

export class EmailOptions {
    constructor(fields:ObjectFields<EmailOptions>) {
       Object.assign(this, fields);
    }
    replyTo: string;
    fromEmail?: string;
    fromName?: string;
    recipients?: ContentVariable[];
    templateName?: string;
}

This will keep nagging you for missing required fields.

Edit: keep in mind that this will also nag you about methods and stuff, however it works for this specific example. In other words you can use it where want to replace data structures and might want to use instanceof on them.

[aj0strow]

Immutable JS Record Replacement:

class Person {
    readonly name: string;
    readonly age: number;

    constructor(...initData: Partial<Person>[]) {
        Object.assign(this, initPerson, ...initData)
    }
}

const initPerson: Partial<Person> = {
    name: "",
    age: 0,
}

const v1 = new Person()
const v2 = new Person(v1, { name: "AJ", age: 23 })
const v3 = new Person(v2, { age: 24 })

[rihei]

@FrogTheFrog, could you explain what is the difference in using ObjectFields vs. just the type itself:

export class EmailOptions {
    constructor(fields: EmailOptions) {
       Object.assign(this, fields);
    }
    replyTo: string;
    fromEmail?: string;
    fromName?: string;
    recipients?: ContentVariable[];
    templateName?: string;
}

[MeirionHughes]

@rihei I don't see there being a difference either. There is scope to pull the object fields and, specifically, remove functions. but you can't do that until type operators/subtraction drops.

[FrogTheFrog]

@rihei Honestly, I don't know... At that time I must have been searching for something that "worked". Then I found some new way to write it, got overexcited and posted here. Only to find out that it's more of the same.

[rihei]

Ok, thank you both! :) I’m new to all this and wasn’t sure I got it right. As a C# programmer I was surprised not to have an object initialization syntax in TS. However, it seems to be a pretty good option to write this kind of one-line constructor to DTO classes etc.

[aluanhaddad]

@rihei bear in mind that classes in TypeScript do not play by any means the same that they play in C#. Thinking otherwise is a road to pain and sadness.

I recommend that you use objects for DTOs instead.

[rihei]

@aluanhaddad, by objects you mean anonymous objects? In most cases I prefer using strongly typed DTOs to make sure they have correct fields on every call site. But this is off-topic here :) I vote for the actual object initialization syntax, but am ok with the current one-line constructor, too.

[aluanhaddad]

I am talking about object literals. Object literals are strongly typed.

[kitsonk]

In JavaScript _anonymous objects_ is not a term commonly used, usually ported from people familiar with other languages... Objects don't have _names_ in JavaScript, unlike Functions, which can have names and thereby _anonymous functions_ are a _thing_. Some people apply the _anonymous objects_ to _object literals_ (e.g. objects created with curly braces, versus a constructor function/class). And as @aluanhaddad says those are implicitly strongly typed at creation, and their assignability differs slightly in TypeScript because the objects are considered _fresh_ and so they are checked for excess properties at assignment. The following two lines produce exactly the same output (and should have the same runtime footprint):

new Object();
{};

On the other hand, these are different:

Object.create({});
{};

In that the first, will have a prototype strictly equal to the object literal that is passed in as the create argument, where as the second will only have a prototype strictly equal to Object.prototype.

I still think people are projecting from other languages here... There are reasons why the language doesn't account for some of these features, because the language essentially has them, just in slightly different syntaxes and constructs.

[aluanhaddad]

@kitsonk well stated. I would say that is the correct way to look at it.

I particularly get concerned when people discuss DTO classes because that implies that they plan to put in place an entire layer for serialization features that are already here in the language.

To talk about another language briefly @rihei mentioned C# and, while it is common to serialize and deserialize objects to specific DTO types in that language, it hasn't been _necessary_ to do that in C# since ~2008.

[nesbocaj]

Sorry for reviving such an old issue, but for anyone still finding the lack of this feature to be an inconvinience, there's this method:

const obj = { ...new MyClass(), field1 = "ASD", field2 = "QWE" };

Of course it would be nice if the prototype was preserved, but I guess we can't have everything...

Edit:

For instances where the prototype must be preserved, one could instead do this:

function initializeObject(obj, properties) {
  return Object.create(
    Object.getPrototypeOf(obj),
    Object.getOwnPropertyDescriptors({ ...obj, ...properties }))
}

const obj = initializeObject(new MyClass(), { field1 = "ASD", field2 = "QWE" });

[vivatum]

Base on TypeScript docs...

export class User {
  id: number;
  name: string;
  email: string;

  constructor(id: number, name: string, email: string) {
    this.id = id;
    this.name = name;
    this.email = email;
  }
}

let newUser = new User(123, "John", "[email protected]");

[DKroot]

@vivatum Of course, a class can have (multiple) constructors which can be used just like in other OO languages. However, (C#) object initializers are quite powerful syntactic sugar because they enable the ability to initialize an object using arbitrary, ad-hoc combinations of fields. They are good for 2 reasons:

1. Handy for classes with many fields and initialization needs.
2. Cover what (vast) majority of constructors do: taking arguments and assigning them to fields thus eliminating the need in writing many constructors

Can you live without object initializers? Of course. Most OO languages do.
Are they a good idea to support? I think so.

[manoharreddyporeddy]

What about this?

http://stackoverflow.com/a/33752064/3481582

var anInstance: AClass = <AClass> {
    Property1: "Value",
    Property2: "Value",
    PropertyBoolean: true,
    PropertyNumber: 1
};

In fact, this is what is working in 2018

[FrogTheFrog]

@manoharreddyporeddy That's a BIG "no no". Your class will not have correct prototype, methods and etc. since you're casting (not constructing) a normal object to type AClass.

[manoharreddyporeddy]

@FrogTheFrog
@https://github.com/FrogTheFrog

I am actually running unit tests.
They need input, i have a json object, the casting works fine.

1. I actually have nested and a long structure.
   What is the best way to do, any example?

2. I am not sure why this exists in first place, when it works perfectly fine.

[avonwyss]

@manoharreddyporeddy If you have working unit tests then they are simply not checking anything related to what @FrogTheFrog has written. Since the type system of TypeScript is a compile-time thing you will not get any casting error at runtime as you would in Java or C#. This does not change the fact, however, that the prototype chain is not correctly set up, and that you force the compiler to assume that the object has the correct prototype but this will not be true at runtime. This is JS fundamentals.

[MeirionHughes]

Perhaps the way to move forward with this proposal is to come at it from the existing constructor field syntax: i.e.

class Foo {
  constructor(public myName) { } 
}

gets extended to support nesting of public/private.

class Foo {
  constructor(opts: {public myName} ) { } 
}

or some other keyword that explicitly flattens the passed type:

class Foo {
  constructor(flatten public opts: {myName} ) { } 
}

both resulting in the same class Foo with a field myName

cc: @RyanCavanaugh

[avonwyss]

@MeirionHughes The constructor syntax does not address all cases where an object initializer seems to be the only way to avoid unsafe casts as noted earlier in the discussion. An object initializer syntax without support for augmented functions and arrays would be pointless IMHO.

[manoharreddyporeddy]

@FrogTheFrog @avonwyss Others

Thanks, I am not an expert in this but is similar structure is below, and it has no functions (Good point you mentioned) in the Cls1

Everything as a class is good in Typescript.

Example: Below discussion is on what is the best way to do.

class Cls1 {
public key1: string;
public key2: number;
public key3: string;
// no functions - just the object assignment
}

Option 1: ---- I have a complex structure, this is unit testing, this looks very simple to use, I can copy paste the network response from the browser, when several unit tests with different values, then this will fare much easier ----
let obj1: Cls1 = {
key1: 'val1',
key2: 0,
key3: 'val3'
}

Option 2 ---- default constrcutor, and assignments ----
let obj1: Cls1 = new Cls1();
obj1.key1 = 'val1';
obj1.key2 = 0;
obj1.key3 = 'val3';

Option 3 ---- paramterised constructor is needs to be created, inside it assignments ----
let obj1: Cls1 = new Cls1('val1', 0, 'val3');

Option 4
< Any other option you may have, easy for complex structure, and easy to copy paste from JSON object will be better, similar to Option 1>

What is the best option for unit testing?
What is the best option going prod?

Thank you

[dolanmiu]

@manoharreddyporeddy

I have written an answer above this chain, but the feedback is very mixed, so I re-thought about it.

After using TypeScript for a while, I think doing this is best

interface MyOptions {
    name: string;
    age: number;
}

public class Person {
    constructor(private readonly options: MyOptions)
}

then you can do this:

new Person({
    name: "Tom",
    age: 30
})

Advantage of doing it like this is that you are exposing less variables out. It's less leaky

Doing it the classical way like below is bad because now those variables are exposed and can be changed anywhere else in the app:

const klass = new Person();
klass.name = "Tom";
klass.age = 30;

There's nothing stopping you of modifying klass.name anywhere. You could say "oh, but I want it to be changed!". In which I will say, use a setter rather than expose what should be private.

Not only that, but it is less robust. it means its possible to instantiate a Person without a name or age.

What I am trying to say is, its separating the stuff which really should be in the constructor.

[ford04]

I am not sure, if it has changed in newer typescript versions - mine is 3.1.6 -, but this does not compile (regardless if strict or not compiler options):

class MyClass implements MyInterface {
    a: string; 
    b: number;

    constructor(i: MyInterface) {
        Object.assign(this, i);
    }
}

interface MyInterface {
    a: string;
    b: number;
}

Error: [ts] Property 'a' has no initializer and is not definitely assigned in the constructor. [2564]
Same for b.

Ideally, I would like to simply write following to let a new class object initialize from other type (like object initializer):

class MyClass implements MyInterface {

    constructor(i: MyInterface) {
        Object.assign(this, i);
    }
}

interface MyInterface {
    a: string;
    b: number;
}

Current error: Class 'MyClass' incorrectly implements interface 'MyInterface'. Property 'a' is missing in type 'MyClass'. [2420]

Did I miss some workaround mentioned above / are the plans to make class constructors more type aware?

[avonwyss]

@ford04 This happens when both strictPropertyInitialization and strictNullChecks is enabled, see Playground (TS 3.2.1-insiders.20181128). I guess when using strictPropertyInitialization you should manually copy these for now.

[ford04]

thanks, didn't know about that strictPropertyInitialization option.
My current workaround is to use the bang operator like this

class MyClass implements MyInterface {
    a!: string; 
    b!: number;
    constructor(i: MyInterface) { Object.assign(this, i); }

, as I find these strict compiler checks very helpful.

[Gianthra]

I don't know if this helps, however I've been doing this for my items, it's not the same but it seems to match what we're tying to do here and it follows the typescript syntax style. (I'm on TS 3.1.1 I think)

let car:Vehicle = {
    Brand: "Tesla",
    // gives compiler error for missing values
    // and for child values that are missing
    //Type: "Electric"
};

[arturoarevalo]

Coming from a C# background I find object initializers very useful. For a project I'm working on I reached the following solution.

First, define a generic base class (I called it DTO) that will take care of initialization of the properties it receives as an object in the constructor. This class will never be instantiated directly, so I made it abstract. The constructor receives a single parameter, whose type is derived from the generic class EXCLUDING methods.

type ExcludeMethods<T> =
    Pick<T, { [K in keyof T]: T[K] extends (_: any) => any ? never : K }[keyof T]>;

abstract class DTO<T> {
    public constructor(initializer: ExcludeMethods<T>) {
        Object.assign(this, initializer);
    }
}

Now, we can define our "initializable" classes extending it.

class Person extends DTO<Person> {

    public readonly id: string;
    public readonly value1: number;
    public readonly value2: number;

}

const person = new Person({
    id: "id",
    value1: 10,
    value2: 20
});

Type validation and refactoring field names work like a charm. Not as clean as a C# object initializer, but gets its job done

[feluxe]

@arturoarevalo This is brilliant! Structs for TypeScript. I find the class/constructor syntax _way_ to verbose and interfaces suck when you need to type check on them. This seems like a nice workaround. Thanks for posting this.

Edit: There is also this: https://github.com/alexeyraspopov/dataclass which looks very similar but allows default values and more.

[IonelLupu]

@arturoarevalo It is possible to have constructor initializer in the parent of a class? For example:

abstract class Person{
    someField: string;
    constructor(initializer: SomeMagicHere){
        Object.assign(this, initializer);
    }
}

class Admin extends Person{
    name: string
}

var john =  new Admin({name: 'John'}); // I need to get only the Admin's fields and not also the Person's fields 

To fix this I've added an initializer method under Person:
```ts
export type ChildObject = Partial>;
abstract class Person{
fill(data: ChildObject){ ... }
}

var john = (new Admin).fill({role: 'John'}); // proper intellisense
````

But I don't like this workaround. And setting it in the constructor: constructor(data: ChildObject<this, Entity>) {} gives: A 'this' type is available only in a non-static member of a class or interface.

For the best DX I need the initializer to go into the constructor