Repository navigation
OneOf access by case and inference #59146
Description
🔍 Search Terms
- Generic derived value type
- oneOf
✅ Viability Checklist
- 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
⭐ Suggestion
Here's a very simple example:
interface CaseA {
valueA: any;
}
interface CaseB {
valueB: any;
}
type OneOf = {
$case: "caseA";
caseA: CaseA;
} | {
$case: "caseB";
caseB: CaseB;
}
declare const request: OneOf
// I know that without further checks, on Typescript side, on the OneOf type, we're only sure that
// `$case` exists and we're unsure about the rest. Yet, as human looking at this type, I know we'll
// have either the caseA or caseB and therefore accessing the OneOf type by its $case should result
// in a type of `CaseA | CaseB`. Is there any way of making this work?
request[request.$case]Here's a link to a Typescript Playground
📃 Motivating Example
When using a oneOf with a discriminator, you can now access directly the value by doing yourOneOfVariable[yourOneOfVariable.discriminator] and it'll give you the union of the values.
💻 Use Cases
- What do you want to use this for?
We have a lot of oneOf equivalent in our codebase, especially as we're using protobuf and this is a very classic usecase.
- What shortcomings exist with current approaches?
Not even sure this can be achieve in a type safe way currently?
- What workarounds are you using in the meantime?
Casting the variable as any and then using as again to cast to the union type.
Activity
Jamesernator commentedon Jul 5, 2024
This is dependent typing which TypeScript doesn't support.
(There is a draft for a weak form of dependent typing, but I don't think is strong enough for the behaviour wanted here)
jcready commentedon Jul 5, 2024
The better way to model the one of is like this:
Now you can just access
request.$valueand the type will beCaseA | CaseBand you can refine the type by branching off therequest.$case.maxime1992 commentedon Jul 5, 2024
Thanks James Browning (@Jamesernator) it always hard to find the correct name of the feature one is looking for, but TIL about depending typing :) !
James Wyatt Cready-Pyle (@jcready) it is indeed except that this bit is not done on our side it's generated by a 3rd party lib. I'd need to see if we can tweak it somehow through configuration.
Hopefully dependant typing lands one day though 🤞
jcalz commentedon Jul 5, 2024
Essentially the same problem as #30581 and TS's facility to deal with it is described in #47109. The example here could look like
Playground link
typescript-bot commentedon Jul 12, 2024
This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.