Aquí hay algunas razones por las que React se ha vuelto tan popular tan rápidamente:
- Trabajar con la API DOM es difícil. React básicamente brinda a los desarrolladores la capacidad de trabajar con un navegador virtual que es más amigable que el navegador real. El navegador virtual de React actúa como un agente entre el desarrollador y el navegador real.
- React permite a los desarrolladores describir de forma declarativa sus interfaces de usuario y modelar el estado de esas interfaces. Esto significa que en lugar de dar pasos para describir transacciones en interfaces, los desarrolladores simplemente describen las interfaces en términos de un estado final (como una función). Cuando las transacciones ocurren en ese estado, React se encarga de actualizar las interfaces de usuario en función de eso.
- React es solo JavaScript, hay una API muy pequeña para aprender, solo algunas funciones y cómo usarlas. Después de eso, sus habilidades de JavaScript son las que lo convierten en un mejor desarrollador de React. No hay barreras de entrada. Un desarrollador de JavaScript puede convertirse en un desarrollador de React productivo en unas pocas horas.
Pero hay mucho más que eso. Intentemos cubrir todas las razones detrás de la creciente popularidad de React. Una razón es su DOM virtual (algoritmo de reconciliación de React). Trabajaremos con un ejemplo para mostrar el valor práctico real de tener un algoritmo de este tipo a su disposición.
La definición oficial de React establece que es una biblioteca de JavaScript para crear interfaces de usuario . Es importante comprender las dos partes diferentes de esta definición:
- React es una biblioteca de JavaScript . No es un marco. No es una solución completa y, a menudo, necesitaremos usar más bibliotecas con React para formar cualquier solución. React no asume nada sobre las otras partes en ninguna solución completa. Se centra en una sola cosa y en hacerla muy bien.
- Lo que React hace realmente bien es la segunda parte de la definición: construir interfaces de usuario . Una interfaz de usuario es cualquier cosa que ponemos frente a los usuarios para que interactúen con una máquina. Las interfaces de usuario están en todas partes, desde los simples botones de un microondas hasta el tablero de un transbordador espacial. Si el dispositivo que estamos tratando de conectar puede comprender JavaScript, podemos usar React para describir una interfaz de usuario para él.
Dado que los navegadores web entienden JavaScript, podemos usar React para describir las interfaces de usuario web. Me gusta usar la palabra describir aquí porque eso es lo que básicamente hacemos con React, simplemente le decimos lo que queremos y React construirá las interfaces de usuario reales, en nuestro nombre, en el navegador web. Sin React o bibliotecas similares, necesitaríamos construir manualmente interfaces de usuario con API web nativas y JavaScript.
Cuando escuche la afirmación de que “React es declarativo”, esto es exactamente lo que significa, describimos las interfaces de usuario con React y le decimos lo que queremos (no cómo hacerlo). React se encargará del "cómo" y traducirá nuestras descripciones declarativas (que escribimos en el lenguaje React) a las interfaces de usuario reales en el navegador. React comparte este poder declarativo simple con el propio HTML, pero con React, podemos ser declarativos para las interfaces HTML que representan datos dinámicos, no solo datos estáticos.
React tiene tres conceptos de diseño principales que impulsan su popularidad:
1 - El uso de componentes reutilizables, componibles y con estado
En React, describimos las interfaces de usuario usando componentes. Puede pensar en los componentes como funciones simples (en cualquier lenguaje de programación). Llamamos funciones con alguna entrada y nos dan alguna salida. Podemos reutilizar funciones según sea necesario y componer funciones más grandes a partir de funciones más pequeñas.
Los componentes son exactamente los mismos; llamamos a sus entradas "propiedades" y "estado", y una salida de componente es una descripción de una interfaz de usuario (que es similar a HTML para navegadores). Podemos reutilizar un solo componente en múltiples interfaces de usuario y los componentes pueden contener otros componentes.
Sin embargo, a diferencia de las funciones puras, un componente React completo puede tener un estado privado para almacenar datos que pueden cambiar con el tiempo.
2 - La naturaleza de las actualizaciones reactivas
El nombre de React es la explicación simple de este concepto. Cuando cambia el estado de un componente (la entrada), la interfaz de usuario que representa (la salida) también cambia. Este cambio en la descripción de la interfaz de usuario debe reflejarse en el dispositivo con el que estamos trabajando.
En un navegador, necesitamos regenerar las vistas HTML en el Modelo de objetos de documento (DOM). Con React, no tenemos que preocuparnos por cómo reflejar estos cambios, o incluso administrar cuándo realizar cambios en el navegador; React simplemente reaccionará a los cambios de estado y actualizará automáticamente el DOM cuando sea necesario.
3 - La representación virtual de vistas en la memoria
Con React, escribimos HTML usando JavaScript. Confiamos en el poder de JavaScript para generar HTML que depende de algunos datos, en lugar de mejorar HTML para que funcione con esos datos. Mejorar HTML es lo que suelen hacer otros marcos de JavaScript. Por ejemplo, Angular extiende HTML con características como bucles, condicionales y otras.
Cuando recibimos solo los datos del servidor (en segundo plano, con AJAX), necesitamos algo más que HTML para trabajar con esos datos. Está usando un HTML mejorado o usando el poder de JavaScript para generar el HTML. ambos planteamientos tienen ventajas y desventajas. React adopta este último, con el argumento de que las ventajas son más fuertes que las desventajas.
De hecho, hay una ventaja importante que puede justificar este enfoque por sí solo; El uso de JavaScript para representar HTML facilita que React mantenga una representación virtual de HTML en la memoria (que se conoce comúnmente como DOM virtual ). React usa Virtual DOM para renderizar un árbol HTML virtualmente primero, y luego, cada vez que un estado cambia y obtenemos un nuevo árbol HTML que necesita ser llevado al DOM del navegador, en lugar de escribir el árbol completamente nuevo, React solo escribirá el diferencia entre el árbol nuevo y el árbol anterior (ya que React tiene ambos árboles en la memoria). Este proceso se conoce como Reconciliación de árbol , y creo que es lo mejor que ha sucedido en el desarrollo web desde AJAX.
En el siguiente ejemplo, nos centraremos en este último concepto y veremos un ejemplo práctico simple del proceso de reconciliación de árboles y la gran diferencia que hace. Escribiremos el mismo ejemplo HTML dos veces, primero usando API web nativas y JavaScript vanilla, y luego veremos cómo describir el mismo árbol HTML con React.
Para enfocarnos exclusivamente en este último concepto, no usaremos componentes y simularemos una operación de cambio de estado usando un temporizador de JavaScript. Tampoco vamos a usar JSX, aunque usar JSX hará que el código sea mucho más simple. Utilizo JSX todo el tiempo cuando escribo React, pero es de esperar que trabajar con React API directamente en este ejemplo te ayude a entender este concepto mucho mejor.
Ejemplo de algoritmo de reconciliación de React
Para seguir este ejemplo, necesita un navegador y un editor de código. De hecho, puede usar un campo de juegos de codificación en línea, pero usaré archivos locales y los probaré directamente en un navegador (no necesitamos un servidor web):
Comenzaremos este ejemplo desde cero. Cree un nuevo directorio e inicie su editor favorito allí:
mkdir react-democd react-demoatom .Cree un index.htmlarchivo en ese directorio y coloque una plantilla HTML estándar allí. Incluya en esa plantilla un script.jsarchivo y ponga una console.logdeclaración en ese script para probar que la inclusión funciona:
React Demo Abra el index.htmlarchivo en su navegador y asegúrese de que puede ver la plantilla vacía sin problemas, y que puede ver en la pestaña Herramientas de desarrollo de la consola el console.logmensaje de prueba que puso script.js:
open index.html # On Mac explorer index.html # On WindowsNow, let’s bring in the React library itself, which we can include from the Reactjs website. Copy both the react and react-dom scripts, and include them in index.html:
We’re including two different scripts here for an important reason: The React library itself can be used without a browser. To use React with a browser, we need the ReactDOM library.
When we refresh the browser now, we should see both React and ReactDOM available on the global scope:
With this simple setup, we can now access both React and ReactDOM APIs, and of course, we also have access to the native Web APIs and JavaScript which we are going to use first.
To insert HTML dynamically in the browser we can simply use pure JavaScript and the DOM Web API itself. Let’s create a div element to host our JavaScript HTML content and give it the id "js". In the body element of index.html, right before the script tag, add:
Now in script.js, let's grab this new div element by its id and put it in a constant. Let's name this constant jsContainer. We can use document.getElementById to grab the div from HTML:
jsContainer.innerHTML = ` Hello JS `;To control the content of this div, we can use the innerHTML setter call on the div element directly. We can use this call to supply any HTML template that we want inserted in the DOM. Let's insert a div element with a class of "demo" and the string "Hello JS" as its content:
jsContainer.innerHTML = ` Hello JS `;ReactDOM.render( /* TODO: React's version of the HTML template */, reactContainer )Make sure this works in the browser. You should see the “Hello JS” line on the screen now.
This demo div is our User Interface so far. It’s a very simple one. We just output a text for the user to see.
Both document.getElementById and element.innerHTML are actually part of the native DOM Web API. We are communicating with the browser directly here using the supported APIs of the Web platform. When we write React code, however, we use the React API instead, and we let React communicate with the browser using the DOM Web API.
React acts like our agent for the browser, and we mostly need to communicate with just React, our agent, and not the browser itself. I say mostly because there are cases where we still need to communicate with the browser, but those are rare.
To create the exact same User Interface that we have so far but with React API this time, let’s create another div element and give it an id of "react". In index.html, right under the div#js element, add:
Now, in script.js, create a new container constant for the new div:
const reactContainer = document.getElementById("react");This container will be the only call we make to the native web API. ReactDOM needs this container to know where to host our application in the DOM.
With the react container identified, we can now use the ReactDOM library to render React's version of the HTML template to this container:
ReactDOM.render( /* TODO: React's version of the HTML template */, reactContainer )What we’re going to do next is your first milestone in truly understanding the React library. Remember when I told you that with React we write HTML using JavaScript? This is exactly what we are going to do next.
To write our simple HTML User Interface, we are going to use JavaScript calls to React API, and by the end of the example you’ll have a better picture about the reason for doing so.
Instead of working with strings (as we did in the native JavaScript example above), in React, we work with objects. Any HTML string will be represented as an object using a React.createElement call (which is the core function in the React API).
Here’s the equivalent HTML User Interface we have so far with React:
ReactDOM.render( React.createElement( "div", { className: "demo" }, "Hello React" ), reactContainer );React.createElement has many arguments:
- The first argument is the HTML tag, which is
divin our example. - The second argument is an object that represents any attributes we want this tag to have. To match the native JS example we used
{ className: "demo" }which translates toclass="demo". Note how we usedclassNameinstead ofclassin the attributes because with React it's all JavaScript that matches the Web API, not HTML itself. - The third argument is the content of the element. We’ve put a “Hello React” string in there.
We can test this now. The browser should render both “Hello JS” and “Hello React”. Let’s style the demo divs as a box, using this CSS, just so that we can visually split the screen. In index.html:
.demo { border: 1px solid #ccc; margin: 1em; padding: 1em; } 
We now have two nodes, one being controlled with the DOM Web API directly, and another being controlled with the React API (which in turn uses the DOM Web API). The only major difference between the ways we are building these two nodes in the browser is that in the JS version we used a string to represent the content, while in the React version we used pure JavaScript calls and represented the content with an object instead of a string.
No matter how complicated the HTML User Interface is going to get, when using React, every HTML element will be represented with a JavaScript object using a React.createElement call.
Let’s now add some more features to our simple User Interface. Let’s add a text box to read input from the user.
To nest elements in our HTML template, it’s straight forward in the JS version because it’s just HTML. For example, to make the demo div render an element, we simply add it to the content:
jsContainer.innerHTML = ` Hello JS `;We can do the same with React by adding more arguments after the 3rd argument for React.createElement. To match what we did in the native JS example, we can add a 4th argument that is another React.createElement call that renders an input element (remember, every HTML element is an object):
ReactDOM.render( React.createElement( "div", { className: "demo" }, "Hello React", React.createElement("input") ), reactContainer );At this point, if you’re questioning what we’re doing and thinking “this is complicating a simple process”, you are totally right! But there is a very good reason for what we’re doing. Keep reading.
Let’s also render a timestamp in both versions. In the JS version, let’s put the timestamp in a paragraph element. We can use a call to new Date() to display a simple timestamp:
jsContainer.innerHTML = ` Hello JS ${new Date()}
`;To do the same in React, we add a 5th argument to the top-level div element. This new 5th argument is another React.createElement call, this time using a p tag, with no attributes, and the new Date() string for content:
ReactDOM.render( React.createElement( "div", { className: "demo" }, "Hello React", React.createElement("input"), React.createElement( "p", null, new Date().toString() ) ), reactContainer );Both JS and React versions are still rendering the exact same HTML in the browser.
As you can see, so far, using React is actually a lot harder than the simple and familiar native way. What is it that React does so well that’s worth giving up the familiar HTML and having to learn a new API to write what can be simply written in HTML? The answer is not about rendering the first HTML view, it’s about what we need to do to update any existing view in the DOM.
So, let’s do an update operation on the DOM we have so far. Let’s simply make the timestamp tick every second.
We can easily repeat a JavaScript function call in a browser using the setInterval Web timer API. So, let's put all of our DOM manipulations for both JS and React versions in a function, call it render, and use it in a setInterval call to make it repeat every second.
Here’s the full final code in script.js:
const jsContainer = document.getElementById("js"); const reactContainer = document.getElementById("react"); const render = () => { jsContainer.innerHTML = ` Hello JS ${new Date()}
`; ReactDOM.render( React.createElement( "div", { className: "demo" }, "Hello React ", React.createElement("input"), React.createElement( "p", null, new Date().toString() ) ), reactContainer ); } setInterval(render, 1000);When we refresh the browser now, the timestamp string should be ticking every second in both versions. We are now updating our User Interface in the DOM.
This is the moment when React will potentially blow your mind. If you try to type something in the text box of the JS version, you won’t be able to. This is very much expected because we’re basically throwing away the whole DOM node on every tick and regenerating it. However, if you try to type something in the text box that’s rendered with React, you can certainly do so!
Although the whole React rendering code is within our ticking timer, React is changing only the timestamp paragraph and not the whole DOM node. This is why the text input box was not regenerated and we were able to type in it.
You can see the different ways we’re updating the DOM visually if you inspect the two DOM nodes in a Chrome dev tools elements panel. The Chrome div tools highlights any HTML elements that get updated. You’ll see how we are regenerating the whole “js” div on every tick, while React is smartly only regenerating the paragraph with the timestamp string.
React has a smart diffing algorithm that it uses to only regenerate in its DOM node what actually needs to be regenerated while it keeps everything else as is. This diffing process is possible because of React’s virtual DOM and the fact that we have a representation of our User Interface in memory (because we wrote in JavaScript).
Using the virtual DOM, React keeps the last DOM version in memory and when it has a new DOM version to take to the browser, that new DOM version will also be in memory, so React can compute the difference between the new and the old versions (in our case, the difference is the timestamp paragraph).
React will then instruct the browser to update only the computed diff and not the whole DOM node. No matter how many times we regenerate our interface, React will take to the browser only the new “partial” updates.
Not only is this method a lot more efficient, but it also removes a big layer of complexity for the way we think about updating User Interfaces. Having React do all the computations about whether we should update the DOM or not enables us to focus on thinking about our data (state) and the way to describe a User Interface for it.
We then manage the updates on our data as needed without worrying about the steps needed to reflect these updates on the actual User Interface in the browser (because we know React will do exactly that and it will do that in an efficient way!)
Thanks for reading! You can view the source code of my demo here, and you can see the demo running here.
Learning React or Node? Checkout my books:
- Learn React.js by Building Games
- Node.js Beyond the Basics