Cómo pensar en React (comenzando con 4 pasos)

Si eres un desarrollador de back-end que ingresa al espacio de desarrollo de frontend a través de React, la biblioteca de UI puede parecer extrañamente extraña o simplemente extraña. O si es un desarrollador front-end encargado de un proyecto de React por primera vez, la biblioteca tiene el potencial de hacerle cuestionar todo lo que ha conocido.

Construir con React requiere un tipo de mentalidad diferente. La libertad que permite significa que no está apoyado por la estructura o la arquitectura. No hay respaldo de un marco completo para evitar problemas con el código espagueti.

Entonces, ¿cómo es pensar en React? Aquí hay cuatro conceptos que deberían ayudarlo a pensar con más claridad cuando se trata de crear su próximo componente React.

Comience con componentes de responsabilidad única

Lo único de React que a menudo afecta a los desarrolladores que no son de React es la necesidad de desglosar la interfaz de usuario en los componentes. Es un proceso de abstracción de la interfaz de usuario en pequeñas partes similares a un lego.

Pero entonces la pregunta es: ¿qué tan pequeños deben ser estos componentes? La forma más sencilla de determinar esto es aplicar una única regla de responsabilidad. Lo que esto significa es que un componente solo debe hacer una cosa. Cada vez que un componente crece más que una sola responsabilidad, debe refactorizarse y descomponerse en una colección de componentes más pequeños.

Si bien esto es fácil de teorizar, ¿cómo podemos implementarlo en la vida real?

Un método eficaz es hacer coincidir su componente con los datos que se le proporcionan a través de JSON. Esto se debe a que lo más probable es que su aplicación dinámica esté conectada a una fuente de datos de alguna forma.

Echemos un vistazo a los datos y las maquetas a continuación.

Aquí está el JSON de su desarrollador de backend:

const CART = [
  {category: 'Vegetables', price: '$2.99', unit: 'single item', stocked: true, name: 'Lettuce'},
  {category: 'Vegetables', price: '$1.99', unit: 'kg', stocked: true, name: 'Carrots'},
  {category: 'Breads', price: '$4.99', unit: 'bag', stocked: true, name: 'Premium Burger Buns'},
  {category: 'Meat', price: '$12.99', unit: 'kg', stocked: true, name: 'Mince'},
  {category: 'Spreads', price: '$3.99', unit: 'single item', stocked: true, name: 'Mayonnaise'},
    {category: 'Spreads', price: '$13.99', unit: 'single item', stocked: false, name: 'Premium Sauce'}]

Aquí está la interfaz de usuario de su diseñador:

601b06a16bba9f098cbc3395_search

Si lo desglosamos, los datos y la interfaz de usuario anteriores se pueden resumir de la siguiente manera:

  • Una tabla de productos filtrables que contiene
    • Una barra de búsqueda
    • Una tabla de productos que contiene
      • Una categoría de producto
      • Filas de productos correspondientes

Así es como se ve cuando encierra en un círculo la interfaz de usuario con los componentes anteriores:

Cada «componente» captura una sola responsabilidad y representa una relación jerárquica entre cada componente. La categoría de producto y la fila de producto pueden verse como elementos secundarios de la tabla de productos. La tabla de productos es un elemento secundario de la tabla de productos filtrables.

Para React, descomponer su interfaz de usuario en su componente más pequeño no significa que necesite cada dato individual como su propio componente. Este es un error común para los nuevos desarrolladores de React porque existe un malentendido sobre cuán atómicos deben ser sus componentes. Aplicar la responsabilidad única a los componentes nos permite evaluar el grado de descomposición en un conjunto de elementos.

Comience con la versión estática

Al crear su interfaz de usuario, puede ser tentador codificar cada componente individual como partes separadas y ponerlos todos juntos. Esto puede ser un problema logístico, especialmente en el frente de CSS, cuando se trata de hacer que las cosas se coloquen en los lugares correctos para diferentes proporciones de visualización.

Por eso es bueno comenzar con una versión estática que muestre primero la vista completa. Una versión estática simplemente consume los datos y los presenta en la pantalla. No importa en qué orden comience a construir su interfaz de usuario. Su enfoque principal aquí es unir todas las piezas a nivel visual.

Para proyectos y UI más pequeños, es más fácil ir desde la parte superior de la jerarquía. Para proyectos más grandes, es más fácil trabajar desde la parte inferior de la jerarquía y avanzar hacia arriba y hacia afuera. Un enfoque de abajo hacia arriba también es más fácil para escribir pruebas mientras construye su interfaz de usuario.

Cuando se centra en la versión estática, no se distrae con la gestión estatal y la tarea de coordinar la construcción de cada componente fuera de contexto.

Representación mínima de estados

Este concepto es una idea de la que no se habla a menudo cuando aprendemos React. Lo que la mayoría de nosotros encontramos es que necesitamos representar nuestro estado de interfaz de usuario de alguna forma. No se hace hincapié en una representación mínima.

Pero, ¿qué es una representación mínima del estado?

Es cuando un desarrollador puede capturar la totalidad de los estados mínimos requeridos para toda su aplicación. Esto significa que no se está repitiendo en otro componente. Si se encuentra escribiendo el mismo código (o algo similar), significa que está creando duplicados y no aplica DRY en su código. La idea de DRY es simple: no se repita. Y esto es esencialmente lo que es la representación mínima de estados.

Por ejemplo, en el ejemplo de IU anterior, es posible que tenga una funcionalidad que agregue nuevos elementos a la lista. Sin embargo, para aplicar el concepto de representación mínima, no llevaría un recuento de cuántos elementos tiene. Más bien, usaría el método de conteo para realizar la tarea.

Cuando aplica una representación mínima, también significa que no está tratando con estados innecesarios, especialmente cuando los datos están fácilmente disponibles. Produce la información que necesita tal como la necesita en lugar de almacenarla como una variable separada.

Pero, ¿cómo se puede saber si algo no es un estado? Aquí hay algunas preguntas que desarrollé para ayudarme a descubrir si algo es un estado o no.

  • ¿Se transmite de un padre a través de accesorios?
  • ¿Permanece sin cambios con el tiempo?
  • ¿Puede calcularlo en función de cualquier otro estado o accesorios en su componente?

Si la respuesta es sí a cualquiera de estas preguntas, entonces no es un estado. En el ejemplo de IU anterior, las únicas dos cosas a las que no se aplican estas situaciones es el valor que un usuario escribe en la barra de búsqueda y el interruptor.

Estas sencillas preguntas pueden evitar que su aplicación React aumente innecesariamente y mantener su código enfocado en las tareas que se supone que debe hacer.

Todos los estados necesitan un hogar, pero ¿dónde?

React utiliza un flujo de datos unidireccional hacia abajo en la jerarquía. Esto significa que los niños solo pueden consumir los datos y no pueden realizar ningún cambio. Averiguar dónde debería vivir un estado es un proceso para determinar qué componente es el padre en la jerarquía.

Esto puede resultar complicado al principio. Entonces, ¿cómo puede saber dónde debería vivir un estado?

A continuación, se muestran algunos pasos sencillos que puede seguir:

  • Identifique todos los componentes que renderizan algo en función de ese estado.
  • Encuentre un componente propietario común o un componente único que exista por encima de todos los componentes que necesitan el estado en la jerarquía, es decir, el padre. Este es el componente que debe poseer el estado.
  • Si no hay ningún componente que tenga sentido para ser dueño del estado. Cree un nuevo componente solo para mantener el estado y manténgalo separado hasta que aparezca un componente lógico que se encuentre por encima de los componentes comunes.

En el ejemplo de IU anterior, puede resultar tentador poner nuestros estados en el componente Barra de búsqueda. Sin embargo, el estado también se comparte con la tabla de productos. Product Table puede verse como un hermano en lugar de un niño, por lo que se convierte en un usuario común con la barra de búsqueda. Para que sea accesible para ambos componentes, según los pasos anteriores, debe subir un nivel a la Tabla de productos filtrables, que actúa como el propietario común tanto de la Tabla de productos como de la Barra de búsqueda.

Pensamientos finales

Pensar en React es un proceso de hacer que todo lo que sucede en su aplicación suceda explícitamente. Si bien esto parece bastante simple, la tarea de estructurarlo puede atrapar a un nuevo desarrollador de React.

Lo que pasa con React es que no hay un esquema o una guía obligatoria para hacer que codifique de cierta manera. Puede ignorar todas las sugerencias anteriores y su aplicación seguirá funcionando. Sin embargo, los métodos de pensamiento que se describen en este artículo pueden ayudar a estructurar su aplicación a largo plazo al darle una base que se ajuste a un método de construcción más lógico, manejable y escalable.

Subscríbete y recibe nuevas noticias

devnow

Autor desde: agosto 12, 2020

Deje su comentario

EN ES