JavaScript
Reúne prácticas para validar fronteras, proteger invariantes, aislar efectos y diseñar errores, estados parciales, reintentos y dependencias explícitas.
El código confiable no es código que nunca falla. Es código que:
entrada incierta
↓
frontera validada
↓
núcleo predecible
↓
efectos controlados
↓
respuesta o error explícitoUna función debe comunicar qué recibe, qué devuelve y cómo falla.
function requireProduct(products, productId) {
const product = products.find(
(candidate) => candidate.id === productId,
);
if (!product) {
throw new ProductNotFoundError(productId);
}
return product;
}El nombre requireProduct comunica que la ausencia no es un resultado normal.
Contrasta con:
function findProduct(products, productId) {
return (
products.find(
(candidate) => candidate.id === productId,
) ?? null
);
}Las dos APIs son válidas porque expresan contratos distintos.
const product = parseProduct(request.body);Después de esa línea, el núcleo puede confiar en una forma controlada.
Sin una frontera:
function calculateTotal(product) {
const price = Number(product.price);
// Cada función vuelve a interpretar el dato.
}Con frontera:
function calculateTotal(product) {
return product.price * product.quantity;
}La complejidad se concentra donde entra la incertidumbre.
Una invariante es una condición que debe mantenerse para que un valor siga siendo válido.
class InventoryItem {
#stock;
constructor(initialStock) {
this.#assertStock(initialStock);
this.#stock = initialStock;
}
decrease(quantity) {
this.#assertStock(
this.#stock - quantity,
);
this.#stock -= quantity;
}
#assertStock(value) {
if (!Number.isInteger(value) || value < 0) {
throw new RangeError(
"Stock cannot be negative",
);
}
}
}La regla no depende de que cada consumidor recuerde comprobarla.
Menos confiable:
const request = {
isLoading: false,
hasError: true,
data: products,
};¿Puede existir data y error al mismo tiempo? ¿Qué significa isLoading junto con ambos?
Un modelo de estados:
const request = {
status: "error",
error,
};switch (request.status) {
case "idle":
case "loading":
case "success":
case "error":
}Una representación clara hace más difíciles las combinaciones imposibles.
function calculateOrderTotal(items) {
return items.reduce(
(total, item) =>
total + item.price * item.quantity,
0,
);
}La función no lee hora, red, globals ni almacenamiento. Con las mismas entradas produce el mismo resultado.
Esto facilita:
No todo puede ser puro. La idea es mantener los efectos en capas reconocibles.
async function checkout(input, dependencies) {
const order = parseOrder(input);
const total = calculateOrderTotal(order.items);
const payment = await dependencies.payments.pay({
orderId: order.id,
total,
});
await dependencies.orders.save({
...order,
total,
paymentId: payment.id,
});
}Validación y cálculo son claros. Red y persistencia aparecen como dependencias explícitas.
Difícil de probar:
function createReport(data) {
globalLogger.info("Creating report");
return globalFormatter.format(data);
}Más explícito:
function createReport(
data,
{ logger, formatter },
) {
logger.info("Creating report");
return formatter.format(data);
}Las dependencias dejan de estar ocultas y pueden sustituirse durante pruebas.
function createProduct(input) {
const product = {
name: input.name,
price: input.price,
};
// El dato inválido viaja.
}Mejor:
function createProduct(input) {
const product = parseProduct(input);
return product;
}Un error cerca del origen suele tener mejor contexto y evita que el programa construya estados parciales.
Dentro del sistema:
throw new RepositoryUnavailableError(
"Product query timed out",
{ cause },
);En la interfaz:
No pudimos cargar los productos. Inténtalo nuevamente.No ocultes el fallo interno, pero tampoco expongas detalles que el usuario no puede resolver.
VALIDATION_FAILED
NOT_FOUND
CONFLICT
UNAVAILABLE
TIMEOUT
INTERNAL_ERRORUna taxonomía pequeña permite:
No conviertas cada frase en una categoría distinta.
Válido:
try {
return await loadRecommendations();
} catch (error) {
if (error instanceof RecommendationUnavailableError) {
return [];
}
throw error;
}La recomendación es opcional y una lista vacía conserva una experiencia válida.
Engañoso:
try {
return await loadAccountBalance();
} catch {
return 0;
}Un fallo no significa que el saldo sea cero.
Una operación externa no debería esperar indefinidamente.
const controller = new AbortController();
const timeoutId = setTimeout(
() => controller.abort(),
5000,
);
try {
return await fetch(url, {
signal: controller.signal,
});
} finally {
clearTimeout(timeoutId);
}La implementación concreta depende del entorno. El principio es que quien inicia trabajo debe definir cómo termina o se cancela.
AbortController se estudiará en asincronía y APIs del navegador.
No reintentes automáticamente cualquier fallo.
Una lectura puede ser repetible. Un cobro puede duplicarse si el proveedor procesó la solicitud pero la respuesta se perdió.
Necesitas:
await saveOrder(order);
await sendConfirmation(order);Si el correo falla, la orden ya existe.
Modelos posibles:
{
orderStatus: "created",
notificationStatus: "pending",
}La confiabilidad mejora cuando el estado parcial es visible en lugar de fingir atomicidad.
Una operación idempotente puede repetirse sin producir efectos adicionales distintos al primero.
await updateOrderStatus(
orderId,
"completed",
);Puede diseñarse para que repetir el mismo estado no duplique acciones.
Crear un pago, enviar un correo o descontar inventario no son automáticamente idempotentes. Pueden necesitar claves de idempotencia, registros o verificaciones.
function applyDiscount(product) {
return {
...product,
price: product.price * 0.9,
};
}Crear una referencia nueva puede evitar que una capa cambie silenciosamente datos usados por otra.
No copies todo por costumbre. Comprende qué referencias se comparten y define quién puede modificarlas.
Ninguna sustituye el diseño. Un tipo correcto puede contener un valor inválido para el dominio; un test puede no cubrir una condición desconocida.
No pruebes únicamente el camino feliz.
Para una cantidad:
-1
0
1
máximo permitido
máximo + 1
NaN
Infinity
string numérico
null
undefinedLos límites revelan errores de comparación, coerción y defaults.
Cuando un fallo ocurre en producción necesitas responder:
Usa identificadores de correlación y datos seguros. No registres secretos.
function add(a, b) {
if (typeof a !== "number") {
// ...
}
if (typeof b !== "number") {
// ...
}
}Puede ser necesario en una API pública, pero redundante en un núcleo que recibe valores ya validados.
Demasiada validación interna:
Define fronteras de confianza.
Frontera:
function parseCreateOrderInput(input) {
// Normaliza y valida.
}Núcleo:
function createOrder(input) {
// Trabaja con datos confiables.
}Infraestructura:
async function saveOrder(order) {
// Traduce errores del proveedor.
}Límite:
async function handleCreateOrder(request) {
try {
const input = parseCreateOrderInput(
request.body,
);
const order = createOrder(input);
await saveOrder(order);
return toSuccessResponse(order);
} catch (error) {
reportError(error, {
requestId: request.id,
});
return toPublicResponse(error);
}
}Cada parte tiene una responsabilidad identificable.
Antes de considerar confiable un flujo, pregunta:
¿Por qué return 0 no es un fallback seguro cuando falla la consulta del saldo?
Porque transforma “no pudimos conocer el saldo” en “el saldo es cero”. Son estados distintos y el usuario podría tomar decisiones incorrectas basándose en información falsa.
El siguiente bloque estudia asincronía, donde estos principios se aplican a callbacks diferidos, Event Loop, promesas, cancelación y errores que atraviesan límites temporales.