Conditional types in TypeScript
I was wondering if I can have conditional types in TypeScript?
Currently I have the following interface:
interface ValidationResult {
isValid: boolean;
errorText?: string;
}
But I want to remove errorText
, and only have it when isValid
is false
as a required property.
I wish I was able to write it as the following interface:
interface ValidationResult {
isValid: true;
}
interface ValidationResult {
isValid: false;
errorText: string;
}
But as you know, it is not possible. So, what is your idea about this situation?
One way to model this kind of logic is to use a union type, something like this
interface Valid {
isValid: true
}
interface Invalid {
isValid: false
errorText: string
}
type ValidationResult = Valid | Invalid
const validate = (n: number): ValidationResult => {
return n === 4 ? { isValid: true } : { isValid: false, errorText: "num is not 4" }
}
The compiler is then able to narrow the type down based on the boolean flag
const getErrorTextIfPresent = (r: ValidationResult): string | null => {
return r.isValid ? null : r.errorText
}
To avoid creating multiple interfaces which only get used to create a third, you can also alternate directly, with a type
instead:
type ValidationResult = {
isValid: false;
errorText: string;
} | {
isValid: true;
};
The union demonstrated by bugs is how I recommend handling this. Nonetheless, Typescript does have something known as “conditional types,” and they can handle this.
type ValidationResult<IsValid extends boolean = boolean> = (IsValid extends true
? { isValid: IsValid; }
: { isValid: IsValid; errorText: string; }
);
declare const validation: ValidationResult;
if (!validation.isValid) {
validation.errorText;
}
This ValidationResult
(which is actually ValidationResult<boolean>
due to the default parameter) is equivalent to the union produced in bugs’s answer or in CertainPerformance’s answer, and can be used in the same manner.
The advantage here is that you could also pass around a known ValidationResult<false>
value, and then you wouldn’t have to test isValid
as it would be known to be false
and errorString
would be known to exist. Probably not necessary for a case like this—and conditional types can be complex and difficult to debug, so they probably shouldn’t be used unnecessarily. But you could, and that seemed worth mentioning.