x is T Type guards personalizados e funções de asserção

Última atualização: 2026-10-22

x is T Type guards personalizados e funções de asserção

Quando os guards nativos (typeof/instanceof/in) não bastam, escreva a sua própria função type guard: declare o tipo de retorno como x is T (um predicado de tipo) e o TypeScript estreitará x para T nos ramos em que a função retornar true. Seu irmão é a função de asserção (asserts x is T), que não retorna boolean, mas lança um erro em caso de falha.

GrupoRestrição e Asserções de Tipos
TipoSintaxe
Modo strictNão necessário

ℹ️ Info O editor transpila TypeScript para JavaScript e o executa (sem verificação de tipos); veja a Saída de cada exemplo para o resultado da verificação.

📝 Sintaxe

// Predicado de tipo: x é estreitado para T onde a função retorna true
function isFoo(x: unknown): x is Foo {
  return typeof x === "object" && x !== null && "foo" in x;
}

// Função de asserção: lança erro quando inválido; depois x é tratado como T
function assertFoo(x: unknown): asserts x is Foo {
  if (!isFoo(x)) throw new Error("not a Foo");
}

⚙️ Parâmetros

x is TTipo de retorno predicado: nomeDoParâmetro is TipoAlvo. O corpo da função precisa realizar uma verificação real em tempo de execução
asserts x is TTipo de retorno de função de asserção: lança erro em caso de falha; o código após a chamada trata x como T

Retorno:Uma função predicado é uma função boolean comum em tempo de execução; o estreitamento ocorre em tempo de compilação. Uma função asserts não retorna nada (void) em tempo de execução e sinaliza a falha lançando um erro.

▶ Exemplo

Edite o código abaixo e clique em Testar para ver o resultado transpilado:

Saída:

failed: 404
data: x,y

(Saída de execução após a transpilação; assim que isFailure retorna true, res é estreitado para ApiError e res.data passa na verificação de tipos — o estreitamento é garantido estaticamente pelo tsc, em tempo de execução existem apenas os valores)

💡 Observações

ℹ️ Info x is T muda apenas a visão do compilador — em tempo de execução é uma função comum. As verificações no corpo precisam corresponder ao T declarado; caso contrário, você está mentindo para o compilador.
⚠️ Atenção Um guard errado não é detectado pelo compilador: declarar res is ApiError enquanto verifica campos não relacionados deixa o tipo errado fluir para o ramo e explodir em tempo de execução. Teste a lógica dos seus guards.
💡 Dica Digite o parâmetro como unknown em vez de any — unknown bloqueia todas as operações até ser estreitado, forçando você a escrever lógica de validação completa.
Mais casos em breve.

📚 Tutoriais relacionados

❓ Perguntas frequentes

P Qual é a diferença entre x is T e retornar um boolean comum?
R Com um boolean comum, o compilador não sabe o que true significa, então x mantém o tipo antigo após a chamada; com x is T, x é estreitado para T no ramo verdadeiro. O predicado afeta apenas tipos e não adiciona custo em tempo de execução.
P Quando devo usar a versão asserts em vez da versão is?
R Use asserts x is T quando dados inválidos devem interromper imediatamente (carregamento de configuração, asserções de teste, verificações de ambiente) — ele lança erro, e o código seguinte prossegue com segurança. Use is quando precisar tratar os dois resultados com if/else.
P Existe uma forma mais simples desde o TS 4.4?
R Sim — desde o TS 4.4, condições aliadas (aliased conditions) permitem que const isFailure = res.ok === false estreite automaticamente, e essas consts podem ser reutilizadas. Ainda assim, funções guard nomeadas continuam sendo a forma mais reutilizável.
Web-Tutorial.com

Equipe Técnica Web-Tutorial

Uma plataforma de tutoriais mantida por diversos desenvolvedores. Cada tutorial é escrito e revisado por profissionais da área correspondente. Trabalhamos para manter nosso conteúdo preciso e confiável — se encontrar algum problema, avise-nos.

100%