Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support "satisfies" operator in type/interface declaration as well #53238

Closed
5 tasks
abaldawa opened this issue Mar 13, 2023 · 9 comments
Closed
5 tasks

Support "satisfies" operator in type/interface declaration as well #53238

abaldawa opened this issue Mar 13, 2023 · 9 comments
Labels
Duplicate An existing issue was already created

Comments

@abaldawa
Copy link

abaldawa commented Mar 13, 2023

Suggestion

Currently "satisfies" operator only supports validating runtime const JS objects. It is SUPER useful and I have used it at so many places which has strongly typed the code base even further, thanks a lot for introducing this.

It would be very useful to also support "satisfies" operator in typescript type/interface declaration as well for exactly the same reasons.

🔍 Search Terms

satisfies, interface, type

✅ Viability Checklist

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, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

📃 Motivating Example

Currently "satisfies" operator is only supported in const runtime objects so that they retain their original definition but also have to satisfy the type constraint at either key or values or both.

It would be very helpful to also support the "satisfies" operator in TS interface/type for the very same reason without changing the definition of original interface/type.

See below use case.

💻 Use Cases

If we have an interface as below:

interface DbModels {
  users: Users[];
  addresses: Address[];
  organizations: Organisation[];
}

Now, if we want to derive a new interface that "satisfies" all the keys from the above interface but with different values, there is no way to express it as "satisfies" operator does not support type/interface.

interface DbRecords {
  users: number;
  addresses: (string | number)[];
  organizations: string[];
} satisfies Record<keyof DbModels, unknown> // Would be great if it is supported here as well but it isn't

interface DbQueryResult {
  users: {id: string};
  addresses: {zipCode: string};
  organizations: {name: string};
} satisfies Record<keyof DbModels, unknown> // Would be great if it is supported here as well but it isn't

Any reason why satisfies is only supported on JS const objects but not in TS types? If it is also supported at type/interface then it would be super useful.

@MartinJohns
Copy link
Contributor

Sounds like a duplicate of #52222.

@fatcerberus
Copy link

fatcerberus commented Mar 13, 2023

interface DbRecords extends Record<keyof DbModels, unknown>?
edit: This doesn't work.

@abaldawa
Copy link
Author

@fatcerberus

interface DbRecords extends Record<keyof DbModels, unknown>? Does not error out when you type an extra key (because its an interface) or miss any key.

Moreover, if the DbModels interface changes with key modifications in the future then it will not error out on DbRecords as it is just extending an object having keys with unknown values.

Basically, you are not able to enforce the DbRecords interface to implement the keys coming from DbModels as they default to just unknown values which is much different than how "satisfies" operate, which is error out if keys are missing in the definition.

But thanks a lot for commenting.

@abaldawa
Copy link
Author

@MartinJohns I did check that issue before posting here. Basically, 52222 is not highlighting exactly what I wanted to convey even though the title of the ticket is similar. Hence I create a separate issue highlighting the exact intent.

Thanks for commenting.

@fatcerberus
Copy link

If that doesn’t error, then satisfies wouldn’t error either, because they would both be checking the same thing: is this interface assignable to this other type

@fatcerberus
Copy link

fatcerberus commented Mar 13, 2023

Sorry, my mistake: I meant to use implements, not extends.

Nevermind, that doesn't work. I could have sworn it did.

@abaldawa
Copy link
Author

@fatcerberus "satisfies" does work normally for JS objects where every key in the object has to satisfy the "satisfies" clause. Interface should also work like that and hence my "issue" here to make it available on type/interface as well

@fatcerberus
Copy link

fatcerberus commented Mar 13, 2023

@abaldawa Yeah, I thought you could already use implements on an interface to accomplish that, but it turns out you can't. My suggestion to use extends was just a brainfart.

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Mar 14, 2023
@typescript-bot
Copy link
Collaborator

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

5 participants