React

1.2 ¿Por qué React?

En el desarrollo web del lado del cliente, desde hace tiempo se ha debatido acaloradamente sobre qué framework es el mejor. Además de las tres soluciones principales, Angular, Vue y React, también hay numerosas soluciones más pequeñas entre las que elegir, como Svelte. Como en otras áreas del desarrollo de software, no hay un ganador claro, no hay nada correcto o incorrecto, sino solo alternativas. Por lo tanto, React es “solo” una alternativa a sus competidores.

Sin embargo, React tiene un objetivo muy específico con sus características, arquitectura y filosofía. El enfoque de React está en el diseño de la interfaz de usuario, por lo que, al desarrollar, la biblioteca le brinda la libertad de diseñar todos los demás aspectos del desarrollo frontend usted mismo. Al igual que los otros marcos, React se basa en una arquitectura de componentes, pero los componentes de React son muy livianos: en el caso más simple, los componentes son funciones con un tipo de retorno específico.

Otra característica de React es que no existe una arquitectura predefinida como ocurre con Angular. Conceptos como la inyección de dependencias o los servicios son ajenos a React. Tienes la libertad de diseñar tu arquitectura según lo necesites para tu aplicación, y React te apoya en esto pero no te impone requisitos estrictos. Sin embargo, este hecho no siempre es una ventaja ya que dificulta a los principiantes el desenvolvimiento en React. Por este motivo, tanto el equipo de React como la comunidad se esfuerzan por hacer lo más fácil posible para los nuevos desarrolladores el aprendizaje de React y el uso de la biblioteca en sistemas de producción.

React sigue el enfoque de control de versiones semántico. Sin embargo, a diferencia de otros proyectos de código abierto, React no prevé un ciclo de lanzamiento regular en el que, por ejemplo, se publiquen nuevas versiones importantes cada seis meses.

NoteVersionado semántico

En el enfoque de control de versiones semántico, el número de versión de un proyecto se divide en tres números separados por un punto. Esto da como resultado un número de versión con el formato X.Y.Z. El control de versiones suele comenzar con 0 y no tiene límite superior.

El primer número del número de versión se denomina versión principal. Este número se incrementa en caso de cambios importantes, cambios que garantizan que la aplicación pueda seguir funcionando solo con ajustes en el código fuente. Un ejemplo en React es la versión 16, que introdujo el reconciliador Fiber, entre otras cosas.

El segundo número del número de versión, también conocido como versión secundaria, se incrementa en el caso de nuevas funciones. Por ejemplo, en la versión 16.8, se introdujeron los Hooks como una extensión de los componentes de funciones. El aspecto importante de una versión secundaria es que la aplicación debe poder seguir ejecutándose sin cambios en este caso.

El último número, el nivel del parche, se incrementa para corregir errores. Este tipo de actualizaciones se producen con relativa frecuencia y, por lo general, no causan ningún problema.

Los desarrolladores de React tienen cuidado de mantener al mínimo los cambios importantes, es decir, las actualizaciones importantes. Esto también se refleja en la frecuencia de los lanzamientos importantes recientes: React 15 se lanzó en abril de 2016, la versión 16 se lanzó en septiembre de 2017, React 17 en octubre de 2020 y, finalmente, React 18 en marzo de 2022.

Si hay cambios pendientes en la interfaz, como en el ciclo de vida de los componentes de clase, entonces no se introducen directamente en la siguiente versión y la versión anterior ya no es compatible. En cambio, en tal caso, los métodos anteriores se renombran y siguen estando disponibles durante un período de transición. Para tales personalizaciones, los desarrolladores de React proporcionan Codemods, que es una herramienta para la personalización automatizada del código fuente. Presentaremos esta herramienta con más detalle en el Capítulo 2. Además, el equipo de React utiliza obsolescencias. Esto significa que el equipo marca partes de la biblioteca que se eliminarán en el futuro, de modo que todos los que desarrollan aplicaciones sean advertidos y puedan programar refactorizaciones apropiadas.