Make defining a data class easier

Search Terms

Data class, Property parameters

Suggestion

Data class just means a class, with certain forms of pattern of how it is defined (required), and some predefined methods (optional, like hashCode, equals...).

Basically we want to achieve the following, very simple goal.

const data = new SomeData({ field1: 'abc', field2: 123 })  // But think there're 10 fields
data.field1 // This should have proper jsdoc showing when hovering

Goals:

1. Use keyword arguments to instantiate the class.
   • This is because for larger class, fields can easily have the same type and using an array-like argument is an anti-pattern
2. Very easy to define the class itself, without a tons of boilerplate
3. (Optional) Being able to define a DataClass generic class
4. (Optional) Play nice with property visibility modifier (private/protected/public)
5. (Optional) Can deal with default value

The most immediate pain point is, due to lack of keyword arguments in JS, defining a data class is very awkward. There are a few ways to mimic a data class, but they all come with different awkwardness.

The most correct and cumbersome definition

class SomeData {
  field1: string
  field2: number

  constructor(args: { field1: string, field2: number }) {
    this.field1 = args.field1
    this.field2 = args.field2
  }
}

That's a lot of boilerplate! Each field is written 4 times! This already feels like Java.

Property parameters

class SomeData {
  constructor(private field1: string, private field2: number) {}
}

Most ideal when defining the class, but don't really satisfy requirement 1.

Define constructor argument based on class info

class SomeData {
  private field1!: string
  private field2!: number  // The '!', ehhh

  constructor(args: Partial<SomeData>) {
    Object.assign(this, args)
  }
}

The issues with this approach is:

• Under strict, have to add ! to every field
• Partial cannot ensure the most correct type info

Another try to improve the type safety around missing fields:

type Shape<T> = { [P in keyof T]: T[P] }
class SomeData {
  private field1!: string
  private field2!: number  // The '!', ehhh

  constructor(args: Shape<SomeData>) {
    Object.assign(this, args)
  }
}

The issue is, Shape will include all the methods and stuff that's not really part of the constructor we want.

Interface + Class

interface SomeDataProps {
  field1: string
  field2: number
}

class SomeData implements SomeDataProps {
  field1!: string // Have to repeat them
  field2!: number
  
  constructor(args: SomeDataProps) {
    Object.assign(this, args)
  }
}

Use Cases

Data class is a super common use case, and is already natively supported in other languages like in Kotlin, Python, Scala and etc.

That being said, I wouldn't doubt this would have numerous use cases and it would make things so much easier, especially in large code base.

Use case I've personally seen:

• In TypeORM, defining a entity class: https://github.com/typeorm/typeorm/issues/3445

Thinking about React's component and their props, it's actually the same pattern, compared to the interface+class approach above. But React's choice is to have to append .props on every field access. Reasonable choice given there's also this.state, but it could be better.

Possible Solutions

There's many ways we could make this better. Just listing some of the possibility. I'm honestly not sure which one is the best. But the idea here is to have a design that have no runtime assumption or changing how JS is emitted.

Non-solutions:

1. data class (as in kotlin/scala) modifier on class definition. This would have runtime implications, changing how classes code are emitted in JS
2. decorator (as in python): Don't think it's possible, since currently TS's decorator has no ability to change the class's typing info

Extend property parameters to support objects

class SomeData {
  constructor(args: {
    private field1: number
    private field2: string
  }) { }
}

Looks legit and scoped, since. this only changes the typing of constructor.
But this might put limitation on constructor arguments: For example, maybe we only allow one constructor argument to have this behavior, or not.

Have a way to mark fields as needed in constructor

Similiarly to readonly:

class SomeData {
  construct field1: number = 10  // Can have default value
  construct field2: string

  // Alternatively, this constructor can be auto generated, but that's really against the design goal
  constructor(args: construct SomeData) {
    // construct SomeData = { field2: string; field1?: number }
    // Maybe if there's a way to query a object type with whether each field has the construct modifier, it could be something like
    //   type Construct<T> = { [P in keyof T]: construct T[P] ? T[P] : never }
    // Ideally, we could figure out the intersection of args and the fields with default values forms correctly SomeData
    Object.assign(this, args)
  }
}

// Maybe this could be generalized by using "args: construct this"?

Asserts in constructor

This has to use the Props pattern. Given this is not really adding return types to constructor, but merely an assert type. Definitely feels harder to implement because it might interfere with flow control analysis. But the nice thing is,

• constructor don't have return type either way, so that complies with assert methods don't have a return type.
• assert methods currently have the limitation to have to explicitly mark the type of the receiver, where in this case, we don't have to, since it's a constructor, we already know what it is.

interface SomeDataProps {
  field1: number
  field2: string
}

class SomeData {
  constructor(props: SomeDataProps): asserts this is SomeDataProps {
     Object.assign(this, props)
  }
}

// And, it's possible to have a generic one!
class DataClass<Props> {
  constructor(props: Props): asserts this is Props {
    Object.assign(this, props)
  }

  // hashCode, equals...
}

class SomeData extends DataClass<SomeDataProps> {
  // methods
}

Checklist

I'm quite sure we can find a way to satisfy all the guidelines here.

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

No source files, tests, or entry points are named. Start by reviewing the proposed property-parameter, construct-field, and constructor-assertion sections alongside the TypeScript design goals. Done would require choosing and specifying one implementable type-system design that supports the requested data-class patterns without changing emitted JavaScript.