Has escrito ya varios componentes cuyo return contiene algo que parece HTML pero vive dentro de un fichero JavaScript. Eso es JSX, y merece una lección propia porque casi todos los tropiezos de las primeras semanas con React vienen de asumir que JSX es HTML. No lo es: es sintaxis de JavaScript disfrazada de HTML. En esta lección desmitificarás JSX viendo en qué se transforma realmente, aprenderás sus reglas exactas y dominarás la interpolación con llaves, que es lo que convierte una tarjeta de texto fijo en una tarjeta que muestra datos reales de CicloUrbano.

1. Qué es JSX y en qué se transforma
2. Regla 1: un único elemento raíz (y los fragmentos)
3. Regla 2: atributos con nombres de JavaScript
4. Regla 3: todas las etiquetas deben cerrarse
5. Interpolación con llaves: expresiones sí, sentencias no
6. Atributos dinámicos
7. Estilos en línea con objeto
8. Comentarios dentro de JSX
9. Qué pinta React y qué no: null, undefined, false y el caso del 0
10. Tabla comparativa HTML vs JSX

JSX (JavaScript XML) es una extensión de sintaxis para JavaScript. Los navegadores no la entienden: antes de llegar al navegador, una herramienta de construcción (en nuestro caso Vite, mediante @vitejs/plugin-react) la traduce a JavaScript normal.

La mejor forma de perderle el miedo es ver la traducción. Este componente:

Se convierte, conceptualmente, en esto:

React.createElement recibe siempre tres cosas: el tipo de elemento, un objeto con sus propiedades y sus hijos. Y devuelve un objeto JavaScript sencillo, algo parecido a:

Tres conclusiones importantísimas se derivan de esto:

• JSX es azúcar sintáctico. Podrías escribir React entero sin JSX, con createElement a mano. Nadie lo hace porque es ilegible, pero conviene saber que no hay magia.
• JSX produce objetos, no HTML. Lo que devuelve tu componente no es una cadena de texto ni un nodo del DOM: es un objeto ligero que describe la interfaz. Ese objeto es la pieza que React compara para saber qué actualizar, tema de la próxima lección.
• Un elemento JSX es un valor de JavaScript. Puedes guardarlo en una variable, pasarlo como argumento o devolverlo desde una función:

Nota sobre React 19: desde la «nueva transformación de JSX» (React 17 en adelante) el compilador no genera literalmente React.createElement, sino una función interna _jsx que importa de forma automática. Ese es el motivo por el que ya no necesitas escribir import React from 'react' en cada fichero, como sí exigían los tutoriales antiguos. La idea es idéntica; solo cambia el detalle de implementación.

Una función solo puede devolver un valor. Como JSX se traduce en una llamada a createElement, un componente solo puede devolver un elemento raíz.

Vite lo rechaza con Adjacent JSX elements must be wrapped in an enclosing tag.

La solución obvia es envolver en un contenedor:

Pero a veces no quieres un contenedor extra: añadiría un div inútil al DOM que puede romper un grid, un flex o la semántica de una tabla. Para eso existen los fragmentos, que agrupan sin generar ninguna etiqueta:

<>...</> es la sintaxis abreviada del fragmento. Existe también la forma larga, <Fragment>...</Fragment>, necesaria únicamente cuando el fragmento debe llevar una key (algo que ocurre al recorrer listas, en la lección 03-03):

Regla práctica: si el contenedor aporta significado (<article>, <section>, <ul>), úsalo. Si solo estaría ahí para contentar a React, usa un fragmento.

En JSX, los atributos son en realidad propiedades de un objeto JavaScript. Eso obliga a dos ajustes respecto al HTML.

Palabras reservadas. class y for son palabras reservadas del lenguaje, así que se renombran:

camelCase. Los atributos compuestos por varias palabras se escriben en camelCase, porque así se llaman las propiedades equivalentes en el DOM:

Hay dos excepciones que conviene recordar porque suelen sorprender: los atributos data-* y aria-* mantienen los guiones tal cual, ya que no son propiedades del DOM sino atributos genuinos.

Buena noticia: si te equivocas, React suele avisarte en la consola con un mensaje muy claro del tipo «Invalid DOM property class. Did you mean className?». Léelos, no los ignores.

JSX hereda el rigor de XML: no existen etiquetas abiertas. En HTML puedes escribir <br> o <img src="..."> y el navegador lo tolera; en JSX es un error de sintaxis.

Lo mismo aplica a tus propios componentes: <TarjetaBicicleta />, no <TarjetaBicicleta>. Y las etiquetas con contenido deben cerrarse siempre y en el orden correcto; JSX no perdona un <p> sin </p> ni un anidamiento cruzado.

Aquí está la potencia real de JSX. Las llaves {} abren una ventana de vuelta a JavaScript: lo que pongas dentro se evalúa y su resultado se inserta en la interfaz.

Compara con la versión de la lección anterior: el texto ya no está escrito a mano, sino calculado a partir de datos. Es el mismo componente, pero ahora es dinámico.

Dentro de las llaves cabe cualquier expresión de JavaScript:

La regla que lo gobierna todo: expresiones sí, sentencias no. Una expresión produce un valor; una sentencia ejecuta una acción. Como el contenido de las llaves acaba siendo un argumento de una llamada a función, tiene que producir un valor.

Esto explica por qué en React el renderizado condicional se escribe con el operador ternario o con &&, y por qué las listas se pintan con .map() en lugar de con un bucle for: son las versiones expresión de esas construcciones. Ambos temas tienen lección propia: Renderizado Condicional y Listas y Claves. Aquí solo necesitas entender el porqué.

Si un cálculo es demasiado largo para caber en una expresión legible, la solución es sacarlo antes del return, donde sí puedes escribir todas las sentencias que quieras:

Este patrón —calcular arriba, mostrar abajo— mantiene el JSX limpio y es una de las señales de código React bien escrito.

Las llaves también funcionan en los atributos. La diferencia es sutil pero fundamental:

Un error muy común es mezclar ambas: src="{rutaLogo}" pasa la cadena literal "{rutaLogo}", no el valor. Comillas o llaves, nunca las dos.

Ejemplo completo aplicado a CicloUrbano, construyendo clases CSS dinámicas:

Detalles a observar:

• className con plantilla de cadena. Produce "tarjeta-bicicleta tarjeta-bicicleta--electrica". Es el patrón habitual para combinar una clase base con un modificador.
• disabled={!disponible}. Los atributos booleanos reciben un booleano de verdad, no una cadena. Si el valor es false, React omite el atributo en el HTML generado. Ojo con disabled="false": como toda cadena no vacía es true en JavaScript, ¡el botón quedaría deshabilitado!
• aria-label dinámico. Los atributos de accesibilidad se benefician muchísimo de la interpolación: cada botón describe exactamente su bicicleta.
• data-bicicleta-id conserva los guiones, como vimos.

En HTML, style recibe una cadena de texto CSS. En JSX recibe un objeto de JavaScript:

Ese doble par de llaves confunde a todo el mundo la primera vez, así que sepáralas mentalmente:

• Las llaves exteriores son la interpolación de JSX: «aquí viene una expresión de JavaScript».
• Las llaves interiores son un objeto literal de JavaScript.

Es exactamente lo mismo que escribir:

Reglas de ese objeto:

Las propiedades van en camelCase y los valores son cadenas, salvo los numéricos de propiedades que aceptan píxeles, donde React añade px automáticamente. Cuidado con esa comodidad: lineHeight: 2 significa «2 veces», no «2 píxeles», porque line-height es adimensional.

Ejemplo aplicado, con un color de estado calculado:

Cuándo usar estilos en línea: solo para valores realmente dinámicos que dependen de datos (un color calculado, un ancho de barra de progreso). Para todo lo demás, hojas de estilo: los estilos en línea no admiten :hover, ni media queries, ni pseudoelementos, y no se cachean. Las estrategias completas de estilado se ven en Estilos en los Componentes.

Los comentarios // y /* */ de JavaScript no funcionan dentro del JSX: acabarían pintados como texto. Hay que envolverlos en llaves:

En los atributos, en cambio, se comenta como en JavaScript, porque ahí ya estás dentro de una expresión:

La mayoría de editores hacen lo correcto automáticamente con Ctrl+/ si tienen soporte de JSX.

React ignora silenciosamente ciertos valores dentro de las llaves. Saber cuáles evita sorpresas desagradables.

Que null, undefined y false no se pinten es una funcionalidad muy útil: permite escribir «pinta esto solo si se cumple algo» sin ninguna estructura especial.

Y aquí está la trampa del 0. El operador && devuelve el operando de la izquierda cuando este es falsy. Si ese operando es 0, React sí lo pinta, porque 0 es un número perfectamente válido:

Este «cero fantasma» es uno de los fallos más reportados por principiantes en React. La regla para evitarlo: la izquierda de && debe ser siempre un booleano, no un número ni una cadena.

Sobre el error de los objetos: {bicicleta} falla porque React no sabe cómo pintar un objeto. Debes acceder a sus propiedades ({bicicleta.modelo}) o, si estás depurando, convertirlo en texto:

• Escribir class en vez de className. El aviso aparece en la consola y los estilos no se aplican. Es tan frecuente que conviene automatizarlo: con ESLint bien configurado te lo marca al escribir.
• Mezclar comillas y llaves: src="{ruta}". Pasa la cadena literal. O comillas para valores fijos, o llaves para expresiones.
• Intentar meter un if o un for dentro de las llaves. Son sentencias. Sácalos antes del return o usa sus equivalentes en forma de expresión (? :, &&, .map()).
• Olvidar el autocierre en <br>, <img>, <input> o <hr>. Error de sintaxis inmediato; el mensaje de Vite señala la línea con precisión.
• El «cero fantasma» con &&. Repítelo hasta que se te quede: la izquierda del && debe ser un booleano. plazasLibres > 0 && ..., nunca plazasLibres && ....
• Pintar un objeto: {bicicleta} en vez de {bicicleta.modelo}. El mensaje Objects are not valid as a React child es literal y te dice exactamente qué pasa.
• Un solo par de llaves en style. style={{ color: 'red' }} lleva dos: interpolación más objeto.
• Consejo: cuando dudes de qué hace un JSX complicado, tradúcelo mentalmente a createElement. Si la traducción no tiene sentido como llamada a función, el JSX tampoco lo tendrá.
• Consejo: si el JSX de un componente ocupa más de una pantalla, no es un problema de JSX sino de diseño: seguramente ese componente esté haciendo demasiadas cosas y deba dividirse. Lo trabajarás en el Módulo 2.

Traduce a JSX correcto el siguiente HTML de una tarjeta de estación de CicloUrbano. Debe ser un componente TarjetaEstacion completo, listo para usarse, con las tres correcciones de sintaxis que hacen falta.

Escribe un componente ResumenReserva que, a partir de estas constantes declaradas dentro del componente, muestre el modelo, las horas, el precio total con dos decimales y un aviso solo cuando la reserva supere las 4 horas. Todo debe salir de expresiones interpoladas, sin texto fijo duplicado.

El siguiente componente tiene un fallo visual: cuando plazasLibres vale 0, aparece un 0 suelto en pantalla en lugar de no mostrarse nada. Explica exactamente por qué ocurre y propón dos soluciones distintas.

Solución 1.

Las correcciones: class → className; el style como cadena → objeto con borderLeft en camelCase y el valor compuesto entre comillas; <hr> → <hr /> y el <input> autocerrado; for → htmlFor; readonly → readOnly.

Un detalle extra: React avisará en consola de que un input con value fijo y sin manejador de cambios es de solo lectura. Aquí es intencionado, y por eso lleva readOnly; los campos editables se estudian en Formularios y Componentes Controlados.

Solución 2.

Con estos datos muestra «Total: 24.00 €» y el aviso, porque 6 es mayor que 4. Fíjate en que la condición del && es una comparación, así que ya es un booleano: no hay riesgo de cero fantasma.

Solución 3.

Por qué ocurre: el operador && evalúa el operando izquierdo; si es falsy, devuelve ese mismo valor en lugar de un booleano. Como plazasLibres vale 0, la expresión completa devuelve 0. Y 0 es un número válido para React, que lo pinta tal cual. Solo null, undefined, true y false se omiten silenciosamente.

Solución A — convertir la condición en un booleano explícito:

Solución B — usar un ternario, que además cubre el caso contrario:

Una tercera vía, algo menos legible pero también válida, es forzar el booleano con doble negación: {!!estacion.plazasLibres && ...}. Prefiere siempre la comparación explícita: comunica mejor la intención.

JSX no es HTML: es sintaxis que se transforma en llamadas a función que producen objetos JavaScript describiendo la interfaz. De esa naturaleza se derivan todas sus reglas: un único elemento raíz (o un fragmento <>...</>), atributos con nombres de propiedad del DOM (className, htmlFor, camelCase), cierre obligatorio de todas las etiquetas, y llaves {} para interpolar expresiones —nunca sentencias—. Sabes construir atributos dinámicos, aplicar estilos en línea con objeto, comentar con {/* */} y evitar la trampa del 0 con &&.

Con eso ya puedes describir cualquier interfaz. Queda una pregunta esencial por responder: ¿qué hace React exactamente con esos objetos que devuelven tus componentes? ¿Cómo pasa de una descripción en memoria a píxeles en la pantalla, y cómo consigue actualizarla sin repintarlo todo? Eso es lo que verás en Cómo Renderiza React: Virtual DOM y Reconciliación, la lección que cierra este primer módulo.