TanStack Table V9 melhora o desempenho de TypeScript
Aprofundamento CEVIU
Aprofundamento
O TanStack Table V9 não é só uma nova versão com mais recursos: é uma reescrita estratégica do sistema de tipos em TypeScript. Enquanto a V8 usava um único tipo genérico Table<TData>, simples para o compilador, mas inflexível e incompatível com tree-shaking, a V9 adota um modelo modular baseado em TFeatures, onde cada funcionalidade (ordenação, filtro, agrupamento etc.) é declarada explicitamente e só entra no tipo se for usada. Isso resolve limitações crônicas da V8, como declarações globais que contaminavam todos os tables do projeto e impossibilidade de inferir funções personalizadas por tabela.
O ganho de desempenho não veio de mágica: veio de três decisões técnicas concretas. Primeiro, substituir blocos condicionais manuais (14 branches + UnionToIntersection) por um mapa de features nomeado, reduzindo instâncias de tipo e permitindo cache real pelo compilador. Segundo, isolar o tipo interno Table_Internal como interface estática (sem condicionais), evitando expansões repetidas em chamadas internas. Terceiro, usar anotações de variância in out em interfaces genéricas, não para mudar comportamento, mas para forçar comparação direta entre parâmetros, poupando trabalho estrutural no language server. Tudo isso foi medido com tsc --extendedDiagnostics e --generateTrace, método padrão usado também no Router e Form da mesma família.
Por que isso importa
Para devs que usam TypeScript em projetos médios ou grandes, essa otimização não é abstrata: significa menos lag no editor ao navegar em arquivos com tabelas complexas, tempo menor de tsc --noEmit em CI, e menos risco de timeouts no language service, especialmente em monorepos com múltiplos adapters (React, Solid, Svelte). A mudança também redefine o que é viável em bibliotecas de UI: agora é possível ter tipagem rica *e* modular sem penalizar o DX. E o mais prático: quem já usa V9 alphas vai notar diferença imediata ao atualizar para a beta, não é ajuste marginal, é salto de ordem de grandeza na velocidade de typecheck.
Perguntas frequentes
A V9 realmente elimina a necessidade de declaration merging global?
Sim. Na V8, adicionar um novo sortFn exigia estender interfaces globais, afetando todos os tables do projeto. Na V9, cada tabela define seus próprios meta, filterFns e sortFns localmente, sem colisão, sem efeito colateral. O declaration merging restante é só para registrar plugins, e mesmo assim só aparece nos tipos de tabelas que os usam.
Por que o UnionToIntersection ainda existe se é caro?
Ele permanece apenas onde é indispensável: na composição de tipos de plugins customizados. Como os nomes desses plugins vêm de código do usuário (não são conhecidos em tempo de build), não dá pra escrever a interseção à mão. Mas o custo é isolado, só dispara se você realmente usa plugins, e só para os keys declarados.
O que muda na prática ao migrar de V8 para V9?
Você passa de um tipo único Table<TData> para Table<TData, TFeatures>. Isso exige declarar features explicitamente (ex: createTable({ columns, features: [sorting, filtering] })). Em troca, ganha tipagem precisa nas APIs (sem métodos fantasma), bundle menor e inferência correta de funções personalizadas, tudo sem perder compatibilidade com frameworks.
Fontes
- tanstack.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 23 de junho de 2026
- Editoria
- CEVIU Web Dev

