¿Qué *demonios* es JSX?

Antes de comenzar una serie de artículos sobre React y React Native, quiero aclarar un concepto que parece confundir a muchas personas.

  • “¡¿HTML en JavaScript?!”
  • “¿Volvió XML?”
  • “¿JSX? ¿Qué #$&%! es eso?”

En 2013, el frontend (sí, yo escribo frontend así, ja!) vivió una pequeña revolución en su ecosistema. En la JSConf EU, Pete Hunt invitó a la comunidad a Repensar las buenas prácticas y, con la “bendición” de Facebook e Instagram, nos presentó “React — Una librería JS para construir interfaces de usuario.”

Después de un inicio complicado y con bastante escepticismo, hoy en día nadie puede negar que React.js es el actor principal en “el salvaje oeste” del frontend. Con empresas como Facebook, Instagram, Netflix, Spotify, Linkedin, PayPal, Github, Microsoft, Apple –y muchas más– utilizando React.js en producción, no cabe duda alguna de su utilidad y estabilidad.

Pero en este artículo no vamos a hablar –mucho– de React, vamos a tratar sobre algo que esta popular librería nos trajo bajo su brazo; JSX.

JSX es un pequeño personaje –tan querido y tan odiado por muchas personas– que ayudó a reformular la idea de escribir “HTML” dentro de JS y que, de cierta forma, contribuyó a la actual revolución de componentes en la web. (aunque también confundió y ahuyentó)

Entonces, ¿qué mismo es JSX?

Fundamentalmente, solo es azúcar sintáctico para la función de React: 
 React.createElement(component, props, ...children) 
 (por eso necesitamos tener a React dentro del scope del proyecto)

Según la gente de facebook: JSX es una extensión de ECMAScript (aka: JavaScript o JS) sin definición semántica y que tiene una sintaxis muy parecida al XML.
No existe intención alguna de implementarlo en motores o navegadores y menos aún tomarlo como una propuesta para ser incorporada en la especificación de ECMAScript. Fue creado con la intención de que los preprocesadores (ej. Babel.js) lo transformen en ECMAScript estándar.

Es decir, el gran propósito de JSX es el de proveer una sintaxis –familiar y concisa (tipo HTML/XML)– para definir estructuras de nodos con propiedades y atributos.

Como ejemplo, imaginemos que vamos a crear un componente de Dropdown que contenga un Menu con varios Items.

Con JSX expresamos los componentes de nuestra interface de usuario de la siguiente forma:

var dropdown = <Dropdown> Nombre de la lista <Menu> <MenuItem>Elemento #1</MenuItem> <MenuItem>Elemento #2</MenuItem> <MenuItem>Elemento #3</MenuItem> </Menu> </Dropdown>; render(dropdown);

En este ejemplo, Tenemos 3 componentes diferentes:

  1. <Dropdown />
  2. <Menu />
  3. <MenuItem />

Un componente <Dropdown /> que contiene un componente <Menu />, que a su vez contiene tres componentes <MenuItem />.
 Con este ejemplo, podemos ver dos de los principios fundamentales de la componetización; composición y reusabilidad.

Existen un par de “reglas” para utilizar JSX:

  1. Escribir nuestros propios componentes con capitalización. <App />
  2. Escribir los componentes built-in (HTML) con minúsculas. <img />

Para continuar, podemos abrir –en una nueva ventana– esta micro herramienta que nos permite visualizar como Babel.js transforma nuestro código. (copiar/pegar o escribir directamente)

JSX bajo el capó

Para entender un poco más lo que está pasando, vamos a imaginar otro ejemplo. Ahora queremos tener un div con una propiedad miProp y un elemento hijo h1, que a su vez contiene un string "Soy un Header!".

  • Si expresamos nuestra UI en JSX:
// JSX 
<div prop="miProp"> <h1>Soy un Header!</h1> </div>
  • Babel transformará el código a lo siguiente:
// JS
React.createElement( "div", // tag o componente { prop: "miProp" }, // propiedades React.createElement( // elemento hijo "h1", null, // null cuando el elemento no tiene propiedades "Soy un Header!" ) );
  • Ahora intentemos imaginar cual será la transformación de este código:
<MiBoton className="btn" color="pink" fontSize={24}> Haz Click! </MiBoton>

Cabe recalcar, que también podemos expresar componentes con self-closing tags, si estos no tienen componentes hijos:

<div className="barra-lateral" />

Como podemos ver, JSX no es ni HTML, ni XML; solo se asemeja para ayudar a la legibilidad –para parecer más familiar.
 Es un simple patrón de composición de funciones pero con una sintaxis similar al HTML/XML.

Nada más. ?

Todo se reduce a ese método que nos provee React; con el cual podemos crear elementos en JS pero camuflados en una sintaxis sencilla que nos recuerda a algo más. :P

En realidad, la mayor diferencia –visual– entre JSX y HTML, es el tener que usar className para agregar una clase, ya que class es una palabra reservada en JS.

<!-- HTML --> <div class="contenedor"> <!-- Contenido --> </div>
// JSX <div className="contenedor"> // Contenido </div>

La versatilidad que esta combinación de tecnologías me ha dado, me lleva a pensar que JSX es igual a HTML… pero con superpoderes. :P

“El gran triunfo de JSX es que parezca ‘HTML-en-JS’, y que al mismo tiempo nos provea una poderosa abstracción por encima.”
 — Guillermo Rauch (@rauchg)

*Recuerda, si no quieres utilizar JSX, puedes crear elementos con React.createElement() y no depender de la transformación.

Conclusión

A pesar de haber tenido un comienzo con mucha resistencia, React y su pequeño JSX, se han ganado un espacio gigantesco dentro de la comunidad frontend.

Esta combinación nos ha permitido crear aplicaciones y prototipos de gran calidad y en poco tiempo, permitiendo a su vez, que desarrolladores y diseñadores trabajen dentro de un mismo “formato mental”.

Así que, ¿quién dijo miedo?

🖖


Originally published at txt.juanmnl.com.

Like what you read? Give ThoughtWorks Español a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.