Typescript 递归 object 类型

Question

I want to define a type / interface that is able to contain properties of the same type as itself.

For Example:

    type TMessagesFormat = { [key: string]: string };
    
    interface TMessages {
      messages: TMessagesFormat;
    }
    
    interface TGroupMessages {
      messages?: TMessagesFormat;
      controls: { [key: string]: TMessages | TGroupMessages }
    }
    
    let groupMessages: TGroupMessages = {
      controls: {
        username: { messages: {required: 'Username required'} }
      }
    }
    
    let messages: TGroupMessages = {
      controls: {
        username: { messages: { required: 'Username required' } },
        passwordGroup: {
          messages: { nomatch: 'Passwords doesn\'t match' },
          controls: {
            password: { messages: { required: 'Password required' } }
          }
        }
      }
    };

Type checking works fine for username and passwordGroup, but eg controls in passwordGroup can be anything and TS compiler doesn't complain. In fact if I put controls: 'whatever' property (string shouldn't be a valid type) inside username object literal, code still compiles without any warning or error. Is this possible and how? Thanks!

Answer 1

It looks like this is a bug in TypeScript where excess property checks on object literals don't seem to happen for unions the way you'd expect. The shortest reproduction:

interface A {
    a: string;
}
interface B {
    b: number;
}
const a: A = {a: 'dog', b: 'cat'}; // error, b is unknown property
const ab: A | B = {a: 'dog', b: 'cat'}; // no error!

You would expect ab to error with something like 'cat' is not a number , but it doesn't because of the above issue. If and when that issue gets addressed, your problem should go away.

---

But we don't have to wait. The fact is that excess property checking on object literals isn't very protective. It just warns you if you add an unknown property to a "fresh" object literal. In TypeScript there's nothing really wrong with adding extra properties to an object. If an object is a valid A , that same object is still a valid A even if you add extra properties to it. So if you do something to evade the excess property checking (eg, assign a "non-fresh" literal to it), you're allowed to add any extra properties you want.

const dogCat = {a: 'dog', b: 'cat'};
const a: A  = dogCat; // no error

What if you really want to disallow extra properties? Well, there's no general way to do it for all properties. But if you want to disallow particular extra properties and know their key names, there's a way to do it:

interface A {
    a: string;
    b?: never; // cannot have a defined b
}
interface B {
    b: number;
}
const dogCat = {a: 'dog', b: 'cat'};
const a: A  = dogCat; // error, string is not undefined
const ab: A | B = {a: 'dog', b: 'cat'}; // error, string is not number

Now you get errors for both non-fresh a and ab . So, back to your case...

---

If we can assume that TMessages cannot have a controls property:

interface TMessages {
  messages: TMessagesFormat;
  controls?: never; // no defined controls
}

interface TGroupMessages {
  messages?: TMessagesFormat;
  controls: { [key: string]: TMessages | TGroupMessages }
}

Then, if a TMessages | TGroupMessages TMessages | TGroupMessages has a defined controls property, it must be of the type specified in TGroupMessages :

let tm: TMessages | TGroupMessages = {messages: {foo: 'hey'}, controls: 3}
// error, 'number' not assignable to type '{ [k: string]: TMessages | TGroupMessages }'

And that should work for you. Hope that helps; good luck!

---

TL;DR

Wait for Microsoft/TypeScript#22129 to be addressed, or change your TMessages interface to the following:

interface TMessages {
  messages: TMessagesFormat;
  controls?: never; // no defined controls
}

Answer 2

As of 3.7 this become more of a reality than it was before. IMO TypeScript was to strict at first, but I would imagine from the perspective of the person(s) engineering the langauge, that it would be better to make it too strict, and then loosen up the language, where it made sense to do so, or where it had to be, which is exactly what happened in TS v3.7 . The typescript compiler was adjusted to be more loose , allowing references to types that occur in themselves.

---

I could give you all sorts of examples, but I think the best, would be to demonstrate how loosely you could recursively define your types now

type TMessagesFormat = { [key: string]: TMessagesFormat };

interface TMessages extends TMessagesFormat{
   [key: string]: TMessagesFormat;
}

interface TGroupMessages {
   messages?: TMessagesFormat;
   controls: { [key: string]: TMessages | TGroupMessages };
}

The Above is 100% Legal TypeScript