Typescript: immutable types

Created on 11 Oct 2016  路  9Comments  路  Source: microsoft/TypeScript

situation:

  • i need an interface 100% similar to a given one but with all properties readonly:

typescript interface MyConfig { name: string; settings: MySettings } interface MySettins { values: string[]; }

problem:

  • in order to get MyConfig immutable i have to effectively re-declare it with all properties which is a lot of work and maintenance:

typescript interface MyConfigReadOnly { readonly name: string; readonly settings: MySettingsReadOnly; } interface MySettingsReadOnly { readonly values: ReadOnlyArray<string>; }

solution:

  • allow special declaration that produces a readonly version of an interface based on the original one :

``` typescript

interface MyConfigReadOnly readonly MyConfig {
// <-- notice here how we saved some work redeclaring the name property!
settings: MySettingsReadOnly;
}
interface MySettingsReadOnly readonly MySettings {
values: ReadOnlyArray;
}
```

Duplicate

Most helpful comment

This is a dupe of #10725 (search is our friend).

Also, this (the shallow version) would model Object.frozen() as well.

It relates to detecting frozen objects in CFA (see: #11481 and #11180).

All 9 comments

Note that a proposal and implementation would be nearly identical to subset types at #11233, just with a different operator.

@andy-ms points out that if we implement this as a type operator, the syntax should probably be const T

@sandersn Actually, there would be a significant difference from subset types in that readonly (or const) would be a deep operation, whereas subset is shallow.

proposed solution is suitable for both deep and shallow

alternatively it would be great to get #11536 https://github.com/Microsoft/TypeScript/issues/4892#issuecomment-252969974 and generate DIY'ed readonly interfaces

In addition I would like to purpose a readonly interface: a interface where all members are implicitly marked as readonly:

situation:

  • I need an interface with all members beeing readonly:
interface RegularInterface {
    regularMember: string;
}

interface AllReadOnlyInterface {
    readonly memberA: number;
    readonly memberB: number;
    readonly regular: ReagularInterface;
}

problem:

  • All member must be explicitly marked as readonly.

solution:

  • Add a interface specifer readonly like enum has const enum (const enum has different meaning to the compiler but it just as example of the purposal)
interface RegularInterface {
    regularMember: string;
}

readonly interface AllReadOnlyInterface {
    memberA: number; // memberA is readonly
    memberB: number; // memberB is readonly
    regular: ReagularInterface; // regular is readonly
}

@aleksey-bykov I really want to see this in the language. It helps to solve a myriad of recent issues and allows for some very flexible programming models. It has lots of practical applications. For example wanting to retrieve and expose immutable data from an Http client but allowing a mutable POST object to be built up using a mutable (the default) version of the same type.

It also fills a nice conceptual space in the language and helps to build idiomatic, JavaScript-embracing correspondence between compile time and runtime strictness.

We could finally get fairly accurate, highly useful type definitions for functions such as deep-freeze-strict. This would be a big win.

@NoHomey
I believe this proposal already covers that and more.

This is a dupe of #10725 (search is our friend).

Also, this (the shallow version) would model Object.frozen() as well.

It relates to detecting frozen objects in CFA (see: #11481 and #11180).

In case anyone finds this issue in a search, it's about read-only interfaces, not immutable ones, despite the title. The correct issue for immutable interfaces is #14909.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dlaberge picture dlaberge  路  3Comments

uber5001 picture uber5001  路  3Comments

jbondc picture jbondc  路  3Comments

DanielRosenwasser picture DanielRosenwasser  路  3Comments

manekinekko picture manekinekko  路  3Comments