Tipos primitivos, arrays y objetos (sin dolor)
Tipos primitivos, arrays y objetos sin dolor
Con un puñado de tipos cubres la mayoría del código que vas a escribir: string, number, boolean, arrays y objetos. La clave no es memorizar sintaxis, sino entender cuándo escribir el tipo y cuándo dejar que TypeScript lo deduzca por ti (eso se llama inferencia).
Deja que la inferencia trabaje
Si inicializas una variable con un valor, no necesitas anotar su tipo: TypeScript ya lo sabe. Anotar de más genera ruido. Anota tipos donde el valor todavía no existe, como parámetros de función o estructuras de datos vacías.
// Redundante: TypeScript ya infiere string
const nombre: string = "María";
// Mejor: deja que infiera
const nombre = "María";
// Aquí SÍ conviene anotar, porque empieza vacío
const ids: string[] = [];Objetos, propiedades opcionales y readonly
El operador ? marca una propiedad como opcional. readonly impide reasignarla después de creada. Y as const convierte un valor en un literal inmutable, útil para uniones.
type Usuario = {
id: string;
nombre: string;
plan: "free" | "pro";
bio?: string; // opcional
readonly creadoEn: string; // no se puede reasignar
};
const usuario: Usuario = {
id: "u_123",
nombre: "María",
plan: "free",
creadoEn: "2026-01-01",
};
const usuarios: Usuario[] = [usuario];Consejo
Si ves que escribes el mismo objeto literal en varios sitios, extráelo a un type con nombre. Un buen nombre de tipo documenta tu intención mejor que un comentario.
¿Qué hace as const?
Convierte el valor en un literal de solo lectura. "free" as const tiene tipo "free", no string, lo que permite usarlo en uniones.
¿Cuándo conviene anotar el tipo explícitamente?
Ejercicio práctico
Objetivo: modelar un catálogo de productos tipado y operar sobre él.
- Define el tipo
Productoconid,titulo,precio(number) yetiquetas(array de string). - Agrega una propiedad opcional
descuento. - Crea una lista
Producto[]con tres productos. - Escribe una función que filtre los productos que tienen una etiqueta dada.
- Comprueba con
tsc --noEmitque no hay errores.
Entregable: el archivo .ts con el tipo, la lista y la función de filtrado.
Para recordar
- Deja que TypeScript infiera en variables inicializadas; anota en parámetros y colecciones vacías.
?hace una propiedad opcional;readonlyimpide reasignarla.as constbloquea el valor a su literal exacto.
Aplicación práctica en un caso real
Aplicar Tipos primitivos, arrays y objetos (sin dolor) dentro del contexto de TypeScript Completo con criterio práctico, evitando quedarse en una definición aislada. Para que esta lección sea útil, imagina un escenario concreto: tienes que usar este tema para mejorar un proceso, tomar una decisión, crear un entregable o explicar una recomendación a otra persona. La pregunta no es solo “qué significa”, sino “qué haría diferente después de entenderlo”.
Un buen uso empieza por delimitar el problema. Define qué resultado quieres lograr, qué información tienes disponible, qué restricciones existen y cómo sabrás si la decisión fue correcta. Esta forma de pensar evita respuestas genéricas y convierte el aprendizaje en una herramienta de trabajo.
Marco de decisión
Antes de avanzar, revisa tres niveles: primero, el objetivo operativo; segundo, los recursos disponibles; tercero, el riesgo de equivocarte. En TypeScript Completo, muchas decisiones fallan porque se copia una táctica sin entender el contexto. El marco correcto te obliga a adaptar, no solo repetir.
- Objetivo: qué resultado medible o visible quieres conseguir.
- Contexto: quién usará esto, con qué nivel de experiencia y bajo qué restricciones.
- Acción: cuál es el siguiente paso mínimo que puedes ejecutar hoy.
- Señal: qué evidencia vas a observar para decidir si funcionó.
Ejemplo guiado
Supón que debes implementar esta idea en una pequeña empresa o proyecto personal. En vez de intentar una versión perfecta, prepara una versión mínima: una plantilla, una prueba, una lista de control, una automatización simple, una página, un mensaje o una medición inicial. Luego pide feedback o compara el resultado contra una métrica.
Si el resultado mejora, documenta el proceso. Si no mejora, identifica si falló la hipótesis, la ejecución o la medición. Esta distinción es clave: muchas personas abandonan una buena idea por una mala primera ejecución, o escalan una mala idea porque miraron la métrica equivocada.
Errores frecuentes
- Confundir actividad con avance: hacer muchas tareas sin saber qué resultado persiguen.
- Copiar ejemplos sin adaptarlos al cliente, audiencia, equipo o nivel técnico real.
- No dejar evidencia: si no registras decisiones y resultados, no aprendes del proceso.
- Querer automatizar o escalar antes de validar que el enfoque básico funciona.
Ejercicio práctico
- Escribe el objetivo de esta lección en una frase aplicada a tu caso.
- Define un entregable pequeño que puedas crear en menos de una hora.
- Lista tres criterios para evaluar si ese entregable está bien hecho.
- Ejecuta una versión inicial y anota qué cambiarías en una segunda iteración.
Checklist de salida
- Puedo explicar el concepto con mis propias palabras.
- Tengo un ejemplo aplicado, no solo una definición.
- Sé qué error debo evitar primero.
- Tengo una acción concreta para practicar esta semana.