JavaScript Pattern Matching & Type Safety: A Guide to Compile-Time Verification

La coincidencia de patrones es una de las características más poderosas y expresivas en la programación moderna, celebrada durante mucho tiempo en lenguajes funcionales como Haskell, Rust y F#. Permite a los desarrolladores deconstruir datos y ejecutar código basándose en su estructura de una manera que es a la vez concisa e increíblemente legible. A medida que JavaScript continúa evolucionando, los desarrolladores buscan cada vez más adoptar estos poderosos paradigmas. Sin embargo, sigue existiendo un desafío importante: ¿Cómo logramos la sólida seguridad de tipos y las garantías en tiempo de compilación de estos lenguajes en el mundo dinámico de JavaScript?

La respuesta está en aprovechar el sistema de tipos estáticos de TypeScript. Si bien JavaScript en sí se está acercando a la coincidencia de patrones nativa, su naturaleza dinámica significa que cualquier verificación se realizaría en tiempo de ejecución, lo que podría generar errores inesperados en la producción. Este artículo es una inmersión profunda en las técnicas y herramientas que permiten la verdadera verificación de patrones en tiempo de compilación, lo que garantiza que detecte los errores no cuando lo hagan sus usuarios, sino cuando escriba.

Exploraremos cómo construir sistemas sólidos, autodocumentados y resistentes a errores combinando las potentes funciones de TypeScript con la elegancia de la coincidencia de patrones. Prepárese para eliminar toda una clase de errores en tiempo de ejecución y escribir código que sea más seguro y fácil de mantener.

¿Qué es exactamente la coincidencia de patrones?

En esencia, la coincidencia de patrones es un sofisticado mecanismo de flujo de control. Es como una declaración `switch` superpoderosa. En lugar de simplemente verificar la igualdad con valores simples (como números o cadenas), la coincidencia de patrones le permite verificar un valor con 'patrones' complejos y, si se encuentra una coincidencia, vincular variables a partes de ese valor.

Contrastémoslo con los enfoques tradicionales:

La forma antigua: cadenas `if-else` y `switch`

Considere una función que calcula el área de una forma geométrica. Con un enfoque tradicional, su código podría verse así:

            
// Shape is an object with a 'type' property
function calculateArea(shape) {
  if (shape.type === 'circle') {
    return Math.PI * shape.radius * shape.radius;
  } else if (shape.type === 'square') {
    return shape.sideLength * shape.sideLength;
  } else if (shape.type === 'rectangle') {
    return shape.width * shape.height;
  } else {
    throw new Error('Unsupported shape type');
  }
}

            

              
                Copy
              
            
          

Esto funciona, pero es verboso y propenso a errores. ¿Qué sucede si agrega una nueva forma, como un `triángulo`, pero olvida actualizar esta función? El código generará un error genérico en tiempo de ejecución, que podría estar lejos de donde se introdujo el error real.

La forma de coincidencia de patrones: declarativa y expresiva

La coincidencia de patrones replantea esta lógica para que sea más declarativa. En lugar de una serie de comprobaciones imperativas, declara los patrones que espera y las acciones a realizar:

            
// Pseudocode for a future JavaScript pattern matching feature
function calculateArea(shape) {
  match (shape) {
    when ({ type: 'circle', radius }): return Math.PI * radius * radius;
    when ({ type: 'square', sideLength }): return sideLength * sideLength;
    when ({ type: 'rectangle', width, height }): return width * height;
    default: throw new Error('Unsupported shape type');
  }
}

            

              
                Copy
              
            
          

Los beneficios clave son evidentes de inmediato:

• Desestructuración: Los valores como `radius`, `width` y `height` se extraen automáticamente del objeto `shape`.
• Legibilidad: La intención del código es más clara. Cada cláusula `when` describe una estructura de datos específica y su lógica correspondiente.
• Exhaustividad: Este es el beneficio más crucial para la seguridad de tipos. Un sistema de coincidencia de patrones verdaderamente robusto puede advertirle en tiempo de compilación si ha olvidado manejar un caso posible. Este es nuestro objetivo principal.

El desafío de JavaScript: dinamismo frente a seguridad

La mayor fortaleza de JavaScript (su flexibilidad y naturaleza dinámica) es también su mayor debilidad cuando se trata de la seguridad de los tipos. Sin un sistema de tipos estáticos que imponga contratos en tiempo de compilación, la coincidencia de patrones en JavaScript sin formato se limita a las comprobaciones en tiempo de ejecución. Esto significa:

• Sin garantías en tiempo de compilación: No sabrá que omitió un caso hasta que su código se ejecute y llegue a esa ruta específica.
• Fallos silenciosos: Si olvida un caso predeterminado, un valor que no coincide simplemente puede resultar en `undefined`, lo que causa errores sutiles en sentido descendente.
• Pesadillas de refactorización: Agregar una nueva variante a una estructura de datos (por ejemplo, un nuevo tipo de evento, un nuevo estado de respuesta de API) requiere una búsqueda y reemplazo global para encontrar todos los lugares donde debe manejarse. Perderse uno puede interrumpir su aplicación.

Aquí es donde TypeScript cambia el juego por completo. Su sistema de tipos estáticos nos permite modelar nuestros datos con precisión y luego aprovechar el compilador para garantizar que manejemos todas las variaciones posibles. Exploremos cómo.

Técnica 1: La base con uniones discriminadas

La característica de TypeScript más importante para habilitar la coincidencia de patrones con seguridad de tipos es la unión discriminada (también conocida como unión etiquetada o tipo de datos algebraico). Es una forma poderosa de modelar un tipo que puede ser una de varias posibilidades distintas.

¿Qué es una unión discriminada?

Una unión discriminada se construye a partir de tres componentes:

1. Un conjunto de tipos distintos (los miembros de la unión).
2. Una propiedad común con un tipo literal, conocida como discriminante o etiqueta. Esta propiedad permite a TypeScript reducir el tipo específico dentro de la unión.
3. Un tipo de unión que combina todos los tipos de miembros.

Remodelemos nuestro ejemplo de forma usando este patrón:

            
// 1. Define the distinct member types
interface Circle {
  kind: 'circle'; // The discriminant
  radius: number;
}

interface Square {
  kind: 'square'; // The discriminant
  sideLength: number;
}

interface Rectangle {
  kind: 'rectangle'; // The discriminant
  width: number;
  height: number;
}

// 2. Create the union type
type Shape = Circle | Square | Rectangle;

            

              
                Copy
              
            
          

Ahora, una variable de tipo `Shape` debe ser una de estas tres interfaces. La propiedad `kind` actúa como la clave que desbloquea las capacidades de reducción de tipo de TypeScript.

Implementación de la comprobación de exhaustividad en tiempo de compilación

Con nuestra unión discriminada implementada, ahora podemos escribir una función que el compilador garantiza que manejará todas las formas posibles. El ingrediente mágico es el tipo `never` de TypeScript, que representa un valor que nunca debería ocurrir.

Podemos escribir una función de ayuda simple para imponer esto:

            
function assertUnreachable(x: never): never {
  throw new Error("Didn't expect to get here");
}

            

              
                Copy
              
            
          

Ahora, reescribamos nuestra función `calculateArea` usando una declaración `switch` estándar. Observe lo que sucede en el caso `default`:

            
function calculateArea(shape: Shape): number {
  switch (shape.kind) {
    case 'circle':
      // TypeScript knows `shape` is a Circle here!
      return Math.PI * shape.radius ** 2;

    case 'square':
      // TypeScript knows `shape` is a Square here!
      return shape.sideLength ** 2;

    case 'rectangle':
      // TypeScript knows `shape` is a Rectangle here!
      return shape.width * shape.height;

    default:
      // If we've handled all cases, `shape` will be of type `never`
      return assertUnreachable(shape);
  }
}

            

              
                Copy
              
            
          

Este código se compila perfectamente. Dentro de cada bloque `case`, TypeScript ha reducido el tipo de `shape` a `Circle`, `Square` o `Rectangle`, lo que nos permite acceder de forma segura a propiedades como `radius`.

Ahora para el momento mágico. Introduzcamos una nueva forma en nuestro sistema:

            
interface Triangle {
  kind: 'triangle';
  base: number;
  height: number;
}

type Shape = Circle | Square | Rectangle | Triangle; // Add it to the union

            

              
                Copy
              
            
          

Tan pronto como agreguemos `Triangle` a la unión `Shape`, nuestra función `calculateArea` producirá inmediatamente un error en tiempo de compilación:

            
// In the `default` block of `calculateArea`:

return assertUnreachable(shape);
//                      ~~~~~
// Argument of type 'Triangle' is not assignable to parameter of type 'never'.

            

              
                Copy
              
            
          

Este error es increíblemente valioso. El compilador de TypeScript nos dice: "Prometiste manejar todas las posibles `Shape`, pero te olvidaste de `Triangle`. La variable `shape` aún podría ser un `Triangle` en el caso predeterminado, y eso no se puede asignar a `never`".

Para corregir el error, simplemente agregamos el caso que falta. El compilador se convierte en nuestra red de seguridad, garantizando que nuestra lógica permanezca sincronizada con nuestro modelo de datos.

            
// ... inside the switch
    case 'triangle':
      return 0.5 * shape.base * shape.height;

    default:
      return assertUnreachable(shape);
// ... now the code compiles again!

            

              
                Copy
              
            
          

Pros y contras de este enfoque

• Pros:
  • Cero dependencias: Utiliza solo las funciones principales de TypeScript.
  • Máxima seguridad de tipos: Proporciona garantías inquebrantables en tiempo de compilación.
  • Excelente rendimiento: Se compila en una declaración `switch` de JavaScript estándar altamente optimizada.
• Contras:
  • Verbosidad: La plantilla `switch`, `case`, `break`/`return` y `default` puede resultar engorrosa.
  • No es una expresión: Una declaración `switch` no se puede devolver directamente ni asignar a una variable, lo que lleva a estilos de código más imperativos.

Técnica 2: API ergonómicas con bibliotecas modernas

Si bien la unión discriminada con una declaración `switch` es la base, su plantilla puede ser tediosa. Esto ha llevado al auge de fantásticas bibliotecas de código abierto que proporcionan una API más funcional, expresiva y ergonómica para la coincidencia de patrones, al tiempo que aprovechan el compilador de TypeScript para la seguridad.

Presentamos `ts-pattern`

Una de las bibliotecas más populares y potentes en este espacio es `ts-pattern`. Le permite reemplazar las declaraciones `switch` con una API fluida y encadenable que funciona como una expresión.

Reescribamos nuestra función `calculateArea` usando `ts-pattern`:

            
import { match } from 'ts-pattern';

function calculateAreaWithTsPattern(shape: Shape): number {
  return match(shape)
    .with({ kind: 'circle' }, (s) => Math.PI * s.radius ** 2)
    .with({ kind: 'square' }, (s) => s.sideLength ** 2)
    .with({ kind: 'rectangle' }, (s) => s.width * s.height)
    .with({ kind: 'triangle' }, (s) => 0.5 * s.base * s.height)
    .exhaustive(); // This is the key to compile-time safety
}

            

              
                Copy
              
            
          

Analicemos lo que está sucediendo:

• `match(shape)`: Esto inicia la expresión de coincidencia de patrones, tomando el valor que se va a comparar.
• `.with({ kind: '...' }, handler)`: Cada llamada `.with()` define un patrón. `ts-pattern` es lo suficientemente inteligente como para inferir el tipo del segundo argumento (la función `handler`). Para el patrón `{ kind: 'circle' }`, sabe que la entrada `s` al controlador será de tipo `Circle`.
• `.exhaustive()`: Este método es el equivalente a nuestro truco `assertUnreachable`. Le dice a `ts-pattern` que se deben manejar todos los casos posibles. Si tuviéramos que eliminar la línea `.with({ kind: 'triangle' }, ...)`, `ts-pattern` activaría un error en tiempo de compilación en la llamada `.exhaustive()`, diciéndonos que la coincidencia no es exhaustiva.

Funciones avanzadas de `ts-pattern`

`ts-pattern` va mucho más allá de la simple coincidencia de propiedades:

• Coincidencia de predicados con `.when()`: Coincide según una condición.

              
  match(input)
    .when(isString, (str) => `It's a string: ${str}`)
    .when(isNumber, (num) => `It's a number: ${num}`)
    .otherwise(() => 'It is something else');
  
              
  
                
                  Copy
                
              
            

• Patrones profundamente anidados: Coincide con estructuras de objetos complejos.

              
  match(user)
    .with({ address: { city: 'Paris' } }, () => 'User is in Paris')
    .otherwise(() => 'User is elsewhere');
  
              
  
                
                  Copy
                
              
            

• Comodines y selectores especiales: Use `P.select()` para capturar un valor dentro de un patrón, o `P.string`, `P.number` para coincidir con cualquier valor de un determinado tipo.

              
  import { match, P } from 'ts-pattern';
  
  match(event)
    .with({ type: 'USER_LOGIN', user: { name: P.select() } }, (name) => {
      console.log(`${name} logged in.`);
    })
    .otherwise(() => {});
  
              
  
                
                  Copy
                
              
            

Al usar una biblioteca como `ts-pattern`, obtiene lo mejor de ambos mundos: la sólida seguridad en tiempo de compilación de la verificación `never` de TypeScript, combinada con una API limpia, declarativa y altamente expresiva.

El futuro: la propuesta de coincidencia de patrones de TC39

El lenguaje JavaScript en sí está en camino de obtener la coincidencia de patrones nativa. Hay una propuesta activa en TC39 (el comité que estandariza JavaScript) para agregar una expresión `match` al lenguaje.

Sintaxis propuesta

Es probable que la sintaxis se vea así:

            
// This is proposed JavaScript syntax and might change
const getMessage = (response) => {
  return match (response) {
    when ({ status: 200, body: b }) { return `Success with body: ${b}` };
    when ({ status: 404 }) { return 'Not Found'; }
    when ({ status: s if s >= 500 }) { return `Server Error: ${s}` };
    default { return 'Unknown response'; }
  }
};

            

              
                Copy
              
            
          

¿Qué pasa con la seguridad de los tipos?

Esta es la pregunta crucial para nuestra discusión. Por sí sola, una función nativa de coincidencia de patrones de JavaScript realizaría sus comprobaciones en tiempo de ejecución. No sabría acerca de sus tipos de TypeScript.

Sin embargo, es casi seguro que el equipo de TypeScript construiría un análisis estático sobre esta nueva sintaxis. Así como TypeScript analiza las declaraciones `if` y los bloques `switch` para realizar la reducción de tipos, analizaría las expresiones `match`. Esto significa que eventualmente podríamos obtener el mejor resultado posible:

1. Sintaxis nativa y de alto rendimiento: No es necesario usar bibliotecas ni trucos de transpilación.
2. Seguridad total en tiempo de compilación: TypeScript verificaría la expresión `match` para determinar la exhaustividad con respecto a una unión discriminada, tal como lo hace hoy con `switch`.

Mientras esperamos que esta característica avance a través de las etapas de propuesta y llegue a los navegadores y tiempos de ejecución, las técnicas que hemos discutido hoy con uniones discriminadas y bibliotecas son la solución de vanguardia lista para la producción.

Aplicaciones prácticas y mejores prácticas

Veamos cómo se aplican estos patrones a escenarios de desarrollo comunes del mundo real.

Gestión del estado (Redux, Zustand, etc.)

La gestión del estado con acciones es un caso de uso perfecto para las uniones discriminadas. En lugar de usar constantes de cadena para los tipos de acciones, defina una unión discriminada para todas las acciones posibles.

            
// Define actions
interface IncrementAction { type: 'counter/increment'; payload: number; }
interface DecrementAction { type: 'counter/decrement'; payload: number; }
interface ResetAction { type: 'counter/reset'; }

type CounterAction = IncrementAction | DecrementAction | ResetAction;

// A type-safe reducer
function counterReducer(state: number, action: CounterAction): number {
  return match(action)
    .with({ type: 'counter/increment' }, (act) => state + act.payload)
    .with({ type: 'counter/decrement' }, (act) => state - act.payload)
    .with({ type: 'counter/reset' }, () => 0)
    .exhaustive();
}

            

              
                Copy
              
            
          

Ahora, si agrega una nueva acción a la unión `CounterAction`, TypeScript lo obligará a actualizar el reductor. ¡No más controladores de acciones olvidados!

Manejo de respuestas de API

Obtener datos de una API implica múltiples estados: carga, éxito y error. Modelar esto con una unión discriminada hace que la lógica de su interfaz de usuario sea mucho más sólida.

            
// Model the async data state
type RemoteData =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: E };

// In your UI component (e.g., React)
function UserProfile({ userId }: { userId: string }) {
  const [userState, setUserState] = useState>({ status: 'idle' });

  // ... useEffect to fetch data and update state ...

  return match(userState)
    .with({ status: 'idle' }, () => 
Click a button to load the user.
)
    .with({ status: 'loading' }, () => )
    .with({ status: 'success' }, (state) => )
    .with({ status: 'error' }, (state) => )
    .exhaustive();
}

            

              
                Copy
              
            
          

Este enfoque garantiza que ha implementado una interfaz de usuario para cada estado posible de la recuperación de datos. No puede olvidarse accidentalmente de manejar el caso de carga o error.

Resumen de las mejores prácticas

• Modelar con uniones discriminadas: Siempre que tenga un valor que pueda ser una de varias formas distintas, use una unión discriminada. Es la base de los patrones con seguridad de tipos en TypeScript.
• Siempre imponga la exhaustividad: Ya sea que use el truco `never` con una declaración `switch` o el método `.exhaustive()` de una biblioteca, nunca deje una coincidencia de patrones abierta. Aquí es donde proviene la seguridad.
• Elija la herramienta adecuada: Para casos simples, una declaración `switch` está bien. Para lógica compleja, coincidencia anidada o un estilo más funcional, una biblioteca como `ts-pattern` mejorará significativamente la legibilidad y reducirá la plantilla.
• Mantenga los patrones legibles: El objetivo es la claridad. Evite patrones anidados demasiado complejos que sean difíciles de entender de un vistazo. A veces, dividir una coincidencia en funciones más pequeñas es un mejor enfoque.

Conclusión: Escribiendo el futuro del JavaScript seguro

La coincidencia de patrones es más que solo azúcar sintáctica; es un paradigma que conduce a un código más declarativo, legible y, lo que es más importante, más sólido. Si bien esperamos ansiosamente su llegada nativa a JavaScript, no tenemos que esperar para cosechar sus beneficios.

Al aprovechar el poder del sistema de tipos estáticos de TypeScript, particularmente con uniones discriminadas, podemos construir sistemas que sean verificables en tiempo de compilación. Este enfoque cambia fundamentalmente la detección de errores del tiempo de ejecución al tiempo de desarrollo, lo que ahorra incontables horas de depuración y previene incidentes de producción. Bibliotecas como `ts-pattern` se basan en esta sólida base, proporcionando una API elegante y potente que hace que escribir código con seguridad de tipos sea una alegría.

Adoptar la verificación de patrones en tiempo de compilación es un paso hacia la escritura de aplicaciones más resilientes y mantenibles. Le anima a pensar explícitamente en todos los estados posibles en los que pueden estar sus datos, eliminando la ambigüedad y haciendo que la lógica de su código sea cristalina. Comience a modelar su dominio con uniones discriminadas hoy mismo y deje que el compilador de TypeScript sea su socio incansable en la construcción de software sin errores.