Você modela o rascunho de um cadastro como `Partial `. Que invariante isso destrói?

Todos ao mesmo tempo: `{ id: "abc", email: undefined }` passa a compilar, embora um rascunho sem e-mail seja inválido no domínio

FFVAcademy

Tipos utilitários (Partial, Pick, Omit...) e quando NÃO usar

⏱ 10 min·⭐ 45 XP

Pré-requisitos (0/1)0%

⬜⚙️ Generics de verdade: variance, constraints e conditional types(TypeScript Profissional)

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

O arsenal — o que vem no lib padrão

Tipo	O que faz	Quando usar
Partial<T>	Todos os campos opcionais	PATCH, merge, form draft (cuidado: veja armadilha)
Required<T>	Todos os campos obrigatórios	Garantir que nada é opcional após setup
Readonly<T>	Todos os campos readonly	Imutabilidade superficial
Pick<T, K>	Seleciona só K	Subconjunto explícito (poucos campos)
Omit<T, K>	Remove K	Tudo exceto alguns (muitos campos, poucas exceções)
Record<K, V>	Dict K → V	Mapa tipado, config, lookup
Exclude<T, U>	T menos o que for atribuível a U	Remover variantes de union
Extract<T, U>	T interseccionado com U	Pegar só variantes que casam
NonNullable<T>	T sem null/undefined	Garantir valor presente
ReturnType<F>	Tipo de retorno de função F	Inferir retorno sem chamar
Awaited<T>	Desempacota Promise<T>	Extrair tipo resolvido

TipoPartial<T>

O que fazTodos os campos opcionais

Quando usarPATCH, merge, form draft (cuidado: veja armadilha)

TipoRequired<T>

O que fazTodos os campos obrigatórios

Quando usarGarantir que nada é opcional após setup

TipoReadonly<T>

O que fazTodos os campos readonly

Quando usarImutabilidade superficial

TipoPick<T, K>

O que fazSeleciona só K

Quando usarSubconjunto explícito (poucos campos)

TipoOmit<T, K>

O que fazRemove K

Quando usarTudo exceto alguns (muitos campos, poucas exceções)

TipoRecord<K, V>

O que fazDict K → V

Quando usarMapa tipado, config, lookup

TipoExclude<T, U>

O que fazT menos o que for atribuível a U

Quando usarRemover variantes de union

TipoExtract<T, U>

O que fazT interseccionado com U

Quando usarPegar só variantes que casam

TipoNonNullable<T>

O que fazT sem null/undefined

Quando usarGarantir valor presente

TipoReturnType<F>

O que fazTipo de retorno de função F

Quando usarInferir retorno sem chamar

TipoAwaited<T>

O que fazDesempacota Promise<T>

Quando usarExtrair tipo resolvido

A armadilha: Partial escondendo modelagem fraca

É tentador usar Partial<User> pra representar "estou criando um User aos poucos". Mas isso descarta invariantes: um "rascunho" na verdade tem regras próprias.

// Antipattern
type UserDraft = Partial<User>;
// Problema: { email: undefined, id: 'abc' } compila — invariante perdido

// Melhor: modelar o rascunho explicitamente
type UserDraft = {
  email: string;          // obrigatório no draft
  name?: string;          // opcional no draft
  age?: number;
  // id NÃO existe até save
};

type User = UserDraft & { id: string; createdAt: string };

⚠️

Use sem medo em patches (input de PATCH API, reduce/merge helpers). Evite pra estados de domínio — modele o estado com seu próprio tipo.

Record vs Map: estrutural vs runtime

// Record: tipo estrutural, valor é objeto
const theme: Record<'light' | 'dark', string> = {
  light: '#fff',
  dark: '#000',
};

// Map: estrutura em runtime (preserva ordem, chaves não-string)
const metrics = new Map<UserId, number>();
metrics.set('abc' as UserId, 42);

Record é melhor pra configs com chaves conhecidas (poucas, fixas). Map é melhor pra dados dinâmicos (chaves desconhecidas, muitas inserções/remoções, precisa de size, iteração ordenada).

Quiz rápido

Você modela o rascunho de um cadastro como `Partial<User>`. Que invariante isso destrói?

Quando NÃO usar utilitários

A regra: se seu tipo nomeado é "usado uma vez e tem significado", nomeie-o. Combinações monstruosas como Omit<Pick<User, 'name' | 'email'>, 'email'> viram ilegíveis. Crie type PublicProfile = { text: string } e fim.

Perguntas frequentes

❓ Quando NÃO usar tipos utilitários?

Quando eles escondem que o modelo está errado: precisar tornar tudo opcional para reaproveitar um tipo costuma indicar que existem dois tipos diferentes — o de criação e o de leitura. Derivar por utilitário é conveniente e propaga o acoplamento.

❓ Derivar tipo do banco ou declarar separado?

Declarar separado o que a API expõe, ainda que pareça duplicação: tipo derivado do esquema faz mudança interna vazar para o contrato público. O que é fronteira precisa ser explícito, e a duplicação aqui é proteção, não desperdício.

❓ Qual utilitário é mais mal usado?

O que torna todos os campos opcionais: usado para "reaproveitar" um tipo, ele apaga a obrigatoriedade e o compilador deixa de cobrar o que é essencial. Ele tem lugar legítimo em atualização parcial, e é aplicado muito além disso.

Fixando

Quiz rápido

`Record<K, V>` e `Map<K, V>` resolvem coisas diferentes. Qual é a distinção que decide a escolha?

Quiz rápido

Quando um tipo utilitário deixa de ajudar e passa a atrapalhar?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

🛡️

Type safety em boundaries: Zod, io-ts e validação runtime

TypeScript Profissional · 12 min · +55 XP

→

Temas deste módulo

Linguagens

Discussão

Carregando comentários…

Tipos utilitários (Partial, Pick, Omit...) e quando NÃO usar

⏱ 10 min·⭐ 45 XP

Pré-requisitos (0/1)0%

⬜⚙️ Generics de verdade: variance, constraints e conditional types(TypeScript Profissional)

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

O arsenal — o que vem no lib padrão

Tipo	O que faz	Quando usar
Partial<T>	Todos os campos opcionais	PATCH, merge, form draft (cuidado: veja armadilha)
Required<T>	Todos os campos obrigatórios	Garantir que nada é opcional após setup
Readonly<T>	Todos os campos readonly	Imutabilidade superficial
Pick<T, K>	Seleciona só K	Subconjunto explícito (poucos campos)
Omit<T, K>	Remove K	Tudo exceto alguns (muitos campos, poucas exceções)
Record<K, V>	Dict K → V	Mapa tipado, config, lookup
Exclude<T, U>	T menos o que for atribuível a U	Remover variantes de union
Extract<T, U>	T interseccionado com U	Pegar só variantes que casam
NonNullable<T>	T sem null/undefined	Garantir valor presente
ReturnType<F>	Tipo de retorno de função F	Inferir retorno sem chamar
Awaited<T>	Desempacota Promise<T>	Extrair tipo resolvido

TipoPartial<T>

O que fazTodos os campos opcionais

Quando usarPATCH, merge, form draft (cuidado: veja armadilha)

TipoRequired<T>

O que fazTodos os campos obrigatórios

Quando usarGarantir que nada é opcional após setup

TipoReadonly<T>

O que fazTodos os campos readonly

Quando usarImutabilidade superficial

TipoPick<T, K>

O que fazSeleciona só K

Quando usarSubconjunto explícito (poucos campos)

TipoOmit<T, K>

O que fazRemove K

Quando usarTudo exceto alguns (muitos campos, poucas exceções)

TipoRecord<K, V>

O que fazDict K → V

Quando usarMapa tipado, config, lookup

TipoExclude<T, U>

O que fazT menos o que for atribuível a U

Quando usarRemover variantes de union

TipoExtract<T, U>

O que fazT interseccionado com U

Quando usarPegar só variantes que casam

TipoNonNullable<T>

O que fazT sem null/undefined

Quando usarGarantir valor presente

TipoReturnType<F>

O que fazTipo de retorno de função F

Quando usarInferir retorno sem chamar

TipoAwaited<T>

O que fazDesempacota Promise<T>

Quando usarExtrair tipo resolvido

A armadilha: Partial escondendo modelagem fraca

É tentador usar Partial<User> pra representar "estou criando um User aos poucos". Mas isso descarta invariantes: um "rascunho" na verdade tem regras próprias.

// Antipattern
type UserDraft = Partial<User>;
// Problema: { email: undefined, id: 'abc' } compila — invariante perdido

// Melhor: modelar o rascunho explicitamente
type UserDraft = {
  email: string;          // obrigatório no draft
  name?: string;          // opcional no draft
  age?: number;
  // id NÃO existe até save
};

type User = UserDraft & { id: string; createdAt: string };

⚠️

Use sem medo em patches (input de PATCH API, reduce/merge helpers). Evite pra estados de domínio — modele o estado com seu próprio tipo.

Record vs Map: estrutural vs runtime

// Record: tipo estrutural, valor é objeto
const theme: Record<'light' | 'dark', string> = {
  light: '#fff',
  dark: '#000',
};

// Map: estrutura em runtime (preserva ordem, chaves não-string)
const metrics = new Map<UserId, number>();
metrics.set('abc' as UserId, 42);

Record é melhor pra configs com chaves conhecidas (poucas, fixas). Map é melhor pra dados dinâmicos (chaves desconhecidas, muitas inserções/remoções, precisa de size, iteração ordenada).

Quiz rápido

Você modela o rascunho de um cadastro como `Partial<User>`. Que invariante isso destrói?

Quando NÃO usar utilitários

Perguntas frequentes

❓ Quando NÃO usar tipos utilitários?

❓ Derivar tipo do banco ou declarar separado?

❓ Qual utilitário é mais mal usado?

Fixando

Quiz rápido

`Record<K, V>` e `Map<K, V>` resolvem coisas diferentes. Qual é a distinção que decide a escolha?

Quiz rápido

Quando um tipo utilitário deixa de ajudar e passa a atrapalhar?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

🛡️

Type safety em boundaries: Zod, io-ts e validação runtime

TypeScript Profissional · 12 min · +55 XP

→

Temas deste módulo

Linguagens

Discussão

Carregando comentários…