Início / coding / Perguntas / 79105149
Accepted
Parzh from Ukraine
Asked: 2024-10-19 22:20:54 +0800 CST

Por que só recebo um erro para uma união, mas não para um tipo simples?

  • 772

Às vezes, para simplificar uma assinatura de função com entradas complexas, definimos uma coleção de entradas complexas "conhecidas", cada uma associada a um token, e permitimos que o usuário forneça o token.

Minha função trabalha com tuplas (simplificadas para tuplas de 3 elementos aqui) e, inicialmente, não apresentou nenhum erro do compilador:

const TUPLE_LENGTH = 3

type Tuple = readonly [unknown, unknown, unknown]

function fn(tuple: Tuple): void {
    if (tuple.length !== TUPLE_LENGTH) {
        throw new Error(`Expected ${TUPLE_LENGTH} items, instead got ${tuple.length}`)
    }
}

Experimente .

… mas depois de adicionar entradas "conhecidas", um erro do compilador começou a aparecer:

const TUPLE_LENGTH = 3

type Tuple = readonly [unknown, unknown, unknown]

const knownTuples = {
    foo: [1, 2, 3],
    bar: ['a', 'b', 'c'],
    baz: [true, false, null],
} satisfies Readonly<Record<string, Tuple>>

type TupleName = keyof typeof knownTuples

function fn(tuple: Tuple | TupleName): void {
    if (typeof tuple === 'string') {
        tuple = knownTuples[tuple]
    }

    if (tuple.length !== TUPLE_LENGTH) {
        throw new Error(`Expected ${TUPLE_LENGTH} items, instead got ${tuple.length}`)
        //                                                                   ^^^^^^
        // Error: Property 'length' does not exist on type 'never'
    }
}

Experimente .

Por alguma razão, depois if (tuple.length !== TUPLE_LENGTH)no primeiro caso é tuple: Tuplemas no segundo caso é reduzido para tuple: never. Por que isso?

typescript

2 respostas

  1. Best Answer

    O TypeScript geralmente só realiza o estreitamento em tipos de união . Se tuplefor do tipo união Tuple | TupleName, então sua primeira verificação elimina a TupleNamepossibilidade (já que não é um string) e a segunda verificação elimina a Tuplepossibilidade (já que seu comprimento não é 3e todos Tupleos s são de comprimento 3). Então tupleé estreitado até o tipo impossívelnever e você obtém erros ao tentar interagir com ele mais adiante. Esses erros estão lhe dizendo que o fluxo de código não pode alcançar o bloco de código em questão.

    Mas quando tupleé do tipo não-sindical Tuple, tal estreitamento não acontece, mesmo que logicamente você ainda tenha eliminado todas as possibilidades e o fluxo de controle não consiga alcançar o bloqueio de código em questão. Sua pergunta é: por quê?

    A resposta é que esta é uma decisão de design do TypeScript, descrita em microsoft/TypeScript#38963 .

    O maior motivo para isso é que o desempenho do compilador sofreria terrivelmente se o estreitamento tivesse que acontecer para todos os valores , e haveria muito pouco benefício. Você obteria um pouco mais de consistência em torno do nevertipo, mas, principalmente, você apenas faria o verificador de tipos fazer um monte de trabalho extra para potencialmente estreitar valores que quase ninguém está tentando estreitar em primeiro lugar.

    A segunda razão é que aparentemente há muitos tipos não-union onde as pessoas realizam verificações extras de tempo de execução que não deveriam ser necessárias (como você mesmo fez em seu primeiro exemplo) e aqueles se tornando erros irritariam as pessoas. Sim, como você mostrou, isso poderia acontecer para uniões também, mas na prática não acontece com muita frequência. Pessoas que passam pelo trabalho de modelar seus valores como tendo tipos union geralmente querem que eles sejam tipados corretamente sem precisar de verificações de tempo de execução.

    Sim, pode-se argumentar que deveria ser ambos ou nenhum, por uma questão de consistência, mas consistência não é o objetivo final do TypeScript. Veja este comentário em microsoft/TypeScript#9825 (e toda a questão para esse assunto). A facilidade de uso para código do mundo real às vezes é considerada mais importante do que a consistência. E isso tem que ser medido empiricamente e estatisticamente; com que frequência as pessoas se deparam com esse problema, e nós tornamos a experiência média melhor ou pior se a mudarmos? Nessa situação, o comportamento atual de "unions narrow e non-unions don't" funciona bem o suficiente para uma ampla gama de código do mundo real, e torná-lo consistente prejudicaria o usuário médio pelos motivos expostos acima.

    • 1

  2. O código já é seguro quanto ao tipo, pois você não pode enviar uma tupla com comprimento diferente de 3. Então, o segundo tipo de proteção na verdade cria tupleum tipo de never, então o erro é legítimo.

    Você não precisa desse tipo de proteção, ele não faz sentido (e o TS mostra isso com o erro validamente), apenas remova-o. Caso contrário, você precisa permitir arrays em vez de tuples[3] passados ​​para a função.

    • 0

relate perguntas