Se eu tiver algum código como:
type Bravo = {
b?: string;
}
type Charlie = {
c:Bravo['b']
}
function acceptsCharlie(value: Charlie){
//'value.c' is possibly 'undefined'.(18048)
value.c.split('');
}
Isso faz sentido - o tipo Charlie
herda a string opcional de Bravo
.
Podemos resolver isso usando o Required
tipo de utilitário:
type Bravo = {
b?: string;
}
type Charlie = {
// 👇
c:Required<Bravo>['b']
}
function acceptsCharlie(value: Charlie){
// no error here
value.c.split('');
}
Fácil.
Entretanto, se eu adicionar mais uma camada de pesquisa de digitação:
type Alpha = {
a?: string;
}
type Bravo = {
b: Alpha['a'];
}
type Charlie = {
c: Required<Bravo>['b']
}
function acceptsCharlie(value: Charlie){
//'value.c' is possibly 'undefined'.(18048)
value.c.split('');
}
Isso Required
não resolve mais o problema para mim.
O que acontece?
A diferença entre
?
e| undefined
é que na primeira situação o campo pode ser ignorado, enquanto na segunda o campo precisa existir, mesmo que possa terundefined
como valor.Required
funciona apenas em campos opcionais. Se um campo for digitado comofield : X | undefined
, Obrigatório não terá efeito sobre ele.Parque infantil
Enquanto que quando é digitado como
field? : X
, entãoRequired
funciona:Parque infantil
O que você está fazendo com a indireção é que agora
Bravo
definitivamente tem o campob
, que pode ser indefinido ou string, mas não é opcional. Então, nesse caso, Required não pode fazer muita coisa.Trecho das notas de lançamento do TS 2.8 :
faça ambos obrigatórios
b: Required<Alpha>['a'];
. tentei aqui e você pode brincar aqui typescriptlang