├── LICENSE ├── README.md └── SUMMARY.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2020 undefined school 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # React: Principios 2 | 3 | ### 👉 Ver [todas las notas](https://github.com/undefinedschool/notes) 4 | 5 | ## Contenido 6 | 7 | * [Qué problema resuelve React?](https://github.com/undefinedschool/notes-react#qu%C3%A9-problema-resuelve-react) 8 | * [Principios](https://github.com/undefinedschool/notes-react#principios) 9 | * [Declarativo](https://github.com/undefinedschool/notes-react#declarativo) 10 | * [Arquitectura basada en _componentes_](https://github.com/undefinedschool/notes-react#arquitectura-basada-en-componentes) 11 | * [Componente](https://github.com/undefinedschool/notes-react#componente) 12 | * [Flujo de datos unidireccional \(one-way data flow\)](https://github.com/undefinedschool/notes-react#flujo-de-datos-unidireccional-one-way-data-flow) 13 | * [Virtual DOM](https://github.com/undefinedschool/notes-react#virtual-dom) 14 | * [Sólo se encarga de la UI](https://github.com/undefinedschool/notes-react#s%C3%B3lo-se-encarga-de-la-ui) 15 | * [Nuestra tarea como React devs](https://github.com/undefinedschool/notes-react#nuestra-tarea-como-react-devs) 16 | 17 | --- 18 | 19 | ## Qué problema resuelve React? 20 | 21 | Antes de empezar a hablar sobre los diferentes conceptos, siempre es útil entender un poco la motivación, por qué existe, qué problema resuelve la herramienta que elegimos. En mi opinión, este proceso resulta además muy beneficioso para entender, tanto mejor como más rápido, los conceptos fundamentales detrás de cualquier tecnología que decidamos usar. 22 | 23 | Con los años, la complejidad de las aplicaciones web fue creciendo. Al principio, sólo teníamos archivos HTML, CSS y algo de JS para proveer un mínimo de interacción con el DOM. El código JS que escribíamos no era compatible con todos los browsers por default, por lo que había que escribir diferentes versiones. _jQuery_ surge entonces como una solución a este problema, brindando una API unificada para escribir este código una vez y de forma más simple, garantizando compatibilidad con los diferentes browsers. 24 | 25 | Pero la complejidad de las bases de código seguía aumentando y los programas eran cada vez más difíciles de mantener. El framework _AngularJS_ aparece en el 2010 y se posiciona rápidamente como el nuevo standard para construir SPAs \(single-page applications\), aportando una estructura y el uso de ciertos patrones \(MVC\) para organizar mejor nuestras aplicaciones. 26 | 27 | Más aún, en aplicaciones donde acciones en diferentes partes de la UI tenían efectos sobre otras[1], los problemas seguían estando y nos encontrábamos con aplicaciones escritas en _Angular_ donde era difícil entender el _flujo de los datos_ y qué parte del código afectaba a cuál otra. 28 | 29 | Facebook tenía este problema muy presente, por lo que decidieron desarrollar una alternativa. [En el 2013, Facebook libera _React_](https://www.youtube.com/watch?v=GW0rj4sNH2w), _una biblioteca de JavaScript para construir interfaces de usuario_, según definen en el [sitio oficial](https://reactjs.org/). 30 | 31 | [↑ Ir al inicio](https://github.com/undefinedschool/notes-react-principles#contenido) 32 | 33 | ## Principios 34 | 35 | ### Declarativo 36 | 37 | La manipulación del DOM es uno de los principales cuellos de botella en la performance del front-end. React decide entonces tomar un enfoque más _declarativo_ y busca evitar que el browser esté continuamente realizando operaciones costosas. 38 | 39 | Por lo tanto, sólo vamos a encargarnos de diseñar las _vistas_ para cada _estado_ de nuestra aplicación y **React va a actualizar y renderizar de manera eficiente los componentes correctos cuando los datos cambien** \(estado\), haciendo cambios mínimos en el DOM. **El código declarativo es más predecible y por lo tanto, más fácil de de razonar y debuggear**. 40 | 41 | > 👉 **La vista pasa a ser entonces una función del estado** de la aplicación, es decir, cuando el estado de la aplicación cambia, la vista se vuelve a renderizar. Por lo tanto, **si queremos que la vista \(UI\) sea actualice, tenemos que modificar el estado de alguna forma**. 42 | 43 | Ya no necesitamos preocuparnos por cómo manipular el DOM o manejar eventos del mismo, React se va a encargar de abstraernos de estos detalles. 44 | 45 | [↑ Ir al inicio](https://github.com/undefinedschool/notes-react-principles#contenido) 46 | 47 | ### Arquitectura basada en _componentes_ 48 | 49 | Vamos a construir interfaces de usuario \(UI\) utilizando _componentes reutilizables_, que poseen y manejan un _estado_ propio. Usamos estos _componentes_ como si fueran bloques de Lego, para construir componentes más complejos y eventualmente una aplicación entera. 50 | 51 | > 👉 **Llamamos** _**estado**_ **a las características propias de un componente**. Por ejemplo, cuando tenemos un componente que hace requests a un server, puede tener dos estados posibles, pendiente o finalizado. 52 | 53 | La lógica de los componentes se escribe en JavaScript \(y no utilizando _templates_, como es el caso de otras libs/frameworks de front\), por lo que podemos pasar datos \(_props_\) de forma simple y mantener el estado fuera del DOM. 54 | 55 | [↑ Ir al inicio](https://github.com/undefinedschool/notes-react-principles#contenido) 56 | 57 | **Componente** 58 | 59 | > 👉 **Un componente es un** _**bloque de código reutilizable**_**, una pieza de UI con contenido, estilos y comportamiento definidos: contiene todo el HTML, CSS y JS necesario para funcionar**. 60 | 61 | Por ejemplo, una barra de búsqueda es un componente, porque tiene una función independiente, una botón podría también a ser un componente, porque cumple una función. Básicamente, cualquier sección de la UI puede llegar a ser un componente. 62 | 63 | Por lo tanto, **en React, cada parte de la UI es un componente y cada componente tiene un estado**. 64 | 65 | Si el _estado_ de nuestra aplicación indica por ejemplo, que un usuario se encuentra logueado, crearemos los componentes correspondientes basados en esa información. 66 | 67 | > 👉 **Los componentes entonces, no dejan de ser simples funciones de JavaScript** que reciben esta información a través de diferentes parámetros a los que llamaremos _props_ \(por _propiedades_\) y retornan el código necesario \(usando [_JSX_](https://reactjs.org/docs/introducing-jsx.html)\) para renderizar los componentes. **Las props son** _**inmutables**_ **y siempre se pasan de componentes superiores a componentes inferiores**. 68 | 69 | [↑ Ir al inicio](https://github.com/undefinedschool/notes-react-principles#contenido) 70 | 71 | ### Flujo de datos unidireccional \(_one-way data flow_\) 72 | 73 | > 👉 En React, **los datos tienen 1 y sólo 1 forma \(o dirección\) de ser transferidos hacia otras partes de la aplicación**. Esto implica que los _componentes hijos_ \(child components\) no pueden actualizar los datos que provienen de un _componente padre_ \(parent component\). 74 | 75 | ![one-way data flow](https://image.slidesharecdn.com/wjkqukgsqgm2vger5dnt-signature-2cf736e9b897e2aaaa6315f9d31d6951ba19fae7560fe278cefb4644ac0753c6-poli-170428114140/95/ndc17-unrealjs-ue4-35-638.jpg?cb=1493434725) 76 | 77 | **Los datos que vienen de un** _**componente padre**_ **se conocen como** _**props**_. 78 | 79 | El principal beneficio de tomar este approach, en el que los datos _fluyen_ a través de nuestra aplicación en una única dirección, es que el código resulta más fácil de razonar y debuggear, porque sabemos qué datos provienen de dónde y por lo tanto menos propenso a errores. 80 | 81 | > 👉 Cualquier cambio que se le realice al _state_ de un componente, sólo puede afectar a los componentes que están _debajo_ \(los _child components_\), que van a recibirlo como _props_ de sólo lectura. 82 | 83 | **Como los datos se mueven en una única dirección, modificar el estado de un componente no afecta a su componentes padre o hermanos: sólo los descendientes van a ser afectados** \(un _child component_ no puede modificar el _state_ de su _parent component_\). Esta es la principal razón por la que [el _state_ suele _levantarse_](https://reactjs.org/docs/lifting-state-up.html) \(lo movemos "hacia arriba" en el _árbol de componentes_\), de manera tal que pueda compartirse y ser accedido entre los componentes que lo necesitan. 84 | 85 | [↑ Ir al inicio](https://github.com/undefinedschool/notes-react-principles#contenido) 86 | 87 | ### Virtual DOM 88 | 89 | **Actualizar y volver a renderizar el DOM en el browser cada vez que queremos realizar un cambio en la UI tiene un gran impacto en la performance de nuestra aplicación**, porque implica realizar operaciones costosas. Al hacer cambios en el DOM, el elemento modificado y sus descendientes \(children\) deben volver a renderizarse para que el cambio se vea reflejado en la UI. Realizar estas operaciones continuamente \([_re-rendering_, _re-painting_, etc](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction)\) es lo que vuelven lenta y poco eficiente a esta forma de trabajar. 90 | 91 | Con React no hacemos cambios al DOM _directamente_, en cambio, esta librería propone utilizar una alternativa, el _Virtual DOM_. 92 | 93 | > 👉 **El** [_**Virtual DOM**_](https://programmingwithmosh.com/react/react-virtual-dom-explained/) **es una representación virtual del DOM, una "versión liviana" \(un gran objeto JS\) del DOM real que encontramos en el browser, que React utiliza para** _**mapear**_ **elementos del DOM real y poder realizar cambios en este de una forma mucho más rápida y eficiente**. Cada vez que el _state_ de nuestra aplicación cambia, se actualiza el _Virtual DOM_ y no el DOM real. 94 | 95 | ![React Virtual DOM](https://miro.medium.com/max/2048/1*wrh_lW6mpQHRsuGtw1FuqA.png) 96 | 97 | > 👉 Básicamente, cada vez que agregamos nuevos elementos \(componentes\) a la UI, un nuevo _virtual DOM_ \(representado como un árbol\) es creado. Cada elemento es un _nodo_ de este árbol. React toma un _snapshot_ de los elementos de nuestra aplicación y lo carga en este árbol. Si el _state_ de alguno de estos elementos cambia, se genera un nuevo _virtual DOM_. Este DOM \(virtual\) es entonces comparado con el DOM \(virtual\) previo y se calculan las diferencias a través de un [_algoritmo de diffing_](https://medium.com/@gethylgeorge/how-virtual-dom-and-diffing-works-in-react-6fc805f9f84e). Utilizando esta información, **React calcula la forma más eficiente de realizar los cambios en el DOM real**, actualizando sólo los nodos que cambiaron, reduciendo el impacto en la _performance_ de nuestra aplicación. 98 | 99 | Otra estrategia que utiliza React para mejorar la performance es enviar los cambios detectados en el virtual DOM por _lotes_ \(batch\), para luego realizar los cambios necesarios en el DOM real de una vez, en lugar de estar enviando continuamente updates al mismo por cada cambio del estado. 100 | 101 | > 👉 **En resumen:** 102 | > 103 | > * realizar updates frecuentes del DOM \(real\) es costoso y tiene un gran impacto en la performance 104 | > * el _Virtual DOM_ es una representación virtual del DOM real que React utiliza para mejorar la performance 105 | > * cuando ocurre un cambio en el _state_, se genera un nuevo _virtual DOM_ y se compara con la versión anterior. Esto se conoce como _diffing_ 106 | > * los cambios a realizar en el DOM se envían por tandas, para actualizar la UI con menor frecuencia y por lo tanto, menor costo 107 | 108 | [↑ Ir al inicio](https://github.com/undefinedschool/notes-react-principles#contenido) 109 | 110 | ### Sólo se encarga de la UI 111 | 112 | > 👉 **React es una librería \(o biblioteca\) que sólo se encarga de resolver un problema: renderizar la** _**vista**_ **o UI de nuestra aplicación**. 113 | 114 | A diferencia de otros _frameworks_ de front-end, como Angular, Vue o Svelte, **React no es opinionado**, no asume nada sobre nuestro stack tecnológico ni sobre cómo resolver y conectar el resto de las partes; esas decisiones quedarán por nuestra cuenta. Gracias a esto, la _API_ de React resulta más concisa y simple en comparación y por lo tanto, más simple de aprender. 115 | 116 | Además, **esta característica permite también que podamos reutilizar código React en diferentes plataformas**: por ejemplo, renderizando desde el servidor usando [Node](https://nodejs.org/) o en aplicaciones móviles, a través de [React Native](https://facebook.github.io/react-native/). 117 | 118 | [↑ Ir al inicio](https://github.com/undefinedschool/notes-react-principles#contenido) 119 | 120 | ## Nuestra tarea como _React devs_ 121 | 122 | Como devs, tendremos que tomar varias decisiones relacionadas a la _arquitectura de la aplicación_, que podrían resumirse en los siguientes puntos: 123 | 124 | * definir los _**React components**_ 125 | * definir qué datos forman parte del _**state**_ y dónde \(en qué componente\) va a vivir 126 | * decidir **qué cambios deben realizarse en la UI cuando el** _**state**_ **cambia** 127 | 128 | [↑ Ir al inicio](https://github.com/undefinedschool/notes-react-principles#contenido) 129 | 130 | --- 131 | 132 | 1 Estos problemas existieron \(y todavía existen\) en las librerías que decidieron usar [_**2-way data binding**_](https://medium.com/front-end-weekly/what-is-2-way-data-binding-44dd8082e48e) **\(o flujo de datos** _**bidireccional**_**\)**. Es decir, los cambios en la UI afectan al objeto JS que la UI quiere representar y viceversa. 133 | 134 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [React: Principios](README.md) 4 | 5 | --------------------------------------------------------------------------------