Sobre el Origen de React

Esta charla toma prestado su título de Sobre el Origen de las Especies, uno de los libros más conocidos de la historia moderna. Y cuando ves este libro, o el nombre de Charles Darwin, quien lo escribió, probablemente te viene a la mente la palabra evolución. O tal vez sea selección natural. O si eres como yo, son los pinzones. Siempre pienso en los pinzones de Darwin.

Ahora, todas estas son asociaciones válidas, y en realidad todas están relacionadas. Así que, la evolución se basa en la selección natural, y Darwin llegó a la idea de la selección natural durante sus viajes a las Islas Galápagos. Donde observó pinzones. Todos iguales, pero diferentes de manera única. Así que, son los picos, cada uno adaptado a un tipo de alimento específico. Al ver esta graduación y diversidad de estructura en un pequeño grupo de aves relacionadas entre sí en este archipiélago, una especie había sido tomada y modificada para diferentes propósitos. Esos son los pinzones. Pero esta graduación y diversidad de estructura, esta especie tomada y modificada para diferentes propósitos, tal vez también podría ser React components.

Verás, estamos en un punto de la historia de React ahora donde podemos mirar hacia atrás y ver cómo ha evolucionado. Te prometo que esto no es una lección de historia. No vamos a estar memorizando fechas o discutiendo los grandes debates de RFC de 2016 o algo por el estilo. Esta charla pretende ser útil. Las versiones antiguas de React todavía están en producción. Y dependiendo de cuándo hayas aprendido React, es posible que veas un componente de una versión anterior y tengas algunas preguntas. Ahí es donde entra esta charla. Te ayudará a identificar algunas de las estructuras antiguas y proporcionará contexto sobre qué ha cambiado y por qué. Ahora, si has estado escribiendo React desde los primeros días, esta charla es más un viaje por el camino de la memoria. Así es como me sentí al escribirla. He estado trabajando con React desde la versión .12 y fue lanzada a finales de 2014. En ese momento, React ya estaba disponible públicamente desde hace más de un año. Su lanzamiento público inicial fue a mediados de 2013.

Pero no considero que ese sea nuestro punto de partida. De hecho, vamos a comenzar a analizar los componentes de React alrededor de la versión .12. Nuevamente, esto es cuando comencé a aprender React y eso se debe a que React realmente estaba tomando forma. Estaba comenzando a ganar popularidad en la comunidad de JavaScript, React era la palabra de moda.

Además, no hay cambios significativos en los componentes de React entre .3 y .12. Por lo tanto, este período de tiempo es nuestra referencia para cómo se estructuraban y se comportaban los componentes. Y este es uno de esos componentes. Ahora, algunos de ustedes nunca han visto esto antes y algunos de ustedes están experimentando flashbacks, pero sí, esto es React en sus primeros días.

Ahora, lo primero que probablemente notes es React.createClass. En este momento de la historia de React, no existen los componentes de clase ni los componentes de función. Tampoco tenemos fragmentos y se están renderizando elementos span adicionales. Eso es cierto. Y hay mucho más. No voy a poder enumerar todas las diferencias en React y su ecosistema entre entonces y ahora, pero en cuanto a la estructura del componente, este es nuestro ancestro más antiguo.

A medida que comenzamos a construir un árbol evolutivo de los componentes de React, este se convierte en la base del árbol. Todos los componentes a partir de aquí evolucionaron a partir de CreateClass. Y esas evoluciones siguen algunas ramas comunes. Entonces, si volvemos a mirar este componente, ¿qué atributos evolucionaron junto con la estructura del componente? Además de la creación del propio componente utilizando CreateClass, ¿qué hay de los métodos del ciclo de vida? Aquí he creado todos los métodos del ciclo de vida disponibles en React .12 y anteriores. Por lo tanto, eso incluye component will mount, component did mount, will receive props, will update, did update y will unmount. Estos probablemente te resulten más familiares que CreateClass en sí, y eso se debe a que estos métodos del ciclo de vida no cambian durante gran parte de la historia de React. Probablemente hayas visto o trabajado con estos ciclos de vida en algún momento. Lo que puede resultarte menos familiar son getInitialState y getDefaultProps, y estos hacen exactamente lo que esperarías, establecer el estado inicial o establecer las props predeterminadas. Por lo tanto, es una estructura poco familiar pero un concepto conocido. Al completar las ramas de nuestro árbol, los ciclos de vida se convierten en una de esas ramas. Estaremos atentos a cómo evolucionan estos ciclos de vida con el tiempo en conjunto con la estructura del componente.

Ahora, hay una rama más en este árbol evolutivo por explorar, y eso es la reutilización de código. ¿Cómo compartimos código entre componentes? Bueno, en los días de createClass, solíamos utilizar algo llamado mixins. Aquí tienes un mixin. Se parece notablemente a cómo creamos componentes, pero no pasamos este objeto a createClass.

En su lugar, vamos a proporcionarlo a un componente con la clave mixins y una matriz de mixins. Aquí estoy proporcionando el mixin de conteo a este componente. Y ahora puedo usar lo que se proporciona en los mixins como si existiera en el propio componente. Estoy usando this.increment, parte del mixin de conteo, y this.state.count, también parte del mixin de conteo. Así que ahora podemos completar la rama de reutilización de código de nuestro árbol con mixins como la primera evolución en esa rama. No pasa mucho tiempo, por cierto, para que este árbol crezca.

La siguiente versión de React se basa en esta base y vamos a empezar a ver estructuras más familiares como los componentes de clase. Los componentes de clase se introducen en la versión .13. Esto es importante. Es un cambio fundamental en cómo construimos los componentes de React. Ahora, createClass todavía es compatible, pero pronto las clases se convertirán en la opción predeterminada. Y no vamos a pasar mucho tiempo mirando los componentes de clase, pero quiero señalar algunas diferencias clave con respecto a createClass. La primera es que no llamamos a createClass. En su lugar, nos extendemos de React.component. Ahora, getInitialState y getDefaultProps ya no existen. Establecemos el estado en el constructor y establecemos DefaultProps como una propiedad de clase. Bien, vamos a añadir componentes de clase a nuestro árbol. Estos son una evolución directa de createClass. Pero, ¿qué pasa con las otras ramas? ¿Hubo algún cambio? En cuanto a los ciclos de vida, realmente nada. Como se mencionó, la inicialización del estado y DefaultProps es un poco diferente, pero los métodos del ciclo de vida en sí siguen estando. Por lo tanto, los componentes de clase siguen conectados a la rama de los ciclos de vida. ¿Y qué pasa con la reutilización de código? ¿Seguimos utilizando mixins con los componentes de clase? No. Por lo tanto, los componentes de clase no admiten mixins. Y resulta que este es el inicio lento de la evolución de la reutilización de código en React. Por lo tanto, la evolución tiende a ser un proceso lento. La selección natural ocurre de generación en generación, pequeños cambios, adaptaciones permiten a las especies sobrevivir y transmitir esos rasgos a la siguiente generación. Ahora, las polillas moteadas son un ejemplo famoso de selección natural y acción. De alguna manera, a lo largo de 50 años, a partir de la década de 1850, las polillas de color claro cambiaron de color. A principios de 1900, las polillas moteadas oscuras eran la población dominante. Lo fascinante es por qué las polillas cambiaron de color, ¿qué más estaba sucediendo durante esos 50 años? No eran solo las polillas las que estaban evolucionando.

La revolución industrial significó la construcción de fábricas, fábricas que funcionaban con carbón y producían un humo oscuro que cubría el paisaje, por lo que las polillas moteadas de color claro tenían menos capacidad para camuflarse. Los depredadores podían detectarlas en contraste con el paisaje más oscuro, y su tasa de supervivencia disminuyó, pero las polillas moteadas oscuras, su tasa de supervivencia aumentó. Así que a veces la selección natural es simplemente una casualidad, una mutación que resulta ser una mejora de la versión anterior, pero a veces la evolución se ve forzada en una especie.

Y debo dejar claro que `forzada` no implica intención. Los mixins ni siquiera fueron deprecados en la versión .13, y no había intención de deprecar mixins en versiones futuras. La regla era simplemente si se requería un mixin, usar create class. Los componentes de clase estaban destinados a evolucionar, React más cercano al JavaScript idiomático. Los mixins no eran parte de JavaScript, por lo que tenía sentido no incluirlos. Ahora, la falta de soporte no pretendía alejar a React de los mixins, aunque eso es lo que sucedió. No fue intencional, pero los componentes de clase sin mixins nos obligaron a evolucionar más allá de ellos.

Sin embargo, la evolución es un proceso lento, por lo que antes de que eso suceda, tenemos un nuevo desarrollo en React. Componentes sin estado, o como los llamamos ahora, componentes de función. Entonces, `sin estado` no era el mejor término para estos porque los componentes sin estado ya existían. Podías crear un componente solo con la función render. Los ciclos de vida, el estado e incluso las props siguen siendo 100% opcionales en los componentes de React. Por lo tanto, es mejor describirlos por lo que son, componentes de función. Estos se presentan como una nueva sintaxis más simple para los componentes que ya estábamos escribiendo, y debo decir que son hermosos. Cuando se lanzan, es encantador. Aún mejor con la deconstrucción de props, como, oh, mira eso, es tan hermoso. Cuando se lanzan, la comunidad de React abraza por completo los componentes de función. Estos son una adición bienvenida al árbol evolutivo de React.

Ahora, en ese momento, no hay ciclos de vida en los componentes de función y no hay opciones para reutilización de código. Al igual que los componentes de clase, los componentes de función acercan a React al JavaScript idiomático. Por lo tanto, esta evolución tiene sentido. Pero ahora tenemos create class, componentes de clase, componentes de función y create class todavía es un requisito para los mixins. Eso va a cambiar pronto. De hecho, ha estado en proceso durante un tiempo. A principios de 2016, se publica una nueva publicación de blog en el blog oficial de React. Su título es `Mixins Considerados Dañinos`. ¿Qué pasó? Entonces, a partir de .13, los mixins no están deprecados y van a ser deprecados, ¿qué cambió? Mira, los mixins no eran una gran solución desde el principio.

Sufren problemas de indirección, mantenimiento y, lo más importante, rompen la composición. La composición es un concepto fundamental en React. Este artículo de blog todavía está disponible si quieres leerlo, pero la versión resumida es que los mixins no estaban destinados a esto. Se crearon como una vía de escape. Han pasado tres años desde que se lanzó React. El panorama ha cambiado. Ahora, varias bibliotecas de Vue adoptan un modelo de componentes similar a React. El uso de la composición en lugar de la herencia para construir interfaces de usuario declarativas ya no es una novedad.

Anteriormente, los mixins no se consideraban perjudiciales en la historia de React, pero a medida que React se volvió más popular y se adoptó la composición, nos dimos cuenta de que los mixins eran perjudiciales y que no necesitábamos la vía de escape que proporcionaban. Había opciones mejores que se ajustaban al modelo compositivo de React, como los componentes de orden superior. Un componente de orden superior es una función que toma un componente y devuelve un nuevo componente, y a menudo se le proporciona funcionalidad adicional. Este componente withCounter es un componente de orden superior, y por cierto, eso es un poco largo, así que voy a empezar a llamarlos HOC. Este HOC recibe un componente y proporciona un contador y una función para incrementar ese contador.

Aquí hay un componente de botón que espera una función de incremento y un contador, y aquí proporciono el componente de botón al HOC y obtengo un nuevo botón de contador con toda la funcionalidad que necesito. Este es un ejemplo muy forzado, pero esa es la idea principal. Los HOC todavía tienen problemas como colisiones de nombres, pero ahora tenemos una opción para reutilizar código con componentes de clase y es compositiva. Ahora podemos agregar componentes de orden superior como la próxima generación de reutilización de código en React. Sé que no parece así, pero con esa adición, estamos realmente cerca de tener un React moderno.

Más cerca de lo que piensas. Este árbol en realidad no cambia durante mucho tiempo. La próxima versión importante de React es la versión 15. Sí, lo sé. Pasamos de la versión .14 a la 15. Las versiones anteriores de React estaban destinadas a llegar a una versión estable 1.0, pero React ya era estable y lo había sido durante un tiempo. Así que simplemente pasamos a la versión 15. Y la versión 15 tiene muchas actualizaciones, pero nada que cambie fundamentalmente la estructura de los componentes. Así que la vamos a omitir y pasar a la siguiente versión importante. La versión 16. En su lanzamiento inicial, la versión 16.0 introduce fragmentos, límites de errores, portales y más.

Pero no hubo cambios reales en los componentes o ciclos de vida hasta un poco más tarde. Por lo tanto, me refiero a las versiones 16.3 y 16.8 como dos lanzamientos importantes que no fueron lanzamientos importantes. Técnicamente, estos son lanzamientos menores, pero es cuando se introducen las deprecaciones de los ciclos de vida y los hooks están disponibles. Las deprecaciones de los ciclos de vida son un poco impactantes. Recuerda que React fue introducido y desde entonces no ha habido cambios significativos en los ciclos de vida, pero en la versión 16.3, se marcan tres ciclos de vida como inseguros. Los ciclos de vida en sí no se eliminan, pero para usarlos, ahora necesitas usar el prefijo inseguro.

Y esto es para el montaje del componente, la actualización del componente y la recepción de props del componente. Ahora, ¿por qué estos cambios y por qué ahora? La respuesta es Fiber. Fiber es el reconciliador de React y te lo voy a explicar muy, muy rápido. Si estás interesado en esto, hay muchos recursos más detallados, pero para contextualizar estos cambios en los ciclos de vida, esto es lo que necesitas saber. Antes de Fiber, el reconciliador usaba la recursión, pero la recursión no te permite detener y comenzar un proceso. Fiber puede hacerlo, por lo que React puede hacer un trabajo, pausar, permitir que el navegador haga un trabajo y luego reanudar su propio trabajo, y así sucesivamente. Y debido a que el trabajo se puede pausar y reanudar, algunos métodos de ciclo de vida eran inseguros. Esperamos que el montaje del componente sea seguido por el desmontaje del componente, pero con Fiber es posible que el montaje del componente se llame varias veces y que el desmontaje del componente no se llame en absoluto. Por lo tanto, el trabajo puede detenerse antes de que se monte el componente y por eso es inseguro. Para ayudar con estos cambios, se introdujeron nuevos métodos de ciclo de vida. Así que tenemos el método getDerivedStateFromProps y el método getSnapshotBeforeUpdate. No voy a perder tiempo explicando estos, hay una gran documentación disponible si no te resultan familiares, pero estos son los primeros nuevos ciclos de vida en toda la historia de React, y esta también es la última evolución en ese lado del árbol. El lado más centrado en los componentes de clase, los ciclos de vida y los HOC. A medida que avanzamos en nuestra línea de tiempo, se introducen los hooks.

Nuevamente, no voy a explicar los hooks, pero son una evolución de los componentes de función. Ahora podemos usar estado en los componentes de función y hay otros hooks que nos permiten acceder a las capacidades que antes estaban limitadas solo a los componentes de clase. Sin embargo, notarás que no conecto la rama de los ciclos de vida con los hooks. Y eso es porque los hooks no son ciclos de vida. No hay ciclos de vida reales en los componentes de función, eso es el futuro de React. useEffect puede ejecutarse una vez, se puede proporcionar una función de limpieza, pero eso no son ciclos de vida. Los hooks también son una opción completamente nueva para la reutilización de código que no está relacionada con los HOC o los mixins, es una nueva rama por sí misma. Y así, llegamos al final de la línea de tiempo. Llegó rápido, lo sé. La versión 17 se lanzó sin nuevas características visibles para los desarrolladores y aquí estamos en el React moderno.

Nuestro árbol evolutivo sigue sin cambios. Esto podría hacernos preguntar, ¿qué sigue? Tengo algunas suposiciones, quiero decir, el equipo de React compartió su investigación sobre los componentes del servidor el año pasado, eso podría ser una rama en este árbol. O al mirar los componentes de función en hooks, esa parte del árbol está un poco vacía, así que tal vez ahí es donde veremos alguna evolución.

La verdad es que no lo sé realmente. Lo que sí sé es que, al escribir esta charla, me di cuenta de cuánto había olvidado sobre los primeros tiempos de React. Supongo que esa es la ventaja de poder avanzar sin mirar atrás. Y si eres nuevo en React, te va a pasar a ti también, vas a olvidar cómo solían ser las cosas.

Oh, y no puedo esperar ese momento para ti, porque no solo React evolucionó en ese tiempo, tú también lo hiciste. Vas a poder ver cuánto has avanzado. Y con eso, solo quiero decir, gracias a todos por escuchar. Nos vemos en línea y algún día en el mundo real también. ♪♪