Alternativas de Enum do TypeScript: Navegando Const Assertions e Union Types para Código Robusto

TypeScript, um poderoso superset do JavaScript, traz tipagem estática para o mundo dinâmico do desenvolvimento web. Entre seus muitos recursos, a palavra-chave enum tem sido há muito tempo uma escolha para definir um conjunto de constantes nomeadas. Enums fornecem uma maneira clara de representar uma coleção fixa de valores relacionados, aumentando a legibilidade e a segurança de tipos.

No entanto, à medida que o ecossistema TypeScript amadurece e os projetos crescem em complexidade e escala, desenvolvedores globalmente estão questionando cada vez mais a utilidade tradicional dos enums. Embora diretos para casos simples, os enums introduzem certos comportamentos e características de tempo de execução que, às vezes, podem levar a problemas inesperados, impactar o tamanho do bundle ou complicar otimizações de tree-shaking. Isso levou a uma exploração generalizada de alternativas.

Este guia abrangente mergulha em duas alternativas proeminentes e altamente eficazes aos enums do TypeScript: Union Types com Literais de String/Numéricos e Const Assertions (as const). Exploraremos seus mecanismos, aplicações práticas, benefícios e desvantagens, fornecendo o conhecimento para tomar decisões de design informadas para seus projetos, independentemente do seu tamanho ou da equipe global que trabalha neles. Nosso objetivo é capacitá-lo a escrever código TypeScript mais robusto, manutenível e eficiente.

O Enum do TypeScript: Um Rápido Resumo

Antes de mergulharmos nas alternativas, vamos revisitar brevemente o enum tradicional do TypeScript. Enums permitem que desenvolvedores definam um conjunto de constantes nomeadas, tornando o código mais legível e prevenindo que "strings mágicas" ou "números mágicos" sejam espalhados por uma aplicação. Eles vêm em duas formas principais: enums numéricos e de string.

Enums Numéricos

Por padrão, os enums do TypeScript são numéricos. O primeiro membro é inicializado com 0, e cada membro subsequente é auto-incrementado.

            enum Direction {
  Up,
  Down,
  Left,
  Right,
}

let currentDirection: Direction = Direction.Up;
console.log(currentDirection); // Saída: 0
console.log(Direction.Left);    // Saída: 2

            

              
                Copy
              
            
          

Você também pode inicializar manualmente membros de enum numéricos:

            enum StatusCode {
  Success = 200,
  NotFound = 404,
  ServerError = 500,
}

let status: StatusCode = StatusCode.NotFound;
console.log(status); // Saída: 404

            

              
                Copy
              
            
          

Uma característica peculiar dos enums numéricos é o mapeamento reverso. Em tempo de execução, um enum numérico compila em um objeto JavaScript que mapeia tanto nomes para valores quanto valores para nomes.

            enum UserRole {
  Admin = 1,
  Editor,
  Viewer,
}

console.log(UserRole[1]); // Saída: "Admin"
console.log(UserRole.Editor); // Saída: 2
console.log(UserRole[2]); // Saída: "Editor"

/*
Compila para JavaScript:
var UserRole;
(function (UserRole) {
    UserRole[UserRole["Admin"] = 1] = "Admin";
    UserRole[UserRole["Editor"] = 2] = "Editor";
    UserRole[UserRole["Viewer"] = 3] = "Viewer";
})(UserRole || (UserRole = {}));
*/

            

              
                Copy
              
            
          

Enums de String

Enums de string são frequentemente preferidos por sua legibilidade em tempo de execução, pois não dependem de números auto-incrementados. Cada membro deve ser inicializado com um literal de string.

            enum UserPermission {
  Read = "READ_PERMISSION",
  Write = "WRITE_PERMISSION",
  Delete = "DELETE_PERMISSION",
}

let permission: UserPermission = UserPermission.Write;
console.log(permission); // Saída: "WRITE_PERMISSION"

            

              
                Copy
              
            
          

Enums de string não recebem mapeamento reverso, o que geralmente é bom para evitar comportamento inesperado em tempo de execução e reduzir a saída JavaScript gerada.

Considerações Chave e Armadilhas Potenciais de Enums

Embora os enums ofereçam conveniência, eles vêm com certas características que merecem consideração cuidadosa:

• Objetos em Tempo de Execução: Enums numéricos e de string geram objetos JavaScript em tempo de execução. Isso significa que eles contribuem para o tamanho do bundle da sua aplicação, mesmo que você os utilize apenas para verificação de tipos. Para projetos pequenos, isso pode ser insignificante, mas em aplicações de larga escala com muitos enums, isso pode se acumular.
• Falta de Tree-Shaking: Como os enums são objetos em tempo de execução, eles frequentemente não são efetivamente tree-shakeados por bundlers modernos como Webpack ou Rollup. Se você definir um enum, mas usar apenas um ou dois de seus membros, todo o objeto enum ainda pode ser incluído em seu bundle final. Isso pode levar a tamanhos de arquivo maiores do que o necessário.
• Mapeamento Reverso (Enums Numéricos): O recurso de mapeamento reverso de enums numéricos, embora às vezes útil, também pode ser uma fonte de confusão e comportamento inesperado. Ele adiciona código extra à saída JavaScript e pode nem sempre ser a funcionalidade desejada. Por exemplo, serializar enums numéricos pode às vezes resultar apenas no número sendo armazenado, o que pode não ser tão descritivo quanto uma string.
• Sobrecarga de Transpilação: A compilação de enums em objetos JavaScript adiciona uma pequena sobrecarga ao processo de build em comparação com a simples definição de variáveis constantes.
• Iteração Limitada: Iterar diretamente sobre valores de enum pode ser não trivial, especialmente com enums numéricos devido ao mapeamento reverso. Frequentemente, você precisa de funções auxiliares ou loops específicos para obter apenas os valores desejados.

Esses pontos destacam por que muitas equipes de desenvolvimento global, especialmente aquelas focadas em performance e tamanho do bundle, buscam alternativas que ofereçam segurança de tipo semelhante sem o custo de tempo de execução ou outras complexidades.

Alternativa 1: Union Types com Literais

Uma das alternativas mais diretas e poderosas aos enums no TypeScript é o uso de Union Types com Literais de String ou Numéricos. Essa abordagem aproveita o robusto sistema de tipos do TypeScript para definir um conjunto de valores específicos e permitidos em tempo de compilação, sem introduzir novas construções em tempo de execução.

O que são Union Types?

Um tipo de união descreve um valor que pode ser um de vários tipos. Por exemplo, string | number significa que uma variável pode conter uma string ou um número. Quando combinado com tipos literais (por exemplo, "success", 404), você pode definir um tipo que só pode conter um conjunto específico de valores predefinidos.

Exemplo Prático: Definindo Statuses com Union Types

Vamos considerar um cenário comum: definir um conjunto de status possíveis para um job de processamento de dados ou conta de usuário. Com union types, isso parece limpo e conciso:

            type JobStatus = "PENDING" | "IN_PROGRESS" | "COMPLETED" | "FAILED";

function processJob(status: JobStatus): void {
  if (status === "COMPLETED") {
    console.log("Job finished successfully.");
  } else if (status === "FAILED") {
    console.log("Job encountered an error.");
  } else {
    console.log(`Job is currently ${status}.`);
  }
}

let currentJobStatus: JobStatus = "IN_PROGRESS";
processJob(currentJobStatus);

// Isso resultaria em um erro em tempo de compilação:
// let invalidStatus: JobStatus = "CANCELLED"; // Erro: Type '"CANCELLED"' is not assignable to type 'JobStatus'.

            

              
                Copy
              
            
          

Para valores numéricos, o padrão é idêntico:

            type HttpCode = 200 | 400 | 404 | 500;

function handleResponse(code: HttpCode): void {
  if (code === 200) {
    console.log("Operation successful.");
  } else if (code === 404) {
    console.log("Resource not found.");
  }
}

let responseStatus: HttpCode = 200;
handleResponse(responseStatus);

            

              
                Copy
              
            
          

Observe como estamos definindo um alias type aqui. Isso é puramente uma construção de tempo de compilação. Quando compilado para JavaScript, JobStatus simplesmente desaparece, e os literais de string/número são usados diretamente.

Benefícios de Union Types com Literais

Esta abordagem oferece várias vantagens convincentes:

• Puramente em Tempo de Compilação: Union types são inteiramente apagados durante a compilação. Eles não geram nenhum código JavaScript em tempo de execução, levando a tamanhos de bundle menores e tempos de inicialização de aplicação mais rápidos. Esta é uma vantagem significativa para aplicações críticas de performance e aquelas implantadas globalmente onde cada kilobyte conta.
• Excelente Segurança de Tipo: TypeScript verifica rigorosamente as atribuições contra os tipos literais definidos, fornecendo fortes garantias de que apenas valores válidos são usados. Isso previne bugs comuns associados a erros de digitação ou valores incorretos.
• Tree-Shaking Ótimo: Como não há objeto em tempo de execução, union types inerentemente suportam tree-shaking. Seu bundler inclui apenas os literais de string ou numéricos reais que você usa, não um objeto inteiro.
• Legibilidade: Para um conjunto fixo de valores simples e distintos, a definição de tipo é frequentemente muito clara e fácil de entender.
• Simplicidade: Nenhuma nova construção de linguagem ou artefatos de compilação complexos são introduzidos. É apenas o aproveitamento de recursos fundamentais de tipo do TypeScript.
• Acesso Direto ao Valor: Você trabalha diretamente com os valores de string ou número, o que simplifica a serialização e desserialização, especialmente ao interagir com APIs ou bancos de dados que esperam identificadores de string específicos.

Desvantagens de Union Types com Literais

Embora poderosos, os union types também têm algumas limitações:

• Repetição para Dados Associados: Se você precisar associar dados adicionais ou metadados a cada membro "enum" (por exemplo, um rótulo de exibição, um ícone, uma cor), você não pode fazer isso diretamente dentro da definição do union type. Você normalmente precisaria de um objeto de mapeamento separado.
• Sem Iteração Direta de Todos os Valores: Não há uma maneira integrada de obter um array de todos os valores possíveis de um union type em tempo de execução. Por exemplo, você não pode obter facilmente ["PENDING", "IN_PROGRESS", "COMPLETED", "FAILED"] diretamente de JobStatus. Isso muitas vezes exige a manutenção de um array separado de valores se você precisar exibi-los em uma UI (por exemplo, um menu suspenso).
• Menos Centralizado: Se o conjunto de valores for necessário tanto como um tipo quanto como um array de valores em tempo de execução, você pode se encontrar definindo a lista duas vezes (uma como tipo, uma como array em tempo de execução), o que pode introduzir potencial para dessincronização.

Apesar dessas desvantagens, para muitos cenários, os union types fornecem uma solução limpa, performática e type-safe que se alinha bem com as práticas modernas de desenvolvimento JavaScript.

Alternativa 2: Const Assertions (as const)

A asserção as const, introduzida no TypeScript 3.4, é outra ferramenta incrivelmente poderosa que oferece uma excelente alternativa aos enums, especialmente quando você precisa de um objeto em tempo de execução e inferência de tipo robusta. Ela permite que o TypeScript infira o tipo mais estreito possível para expressões literais.

O que são Const Assertions?

Quando você aplica as const a uma variável, um array ou um literal de objeto, o TypeScript trata todas as propriedades dentro desse literal como readonly e infere seus tipos literais em vez de tipos mais amplos (por exemplo, "foo" em vez de string, 123 em vez de number). Isso torna possível derivar tipos de união altamente específicos de estruturas de dados em tempo de execução.

Exemplo Prático: Criando um Objeto "Pseudo-Enum" com as const

Vamos revisitar nosso exemplo de status de job. Com as const, podemos definir uma única fonte de verdade para nossos status, que atua tanto como um objeto em tempo de execução quanto como base para definições de tipo.

            const JobStatuses = {
  PENDING: "PENDING",
  IN_PROGRESS: "IN_PROGRESS",
  COMPLETED: "COMPLETED",
  FAILED: "FAILED",
} as const;

// JobStatuses.PENDING é agora inferido como tipo "PENDING" (não apenas string)
// JobStatuses é inferido como tipo {
//   readonly PENDING: "PENDING";
//   readonly IN_PROGRESS: "IN_PROGRESS";
//   readonly COMPLETED: "COMPLETED";
//   readonly FAILED: "FAILED";
// }

            

              
                Copy
              
            
          

Neste ponto, JobStatuses é um objeto JavaScript em tempo de execução, assim como um enum regular. No entanto, sua inferência de tipo é muito mais precisa.

Combinando com typeof e keyof para Union Types

O verdadeiro poder emerge quando combinamos as const com os operadores typeof e keyof do TypeScript para derivar um tipo de união dos valores ou chaves do objeto.

            const JobStatuses = {
  PENDING: "PENDING",
  IN_PROGRESS: "IN_PROGRESS",
  COMPLETED: "COMPLETED",
  FAILED: "FAILED",
} as const;

// Tipo representando as chaves (por exemplo, "PENDING" | "IN_PROGRESS" | ...)
type JobStatusKeys = keyof typeof JobStatuses;

// Tipo representando os valores (por exemplo, "PENDING" | "IN_PROGRESS" | ...)
type JobStatusValues = typeof JobStatuses[keyof typeof JobStatuses];

function processJobWithConstAssertion(status: JobStatusValues): void {
  if (status === JobStatuses.COMPLETED) {
    console.log("Job finished successfully.");
  } else if (status === JobStatuses.FAILED) {
    console.log("Job encountered an error.");
  } else {
    console.log(`Job is currently ${status}.`);
  }
}

let currentJobStatusFromObject: JobStatusValues = JobStatuses.IN_PROGRESS;
processJobWithConstAssertion(currentJobStatusFromObject);

// Isso resultaria em um erro em tempo de compilação:
// let invalidStatusFromObject: JobStatusValues = "CANCELLED"; // Erro!

            

              
                Copy
              
            
          

Este padrão oferece o melhor dos dois mundos: um objeto em tempo de execução para iteração ou acesso direto à propriedade e um tipo de união em tempo de compilação para verificação rigorosa de tipos.

Benefícios de Const Assertions com Union Types Derivados

• Única Fonte de Verdade: Você define suas constantes uma vez em um objeto JavaScript simples, e deriva tanto o acesso em tempo de execução quanto os tipos em tempo de compilação dele. Isso reduz significativamente a duplicação e melhora a manutenibilidade em equipes de desenvolvimento diversas.
• Segurança de Tipo: Semelhante aos union types puros, você obtém excelente segurança de tipo, garantindo que apenas valores predefinidos sejam usados.
• Iterabilidade em Tempo de Execução: Como JobStatuses é um objeto JavaScript padrão, você pode facilmente iterar sobre suas chaves ou valores usando métodos JavaScript padrão como Object.keys(), Object.values() ou Object.entries(). Isso é inestimável para UIs dinâmicas (por exemplo, preencher dropdowns) ou logging.
• Dados Associados: Este padrão suporta naturalmente a associação de dados adicionais a cada membro "enum".
• Melhor Potencial de Tree-Shaking (Comparado a Enums): Embora as const crie um objeto em tempo de execução, é um objeto JavaScript padrão. Bundlers modernos geralmente são mais eficazes em tree-shaking de propriedades não utilizadas ou até mesmo objetos inteiros se eles não forem referenciados, em comparação com a saída de compilação de enum do TypeScript. No entanto, se o objeto for grande e apenas algumas propriedades forem usadas, o objeto inteiro ainda poderá ser incluído se for importado de uma maneira que impeça tree-shaking granular.
• Flexibilidade: Você pode definir valores que não são apenas strings ou números, mas objetos mais complexos, se necessário, tornando este um padrão altamente flexível.

            const FileOperations = {
  UPLOAD: {
    label: "Upload File",
    icon: "upload-icon.svg",
    permission: "can_upload"
  },
  DOWNLOAD: {
    label: "Download File",
    icon: "download-icon.svg",
    permission: "can_download"
  },
  DELETE: {
    label: "Delete File",
    icon: "delete-icon.svg",
    permission: "can_delete"
  },
} as const;

type FileOperationType = keyof typeof FileOperations; // "UPLOAD" | "DOWNLOAD" | "DELETE"
type FileOperationDetail = typeof FileOperations[keyof typeof FileOperations]; // { label: string; icon: string; permission: string; }

function performOperation(opType: FileOperationType) {
  const details = FileOperations[opType];
  console.log(`Performing: ${details.label} (Permission: ${details.permission})`);
}

performOperation("UPLOAD");

            

              
                Copy
              
            
          

Desvantagens de Const Assertions

• Presença de Objeto em Tempo de Execução: Ao contrário dos union types puros, esta abordagem ainda cria um objeto JavaScript em tempo de execução. Embora seja um objeto padrão e muitas vezes melhor para tree-shaking do que objetos de enum do TypeScript, ele não é inteiramente apagado.
• Definição de Tipo Ligeiramente Mais Verbosa: Derivar o tipo de união (keyof typeof ... ou typeof ...[keyof typeof ...]) requer um pouco mais de sintaxe do que simplesmente listar literais para um union type.
• Potencial de Mau Uso: Se não for usado com cuidado, um objeto as const muito grande ainda poderá contribuir significativamente para o tamanho do bundle se seus conteúdos não forem efetivamente tree-shakeados entre os limites do módulo.

Para cenários onde você precisa de verificação de tipo em tempo de compilação e uma coleção em tempo de execução de valores que podem ser iterados ou fornecer dados associados, as const é frequentemente a escolha preferida entre desenvolvedores TypeScript em todo o mundo.

Comparando as Alternativas: Quando Usar o Quê?

A escolha entre union types e const assertions depende largamente dos seus requisitos específicos em relação à presença em tempo de execução, iterabilidade e se você precisa associar dados adicionais às suas constantes. Vamos detalhar os fatores de tomada de decisão.

Simplicidade vs. Robustez

• Union Types: Oferecem simplicidade máxima quando você precisa apenas de um conjunto type-safe de valores de string ou numéricos distintos em tempo de compilação. São a opção mais leve.
• Const Assertions: Fornecem um padrão mais robusto quando você precisa de segurança de tipo em tempo de compilação e um objeto em tempo de execução que possa ser consultado, iterado ou estendido com metadados adicionais. A configuração inicial é ligeiramente mais verbosa, mas compensa em recursos.

Presença em Tempo de Execução vs. Tempo de Compilação

• Union Types: São construções puramente de tempo de compilação. Eles não geram absolutamente nenhum código JavaScript. Isso é ideal para aplicações onde minimizar o tamanho do bundle é primordial, e os valores em si são suficientes sem a necessidade de acessá-los como um objeto em tempo de execução.
• Const Assertions: Geram um objeto JavaScript padrão em tempo de execução. Este objeto é acessível e utilizável em seu código JavaScript. Embora adicione ao tamanho do bundle, geralmente é mais eficiente do que os enums do TypeScript e melhores candidatos para tree-shaking.

Requisitos de Iterabilidade

• Union Types: Não oferecem uma maneira direta de iterar sobre todos os valores possíveis em tempo de execução. Se você precisar popular um menu suspenso ou exibir todas as opções, precisará definir um array separado desses valores, potencialmente levando à duplicação.
• Const Assertions: Excel aqui. Como você está trabalhando com um objeto JavaScript padrão, você pode facilmente usar Object.keys(), Object.values() ou Object.entries() para obter um array de chaves, valores ou pares chave-valor, respectivamente. Isso os torna perfeitos para UIs dinâmicas ou qualquer cenário que exija enumeração em tempo de execução.

            const PaymentMethods = {
  CREDIT_CARD: "Credit Card",
  PAYPAL: "PayPal",
  BANK_TRANSFER: "Bank Transfer",
} as const;

type PaymentMethodType = keyof typeof PaymentMethods;

// Obter todas as chaves (por exemplo, para lógica interna)
const methodKeys = Object.keys(PaymentMethods) as PaymentMethodType[];
console.log(methodKeys); // ["CREDIT_CARD", "PAYPAL", "BANK_TRANSFER"]

// Obter todos os valores (por exemplo, para exibição em um dropdown)
const methodLabels = Object.values(PaymentMethods);
console.log(methodLabels); // ["Credit Card", "PayPal", "Bank Transfer"]

// Obter pares chave-valor (por exemplo, para mapeamento)
const methodEntries = Object.entries(PaymentMethods);
console.log(methodEntries); // [["CREDIT_CARD", "Credit Card"], ...]

            

              
                Copy
              
            
          

Implicações de Tree-Shaking

• Union Types: São inerentemente tree-shakeables, pois são apenas de tempo de compilação.
• Const Assertions: Embora criem um objeto em tempo de execução, bundlers modernos podem frequentemente tree-shakear propriedades não utilizadas deste objeto de forma mais eficaz do que com objetos de enum gerados pelo TypeScript. No entanto, se o objeto inteiro for importado e referenciado, ele provavelmente será incluído. Um design de módulo cuidadoso pode ajudar.

Melhores Práticas e Abordagens Híbridas

Nem sempre é uma situação de "ou/ou". Frequentemente, a melhor solução envolve uma abordagem híbrida, especialmente em aplicações grandes e internacionalizadas:

• Para flags ou identificadores internos simples e puramente internos que nunca precisam ser iterados ou ter dados associados, Union Types são geralmente a escolha mais performática e limpa.
• Para conjuntos de constantes que precisam ser iterados, exibidos em UIs ou ter metadados associados ricos (como rótulos, ícones ou permissões), o padrão Const Assertions é superior.
• Combinando para Legibilidade e Localização: Muitas equipes usam as const para os identificadores internos e, em seguida, derivam rótulos de exibição localizados de um sistema de internacionalização (i18n) separado.

            // src/constants/order-status.ts
const OrderStatuses = {
  PENDING: "PENDING",
  PROCESSING: "PROCESSING",
  SHIPPED: "SHIPPED",
  DELIVERED: "DELIVERED",
  CANCELLED: "CANCELLED",
} as const;

type OrderStatus = typeof OrderStatuses[keyof typeof OrderStatuses];

export { OrderStatuses, type OrderStatus };

// src/i18n/en.json
{
  "orderStatus": {
    "PENDING": "Pending Confirmation",
    "PROCESSING": "Processing Order",
    "SHIPPED": "Shipped",
    "DELIVERED": "Delivered",
    "CANCELLED": "Cancelled"
  }
}

// src/components/OrderStatusDisplay.tsx
import { OrderStatuses, type OrderStatus } from "../constants/order-status";
import { useTranslation } from "react-i18next"; // Biblioteca i18n de exemplo

interface OrderStatusDisplayProps {
  status: OrderStatus;
}

function OrderStatusDisplay({ status }: OrderStatusDisplayProps) {
  const { t } = useTranslation();
  const displayLabel = t(`orderStatus.${status}`);
  return <span>Status: {displayLabel}</span>;
}

// Uso:
// <OrderStatusDisplay status={OrderStatuses.DELIVERED} />

            

              
                Copy
              
            
          

Essa abordagem híbrida aproveita a segurança de tipo e a iterabilidade em tempo de execução de as const, mantendo as strings de exibição localizadas separadas e gerenciáveis, uma consideração crítica para aplicações globais.

Padrões Avançados e Considerações

Além do uso básico, tanto union types quanto const assertions podem ser integrados em padrões mais sofisticados para aprimorar ainda mais a qualidade e a manutenibilidade do código.

Usando Type Guards com Union Types

Ao trabalhar com union types, especialmente quando a união inclui tipos diversos (não apenas literais), type guards se tornam essenciais para restringir os tipos. Com union types literais, discriminated unions oferecem imenso poder.

            type SuccessEvent = { type: "SUCCESS"; data: any; };
type ErrorEvent = { type: "ERROR"; message: string; code: number; };

type SystemEvent = SuccessEvent | ErrorEvent;

function handleSystemEvent(event: SystemEvent) {
  if (event.type === "SUCCESS") {
    console.log("Data received:", event.data);
    // event é agora restrito a SuccessEvent
  } else {
    console.log("Error occurred:", event.message, "Code:", event.code);
    // event é agora restrito a ErrorEvent
  }
}

handleSystemEvent({ type: "SUCCESS", data: { user: "Alice" } });
handleSystemEvent({ type: "ERROR", message: "Network failure", code: 503 });

            

              
                Copy
              
            
          

Este padrão, frequentemente chamado de "discriminated unions", é incrivelmente robusto e type-safe, fornecendo garantias em tempo de compilação sobre a estrutura dos seus dados com base em uma propriedade literal comum (o discriminador).

Object.values() com as const e Type Assertions

Ao usar o padrão as const, Object.values() pode ser muito útil. No entanto, a inferência padrão do TypeScript para Object.values() pode ser mais ampla do que o desejado (por exemplo, string[] em vez de uma união específica de literais). Você pode precisar de uma asserção de tipo para maior rigor.

            const Statuses = {
  ACTIVE: "Active",
  INACTIVE: "Inactive",
  PENDING: "Pending",
} as const;

type StatusValue = typeof Statuses[keyof typeof Statuses]; // "Active" | "Inactive" | "Pending"

// Object.values(Statuses) é inferido como (string | "Active" | "Inactive" | "Pending")[]
// Podemos afirmar que é mais restrito, se necessário:
const allStatusValues: StatusValue[] = Object.values(Statuses);

console.log(allStatusValues); // ["Active", "Inactive", "Pending"]

// Para um dropdown, você pode parear valores com rótulos se eles diferirem
const statusOptions = Object.entries(Statuses).map(([key, value]) => ({
  value: key, // Use a chave como identificador real
  label: value // Use o valor como rótulo de exibição
}));
console.log(statusOptions);
/*
[
  { value: "ACTIVE", label: "Active" },
  { value: "INACTIVE", label: "Inactive" },
  { value: "PENDING", label: "Pending" }
]
*/

            

              
                Copy
              
            
          

Isso demonstra como obter um array fortemente tipado de valores adequado para elementos de UI, mantendo os tipos literais.

Internacionalização (i18n) e Rótulos Localizados

Para aplicações globais, gerenciar strings localizadas é primordial. Enquanto os enums do TypeScript e suas alternativas fornecem identificadores internos, os rótulos de exibição frequentemente precisam ser separados para i18n. O padrão as const complementa maravilhosamente os sistemas de i18n.

Você define seus identificadores internos e imutáveis usando as const. Esses identificadores são consistentes em todos os locais e servem como chaves para seus arquivos de tradução. As strings de exibição reais são então recuperadas de uma biblioteca de i18n (por exemplo, react-i18next, vue-i18n, FormatJS) com base no idioma selecionado pelo usuário.

            // app/features/product/constants.ts
export const ProductCategories = {
  ELECTRONICS: "ELECTRONICS",
  APPAREL: "APPAREL",
  HOME_GOODS: "HOME_GOODS",
  BOOKS: "BOOKS",
} as const;

export type ProductCategory = typeof ProductCategories[keyof typeof ProductCategories];

// app/i18n/locales/en.json
{
  "productCategories": {
    "ELECTRONICS": "Electronics",
    "APPAREL": "Apparel & Accessories",
    "HOME_GOODS": "Home Goods",
    "BOOKS": "Books"
  }
}

// app/i18n/locales/es.json
{
  "productCategories": {
    "ELECTRONICS": "Electrónica",
    "APPAREL": "Ropa y Accesorios",
    "HOME_GOODS": "Artículos para el hogar",
    "BOOKS": "Libros"
  }
}

// app/components/ProductCategorySelector.tsx
import { ProductCategories, type ProductCategory } from "../features/product/constants";
import { useTranslation } from "react-i18next";

function ProductCategorySelector() {
  const { t } = useTranslation();

  return (
    <select>
      {Object.values(ProductCategories).map(categoryKey => (
        <option key={categoryKey} value={categoryKey}>
          {t(`productCategories.${categoryKey}`)}
        </option>
      ))}
    </select>
  );
}

            

              
                Copy
              
            
          

Essa separação de preocupações é crucial para aplicações globais escaláveis. Os tipos do TypeScript garantem que você esteja sempre usando chaves válidas, e o sistema de i18n cuida da camada de apresentação com base no local do usuário. Isso evita ter strings dependentes de idioma diretamente embutidas na lógica principal da sua aplicação, um anti-padrão comum para equipes internacionais.

Conclusão: Capacitando Suas Escolhas de Design em TypeScript

À medida que o TypeScript continua a evoluir e capacitar desenvolvedores em todo o mundo a construir aplicações mais robustas e escaláveis, entender seus recursos e alternativas nuançados torna-se cada vez mais importante. Embora a palavra-chave enum do TypeScript ofereça uma maneira conveniente de definir constantes nomeadas, seu custo em tempo de execução, limitações de tree-shaking e complexidades de mapeamento reverso frequentemente tornam as alternativas modernas mais atraentes para projetos sensíveis à performance ou de larga escala.

Union Types com Literais de String/Numéricos se destacam como a solução mais leve e centrada em tempo de compilação. Eles fornecem segurança de tipo intransigente sem gerar nenhum JavaScript em tempo de execução, tornando-os ideais para cenários onde o tamanho mínimo do bundle e o tree-shaking máximo são prioridades, e a enumeração em tempo de execução não é uma preocupação.

Por outro lado, Const Assertions (as const) combinadas com typeof e keyof oferecem um padrão altamente flexível e poderoso. Eles fornecem uma única fonte de verdade para suas constantes, forte segurança de tipo em tempo de compilação e a capacidade crítica de iterar sobre valores em tempo de execução. Essa abordagem é particularmente bem adequada para situações onde você precisa associar dados adicionais às suas constantes, popular UIs dinâmicas ou integrar-se perfeitamente com sistemas de internacionalização.

Ao considerar cuidadosamente os trade-offs – custo em tempo de execução, necessidades de iterabilidade e complexidade de dados associados – você pode tomar decisões informadas que levam a código TypeScript mais limpo, eficiente e manutenível. Abraçar essas alternativas não é apenas sobre escrever TypeScript "moderno"; é sobre fazer escolhas arquiteturais deliberadas que aprimoram a performance, a experiência do desenvolvedor e a sustentabilidade a longo prazo de sua aplicação para um público global.

Capacite seu desenvolvimento em TypeScript escolhendo a ferramenta certa para o trabalho certo, indo além do enum padrão quando alternativas melhores existem.