Creo que es justo decir que cuando se trata de Hooks, encontrarás tres tipos de desarrolladores de React: amarán la idea, odio la idea, y simplemente confundido sobre todo el asunto.

Si se encuentra entre los que se preguntan de qué se trata el ruido, este artículo le brindará el alivio que tanto necesita.

Entonces, toma un poco de café ☕, recuéstate y ¡disfruta!

Los cambios rápidos y los cambios tectónicos de la noche a la mañana no molestan a los desarrolladores de frontend. Han entendido que la resistencia es inútil y se han puesto el cinturón de seguridad para aprender una nueva Marco CSS cada año, un nuevo Marco de JavaScript cada semana (porque eso es lo rápido que parecen estar proliferando) y reescrituras completas de aplicaciones web personales y relacionadas con el trabajo cada dos años.

Y, sin embargo, nadie estaba preparado para el gigantesco cambio que trajo el equipo React de Facebook con Hooks. Repentinamente, Reaccionar desarrolladores se les decía que la antigua forma de crear aplicaciones con clases no era la mejor idea que existía; y que ahora deberían adoptar esta cosa brillante, nueva y altamente capaz llamada Hooks.

Sobre el tema de si todos deberían reescribir las clases de su aplicación React en Hooks, el equipo central de React los disuadió, argumentando que era demasiado esfuerzo. Pero ellos democracia insistió en la idea de que los componentes basados ​​en clases entrarán en modo de mantenimiento, y los Hooks son el nuevo y brillante futuro que todos quieren.

Errrrrr. . . okayyyyyy. . . . .

Esto dejó a todos rascándose la cabeza. Hooks tenía un área de superficie no trivial que cubrir, el modelo mental se puso patas arriba y la curva de aprendizaje (con muchos momentos de “¡sorpresa!”) Fue empinada. Al momento de escribir, 18 meses después del lanzamiento, Hooks se están convirtiendo más o menos en un estándar en las aplicaciones React. Conocerlos es una necesidad para los nuevos desarrolladores (al igual que, lamentablemente, conocer los componentes basados ​​en clases porque están en uso en muchos proyectos recientes / antiguos).

Pero el panorama general sigue siendo confuso; los que entienden un poco los anzuelos se han declarado "expertos", mientras que el resto anda a tientas en la oscuridad. Entre los desarrolladores senior, casi todos consideran que Hooks es una solución mucho mejor, mientras que algunos dicen que son solo otra arma en su escondite.

El quid es que los vientos soplan en la dirección de Hooks y te gusten o no, harías tu carrera un enorme favor entendiéndolos. Avancemos para comprender dos cosas básicas sobre los Hooks: 1) qué son; y 2) por qué los necesita.

Sin embargo, siento que debo resaltar el flujo de este artículo.

Normalmente, tendría sentido abordar el "qué"De algo nuevo y solo entonces pasar al"el porqué“. Sin embargo, dado que este es un artículo para desarrolladores de React confusos (o simplemente desarrolladores de frontend en general), creo que es mucho más importante abordar el problema explicando qué tipo de problemas resuelven los Hooks. Una vez hecho esto, la tensión en nuestras mentes se disolverá y conoceremos la filosofía y el pragmatismo detrás de Hooks. Y luego, convencidos de la idea (o no, aunque eso no ayudará mucho si desea convertirse / seguir siendo un desarrollador de React), podemos revisar una descripción general de lo que son los Hooks.

Why were React Hooks created?

Los Hooks no se crearon solo porque algunos ingenieros brillantes de Facebook se estaban inquietando. Verá, React es algo que Facebook se usa a sí mismo (y también en gran medida), por lo que desde el primer día, han tenido como objetivo evolucionar React en la dirección que mejor se adapte a sus necesidades (trabajo de frontend de alto rendimiento y componible). Habiendo escrito y mantenido decenas de miles de componentes, el equipo de React decidió que los componentes basados ​​en clases no estaban funcionando.

Veamos varias razones (destacadas por Facebook y otros) que hicieron que a los desarrolladores no les gustaran los componentes basados ​​en clases.

Las clases de JavaScript son una mentira.

Esta es mi queja personal con la dirección que está tomando el idioma principal. JavaScript puede parecer un lenguaje de llaves inspirado en C, pero ahí es donde termina la similitud. Pero luego, la versión ES5 / ES6 del idioma agregó "clases". De repente, el código JavaScript "moderno" hizo que los desarrolladores de otros lenguajes se sintieran como en casa:

class ShoppingCart extends BasicShoppingCart {
	constructor(items) {
    	super(items);
        this.items = items;
    }
    
    getTotalPrice() {
    	let price = 0;
        for (let item of this.items) {
        	price += item.price;
        }
        return price;
    }
    
    // and so on
}

Clases, subclases, jerarquías de herencia, constructores, captadores, establecedores, miembros estáticos (en términos generales), extends y new Palabras clave: cosas que dan orgasmos mentales a los arquitectos de OOP endurecidos por la batalla (con el debido respeto a su experiencia y capacidades). Así como incluir "Java" en el nombre del lenguaje (en sus primeros días, cuando se llamaba LiveScript) funcionó como un brillante golpe de marketing, se suponía que la palabra clave "clase" consolidaría aún más la posición y se fundiría con la multitud de lenguajes que son muy similares entre sí (PHP, Perl, Python, Ruby, Java; puede realizar una transición casi perfecta de uno a otro).

Pero las clases son una mentira (del tipo "maldito") en JavaScript. Cuando un motor JavaScript ejecuta código, no tiene noción de clases; así, una herramienta como Babel es necesario para convertir clases "modernas" y "bonitas" en funciones simples. Si hay herencia involucrada, se convierte a la , solamente tipo de herencia posible en JavaScript - Herencia prototípica.

Entonces, cuando cerramos los ojos y escribimos código basado en clases, nos mentimos a nosotros mismos y debilitamos nuestra posición para el día en que nuestro conocimiento superficial nos muerda.

Bueno, este es complicado!

A pesar del valiente intento de ocultar la palabra clave fundamental this en JavaScript, el problema surge a menudo en las clases de React (y también en las clases de JavaScript, en general). En varios casos de uso, las funciones del componente arrojan errores porque no están vinculadas al contexto correcto en ese momento de ejecución. Para solucionar esto, tienes que bind() ellos (leer este para más detalles) al principio del contexto React explícitamente, o use las funciones de flecha para devoluciones de llamada. No es un factor decisivo con seguridad, pero aumenta la carga cognitiva al agregar otra cosa más a tener en cuenta en todo momento; y, por supuesto, es el pozo en el que cae cada nuevo desarrollador de React.

Mucho ruido y pocas nueces sobre algo

La reutilización de código es un objetivo común en de desarrollo de software. Las clases pueden promover la reutilización de código en otros contextos (y lenguajes), pero en React, introducen problemas en el intercambio de código. Este fue un punto importante de debate / interés desde el principio en el mundo de React, y la comunidad finalmente desarrolló soluciones como Componentes de orden superior y Accesorios de renderizado para lidiar con eso. La idea básica es que los componentes se pasan a otros componentes, que “envuelven” alguna funcionalidad a su alrededor. Cualquiera que haya tocado el código utilizando estas "soluciones" conoce el dolor y no quiere volver a hacerlo (incluido yo mismo).

Lea esta guía para comprender Reaccionar comportamiento de renderizado.

Solo necesita leer la documentación oficial para Componentes de orden superior para ver por ti mismo lo difícil de manejar que es toda la idea. En proyectos del mundo real, a menudo es necesario compartir varias piezas de código, lo que puede resultar fácilmente en varias capas de jerarquía de envoltura de componentes. ¡Es el tipo de código que ni siquiera su autor entenderá después de unas semanas! Sí, aunque la reutilización de código no es imposible cuando se usan clases de React, es torpe y confuso.

Perforación de hélice

La perforación de accesorios es el problema al que se enfrenta (al menos en Vanilla React) cuando tiene un accesorio en lo alto de la jerarquía de componentes, y debe estar disponible para un componente hacia abajo. Aquí hay un ejemplo: considere el perfil de usuario en una aplicación web típica, que generalmente se muestra en el encabezado. Ahora, supongamos que los detalles del usuario también son necesarios en el componente de pie de página, tal vez para decir algo como “Has realizado 34 transacciones hasta ahora | Obtenga más estadísticas interesantes aquí ”. ¿Cómo hacer que la información del perfil esté disponible en el pie de página si estás usando clases? Bueno, algunos desarrolladores de React que conozco dirían "¡al diablo!" y haga una llamada adicional a la API en el pie de página también, pero esta es una práctica terrible.

El único enfoque que me viene a la mente también es la única opción: seguir pasando el apoyo del perfil del componente al componente secundario hasta que llegue al componente del pie de página. Sí, es un proceso tedioso, y sí, hace que el código sea difícil de leer (porque en los componentes intermedios, debes seguir ignorando mentalmente el accesorio, ya que no tiene ningún uso excepto simplemente estar en camino hacia abajo). Este manejo encadenado de arriba hacia abajo de una hélice se llama perforación de hélice y es un fenómeno temido en el mundo React.

Al usar clases, los desarrolladores de React lo resolverían usando algo como Redux, pero eso es demasiada inversión inicial si no va a usar Redux para todo. Con Hooks, React ha lanzado una función llamada Contexto que fue hecho a medida para este caso de uso. Ahora, Context también se puede usar con clases, pero es difícil ignorar la torpeza; Además, con Hooks, consumir múltiples contextos es muy sencillo.

Menos cosas que aprender

Esto puede sonar paradójico y el equipo de React reconoce el argumento. Una forma de escribir completamente nueva Reaccionar aplicaciones se están introduciendo; Se nos dice que no debemos reescribir o tirar el código existente basado en clases, ¡y sin embargo, el equipo de React nos dice que hay menos cosas que aprender!

"¡Que alguien me dispare!"

En realidad, la cuestión es que, a corto plazo, la complejidad y la confusión generales en el ecosistema React se dispararán (y lo ha hecho, ya que las nuevas personas que aprenden React necesitan aprender Clases, HoC, Hooks, Context, Redux y muchas otras bibliotecas así como sus maletines de esquina). Pero el punto más importante es que si Hooks resulta ser un concepto exitoso, a largo plazo, se pueden descartar una gran cantidad de conceptos, dejándonos con un pequeño núcleo de Hooks, componentes funcionales y poco más. No sucederá pronto (simplemente debido a la cantidad de código existente basado en clases), pero es donde eventualmente terminaremos.

"Actualización" de componentes sensibles

Un dilema común en React tiene que decidir si un nuevo componente debe escribirse como una clase o como una función. Para minimizar la complejidad, la práctica común ha sido comenzar con un componente funcional sin estado. Luego, si llega un momento en el que cree que el componente en cuestión necesita administrar algún estado o necesita acceso a más funciones (métodos de ciclo de vida, por ejemplo), lo convierte en un componente basado en clases. Excepto que solo necesita eliminar todo el código del componente, repensar el enfoque y luego escribir una versión basada en clases. No es divertido, sí.

Con Hooks, tales “actualizaciones” de componentes son más fáciles y suaves: un componente funcional sigue siendo un componente funcional incluso después de asumir muchas tareas; Los métodos de ciclo de vida no aparecen en Hooks, aunque hay algunas funciones similares disponibles; finalmente, cualquier funcionalidad común puede extraerse en ganchos separados y reutilizarse por otros componentes. ¿Viste la belleza en este caso? - todo es una función o un gancho (que también es una función, pero podemos hacer la distinción por el bien del desarrollo), y no hay nada de engaño cuando se trata de colocar una clavija cuadrada en un agujero redondo. 😀

Así que ahí lo tenemos. Los Hooks no están dirigidos a una sola cosa, pero son un gran cambio de paradigma. Es un inconveniente, sí, pero la experiencia del desarrollador resultante es mucho mejor (en comparación con React with classes).

Ahora que nos hemos ocupado del "por qué", dirijamos nuestra atención a lo que realmente son los Hooks.

¿Qué son los Hooks en React?

Los anzuelos son resistentes y muy fáciles de definir al mismo tiempo. La versión fácil es la que encontrarás en las oraciones iniciales de los documentos oficiales: los Hooks son una forma de escribir componentes de React sin clases; también le brindan formas de "conectarse" a las características principales de React, como el estado, el control de los renders, etc., en componentes funcionales.

Eso no ayudó mucho, ¿verdad?

Como no me ayudó la primera vez, me encontré con Hooks. Para entender lo que Hooks democracia es decir, tiene que realizar un estudio largo y paciente de sus entresijos (¡y no hay escasez de ellos!), construir aplicaciones usándolos (tal vez incluso reconstruir aplicaciones pasadas), ser mordido por casos especiales, y así sucesivamente.

Pero solo para darle una "sensación", así es como se ve el código con Hooks. Recuerde, todos los componentes son funcionales y el código relevante para un componente se define dentro de él.

import React, { useState } from 'react';

export function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

¡Sí, es el mismo componente de Contador que todos hemos escrito incontables veces mientras usamos clases! Pero puedes ver lo drásticas que son las diferencias: el constructor desaparece, acceder y cambiar de estado es mucho más simple y modular (puedes tener tantas useState() invocaciones que necesite para administrar diferentes partes del estado), y el código es más corto. En varios casos, el código resultante es mucho más corto que un componente basado en clases, simplemente porque los Hooks capturan y proporcionan la misma funcionalidad de manera sucinta.

Hay varios tipos de anzuelos y useState() es solo uno de ellos. Si tiene curiosidad por saber cuántos hay y qué hacen, eche un vistazo al oficial documentos.

En resumen

Los Hooks traen enormes cambios al ecosistema React y llegaron para quedarse. Simplifican la estructura de los componentes, la arquitectura, la jerarquía, la reutilización del código y mucho más. Si bien hay algunos críticos extremadamente vocales, la recepción general ha sido muy cálida y el futuro parece esperanzador.

Esta es una de esas contribuciones fundamentales del equipo de React que probablemente afectará a otros marcos e influirá desarrollo front-end fundamentalmente.

A continuación, averigüe cómo empezar con Reaccionar Storybook.