Functional programming en TypeScript: las abstracciones que realmente uso y las que abandoné

Hay un momento específico que reconozco en casi todo developer que llega a TypeScript desde un background de lenguajes tipados: abrís la documentación de fp-ts, ves pipe, Option, TaskEither, ReaderTaskEither y pensás "esto es lo que me faltaba". El type checker te respalda. La API es hermosa. La teoría es sólida.

Tres semanas después, el PR tiene 800 líneas de cambio y un comentario de un compañero que dice: "¿qué hace fold acá?".

Mi tesis es esta: los patrones funcionales tienen valor real en TypeScript, pero la adopción total de fp-ts tiene un costo de onboarding que casi nadie menciona cuando evangeliza la librería. El criterio que terminé usando —después de evaluar la adopción completa y descartarla— es: adoptá los patrones, no la librería, salvo que el equipo entero esté alineado y dispuesto a sostenerlo.

No soy anti-FP. Uso pipe, tengo un Result type casero y pienso en funciones puras cuando puedo. Pero hay una diferencia entre escribir código funcional y adoptar un framework de categorías matemáticas en un proyecto colaborativo.

---

Qué dice fp-ts y qué no dice

fp-ts es una librería de Giulio Canti que porta conceptos de Haskell y Scala a TypeScript con tipos correctos: functores, mónadas, applicatives, la trilogía completa. La documentación es rigurosa. Los tipos son precisos. Y si venís de Haskell, la API te resulta familiar casi de inmediato.

Lo que la documentación no dice —porque no le corresponde decirlo— es cuánto cuesta incorporarla en un equipo donde la mitad nunca escribió Haskell, donde los PRs se revisan bajo presión de sprint, y donde el onboarding de un dev nuevo tiene que medirse en días, no en semanas de teoría de categorías.

fp-ts requiere internalizar:

• El modelo de tipos algebraicos (Either, Option, Task)
• La diferencia entre map, chain y ap
• Cómo pipe compone funciones con esos tipos
• Por qué TaskEither existe y qué problema resuelve vs. un Promise<Result<T, E>>

Eso no es un problema de la librería. Es un trade-off que existe y que vale la pena nombrar antes de abrir un PR.

---

Los tres patrones que sí sobrevivieron

1. pipe — composición sin magia

pipe no necesita fp-ts. TypeScript tiene Array.prototype y podés implementar una versión mínima en diez líneas. La idea es simple: una serie de transformaciones encadenadas, de izquierda a derecha, donde cada función recibe el output de la anterior.

// pipe minimal — sin dependencias externas
function pipe<A>(value: A): A;
function pipe<A, B>(value: A, fn1: (a: A) => B): B;
function pipe<A, B, C>(value: A, fn1: (a: A) => B, fn2: (b: B) => C): C;
function pipe(value: unknown, ...fns: Array<(x: unknown) => unknown>): unknown {
  return fns.reduce((acc, fn) => fn(acc), value);
}

// Uso real: transformar un objeto de base de datos antes de devolverlo
const toPublicUser = (raw: RawUserRow) =>
  pipe(
    raw,
    normalizarFechas,      // Date → string ISO
    ocultarCamposInternos, // quitar campos sensibles
    agregarMetadata        // agregar campos calculados
  );

Esto lo entendé cualquier dev en su primera lectura. No requiere conocer mónadas. El beneficio es concreto: eliminás las variables intermedias const step1 = ...; const step2 = ... y hacés explícito el orden de las transformaciones.

Sobrevivió porque el costo de adopción es casi cero y el beneficio de legibilidad es inmediato.

2. Result<T, E> — manejo explícito de errores sin excepciones

Este es el patrón que más valor me trajo y el que más le cuesta a los equipos que vienen de un mundo try/catch puro.

La idea: en lugar de lanzar excepciones, una función que puede fallar devuelve Result<T, E> — ya sea un valor exitoso (Ok) o un error con tipo (Err).

// Definición mínima — sin fp-ts, sin dependencias
type Ok<T> = { ok: true; value: T };
type Err<E> = { ok: false; error: E };
type Result<T, E = Error> = Ok<T> | Err<E>;

// Constructores
const ok = <T>(value: T): Ok<T> => ({ ok: true, value });
const err = <E>(error: E): Err<E> => ({ ok: false, error });

// Uso en un Server Action de Next.js
async function guardarPerfil(
  input: unknown
): Promise<Result<UserProfile, ValidationError | DatabaseError>> {
  const parsed = profileSchema.safeParse(input);
  if (!parsed.success) {
    return err({ type: "validation", issues: parsed.error.issues });
  }

  try {
    const user = await db.user.update({ where: { id: parsed.data.id }, data: parsed.data });
    return ok(user);
  } catch (e) {
    return err({ type: "database", cause: e });
  }
}

// En el llamador — el type checker obliga a manejar ambos casos
const result = await guardarPerfil(formData);
if (!result.ok) {
  // TypeScript sabe que result.error es ValidationError | DatabaseError
  return handleError(result.error);
}
// Acá TypeScript sabe que result.value es UserProfile
return result.value;

¿Por qué no Either de fp-ts? Porque Either<E, A> requiere conocer la convención de que el error va a la izquierda, entender fold, mapLeft, chain. Con Result casero, cualquier dev que haya visto una API de Rust o un patrón ok/error lo entiende en un minuto.

El trade-off honesto: perdés la capacidad de componer errores con chain de manera elegante. Si necesitás encadenar cinco operaciones que pueden fallar, fp-ts TaskEither es más expresivo. Para el caso común —una función que puede fallar con dos tipos de error— el tipo casero gana en fricción cero.

3. Funciones puras donde el estado no es necesario

Este no es un patrón de librería. Es una disciplina de diseño.

Cuando escribo helpers de transformación, validación o formateo, los escribo como funciones puras: mismo input, mismo output, sin efectos. El beneficio es testabilidad instantánea — no necesitás mocks, no necesitás setup.

// Función pura — testeable sin setup
function formatearPrecio(
  centavos: number,
  opciones: { moneda: string; locale: string }
): string {
  return new Intl.NumberFormat(opciones.locale, {
    style: "currency",
    currency: opciones.moneda,
  }).format(centavos / 100);
}

// Test sin mocks, sin beforeEach, sin dependencias
expect(formatearPrecio(1099, { moneda: "ARS", locale: "es-AR" })).toBe("$ 10,99");

Esto no requiere fp-ts. Requiere disciplina para separar la lógica pura de los efectos (IO, base de datos, fechas del sistema).

---

Lo que abandoné y por qué

TaskEither para async/await

TaskEither<E, A> de fp-ts es una mónada que combina Task (operación asincrónica) con Either (resultado que puede fallar). En teoría, es la solución perfecta para funciones async que pueden fallar con tipos.

En práctica, en un proyecto con Next.js Server Actions y Prisma, agregar TaskEither significaba reescribir toda la capa de acceso a datos en un estilo que el resto del equipo no reconocía. El tipo de error que TypeScript te da cuando fallás al componer TaskEither correctamente no es amigable para alguien que nunca vio la librería.

Terminé con Promise<Result<T, E>> — que es conceptualmente idéntico pero sin la deuda de onboarding.

Option<A> como reemplazo de null/undefined

Option (o Maybe) es el patrón para valores que pueden no existir. La idea es que en lugar de string | null, usás Option<string> y operás con map, getOrElse, fold.

El problema en TypeScript 5.x con strictNullChecks activado: string | null ya es seguro a nivel de tipos. El compilador te obliga a hacer el check antes de usar el valor. La mayoría del equipo ya maneja null y undefined con optional chaining (?.) y nullish coalescing (??).

Agregar Option<A> encima de eso es una abstracción sobre una abstracción que TypeScript ya resolvió. No lo adopté.

Mónadas de Reader/State para inyección de dependencias

ReaderTaskEither es potencialmente el pináculo de fp-ts para aplicaciones reales: combina dependencias inyectadas (Reader), estado asincrónico (Task), y errores tipados (Either). La API tiene una curva de aprendizaje que, sin exagerar, requiere semanas para un dev que viene de OOP.

Evalualo si tenés un equipo donde todos tienen background funcional y el proyecto lo justifica. En un equipo mixto, es un pasivo, no un activo.

---

La matriz de decisión: cuándo adoptar cada patrón

Antes de adoptar cualquier abstracción funcional, pasala por estos cuatro criterios:

Patrón	¿El equipo lo entiende en < 30 min?	¿TypeScript lo resuelve nativamente?	¿Vale el costo?
pipe (propio)	✅ Sí	No nativo, pero trivial	✅ Siempre
Result<T, E> casero	✅ Sí	No (requiere disciplina)	✅ Cuando hay errores tipados
Funciones puras	✅ Sí	N/A	✅ Siempre que puedas
Option<A> de fp-ts	⚠️ 30-60 min	✅ Sí (`T \	null`)
TaskEither de fp-ts	❌ Días/semanas	No	✅ Solo si el equipo es FP-first
ReaderTaskEither	❌ Semanas	No	⚠️ Solo proyectos FP-first

La regla práctica: si la abstracción requiere que el equipo lea una guía de teoría de categorías antes de hacer un PR de review, el costo de adopción es real y acumulativo.

---

Lo que no podés concluir sin datos propios

Acá es donde tengo que ser honesto sobre los límites de este análisis:

• No tengo números de velocidad de equipo para respaldar "fp-ts ralentiza el onboarding X%". Es un patrón reportado en discusiones del ecosistema, pero la magnitud depende del equipo concreto.
• No puedo afirmar que Result casero escala mejor que Either de fp-ts en proyectos de 100k líneas sin haberlo medido. Para proyectos con composición de errores compleja, fp-ts puede ser mejor.
• La curva de aprendizaje depende del background del equipo. Si todos vienen de Scala, fp-ts es natural. El análisis cambia completamente.

Si querés datos propios: tomá un módulo pequeño, reescribilo con fp-ts completo, sumá a alguien del equipo que no estuvo en la reescritura y medí cuánto tarda en entender el PR sin contexto. Eso te da información concreta para la decisión.

---

FAQ

¿Necesito fp-ts para escribir código funcional en TypeScript?

No. pipe, Result, funciones puras — todos son patrones que podés implementar en 50 líneas sin dependencias. fp-ts es una librería que los formaliza con tipos más estrictos y composición más potente, pero el patrón existe independientemente de la librería.

¿Result<T, E> no es reinventar la rueda?

Es reinventar una rueda más pequeña a propósito. Either<E, A> de fp-ts tiene más capacidad de composición, pero lleva consigo toda la API de la librería. Si no necesitás chain ni sequenceArray, el tipo casero es suficiente y tiene costo de adopción cercano a cero.

¿Cuándo sí adoptaría fp-ts completo?

Si el equipo tiene background funcional (Scala, Haskell, Elm), si el proyecto tiene lógica de dominio compleja con muchas operaciones encadenadas que pueden fallar, y si el onboarding de nuevos devs tiene tiempo para incluir la teoría. No es una decisión de una persona — requiere consenso del equipo.

¿strictNullChecks reemplaza a Option<A>?

Para la mayoría de los casos, sí. TypeScript con strictNullChecks: true te obliga a manejar null y undefined antes de usarlos. Optional chaining (?.) y nullish coalescing (??) cubren el 90% de los casos de uso de Option. El 10% restante — composición elegante de valores opcionales en pipelines largos — es donde Option brilla, pero ese caso no es el más común.

¿pipe no es lo mismo que encadenar métodos?

Conceptualmente similar, pero con una diferencia importante: pipe trabaja con funciones libres, no con métodos de objeto. Eso significa que podés componer transformaciones sobre cualquier tipo sin necesidad de que el tipo tenga esos métodos. Es más composable y más testeable de forma aislada.

¿Vale la pena aprender fp-ts aunque no lo adopte completamente?

Sí, y esto es lo que más rescato del ejercicio. Estudiar fp-ts me hizo pensar mejor en errores tipados, en la separación entre lógica pura y efectos, y en qué significa "componible". Esos conceptos los uso todos los días aunque no use la librería. El aprendizaje y la adopción son decisiones independientes.

---

Mi postura y el próximo paso concreto

Empecé queriendo escribir Haskell en TypeScript. Terminé con tres cosas: un pipe de 15 líneas, un Result<T, E> de 10 líneas, y la disciplina de separar funciones puras de efectos. No es glamoroso. Sí es mantenible.

fp-ts es una librería seria, bien diseñada y con una comunidad activa. Si evaluás adoptarla, leé la documentación oficial — en particular la sección de guías — antes de decidir. Lo que vas a encontrar es poderoso. La pregunta es si el equipo completo puede sostenerlo.

Mi recomendación práctica para este momento: si estás evaluando FP en TypeScript, empezá por los tres patrones que sobrevivieron. Implementalos vos mismo en una tarde — no instales nada. Cuando esos patrones te resulten insuficientes para la complejidad que tenés, ahí sí evaluá fp-ts en serio, con el equipo, con un módulo piloto y con criterios de aceptación claros.

Si te interesa cómo el manejo explícito de errores conecta con otros niveles del stack, el post sobre Spring Boot Actuator y qué exponer tiene una perspectiva similar: decidir con criterio qué mostrás y qué no. Y si trabajás en un entorno con múltiples servicios, OpenTelemetry en Next.js muestra cómo el contexto que perdés en el edge tiene el mismo patrón de "abstracción que fuga" que las mónadas mal usadas.

---

Fuente original:

• fp-ts documentation: https://gcanti.github.io/fp-ts/

---

Este artículo fue publicado originalmente en juanchi.dev