Aprenda los conceptos básicos de la desestructuración de accesorios en React

Cuando supe por primera vez sobre ES6, dudaba en empezar a usarlo. Había escuchado muchas cosas buenas sobre las mejoras, pero al mismo tiempo, me había acostumbrado a la buena forma original de hacer las cosas y aquí se me lanzó una nueva sintaxis para aprender.

Lo evité por un tiempo bajo la premisa de “si no está roto, no lo arregles”, pero recientemente me he encariñado con su simplicidad y el hecho de que se está convirtiendo en la norma en JavaScript.

Con React, que adopta completamente la sintaxis de ES6, la desestructuración agrega una gran cantidad de beneficios para mejorar su código. Este artículo repasará los conceptos básicos de la desestructuración de objetos y cómo se aplica a los accesorios en React.

Razones para desestructurar

Mejora la legibilidad

Esta es una gran ventaja en React cuando estás transmitiendo accesorios. Una vez que te tomes el tiempo para desestructurar tus accesorios, puedes deshacerte props / this.propsde cada uno de ellos.

Si está abstrayendo sus componentes en diferentes archivos, también tendrá un lugar útil para hacer referencia rápidamente a los accesorios que está transmitiendo sin tener que cambiar de pestaña. Esta doble verificación le ayuda a detectar errores, como pasar el exceso de accesorios o errores tipográficos.

Puede ir un paso más allá agregando propTypevalidación, lo que le permite definir el tipo de cada accesorio que pasa. Cuando está en un entorno de desarrollo, esto activa React para registrar una advertencia si el tipo es diferente al definido .

Puede ser difícil realizar un seguimiento de los accesorios en aplicaciones complejas, por lo que definir claramente sus accesorios a medida que los transmite es inmensamente útil para cualquiera que lea su código.

Líneas de código más cortas

Consulte lo siguiente antes de ES6:

var object = { one: 1, two: 2, three: 3 }
var one = object.one;var two = object.two;var three = object.three
console.log(one, two, three) // prints 1, 2, 3

Es largo, torpe y requiere demasiadas líneas de código. Con la desestructuración, su código se vuelve mucho más claro.

En el siguiente ejemplo, hemos reducido efectivamente el número de líneas a dos:

let object = { one: 1, two: 2, three: 3 }
let { one, two, three } = object;
console.log(one, two, three) // prints 1, 2, 3

Azúcar sintáctica

Hace que el código se vea más agradable, más conciso y como si alguien que sabe lo que está haciendo lo haya escrito. Estoy reiterando un poco el primer punto aquí, pero, de nuevo, si mejora la legibilidad, ¿por qué no lo haría?

Componentes funcionales frente a componentes de clase

La desestructuración en React es útil para componentes funcionales y de clase, pero se logra de manera un poco diferente.

Consideremos un componente principal en nuestra aplicación:

import React, { Component } from 'react';
class Properties extends Component { constructor() { super(); this.properties = [ { title: 'Modern Loft', type: 'Studio', location: { city: 'San Francisco', state: 'CA', country: 'USA' } }, { title: 'Spacious 2 Bedroom', type: 'Condo', location: { city: 'Los Angeles', state: 'CA', country: 'USA' } }, ]; }
render() { return ( ); }}

Componentes funcionales

En este ejemplo, queremos pasar un listingobjeto de nuestra matriz de propiedades para que el componente secundario lo represente.

Así es como se vería un componente funcional:

const Listing = (props) => ( 

Title: {props.listing.title}

Type: {props.listing.type}

Location: {props.listing.location.city}, {props.listing.location.state}, {props.listing.location.country}

);

¡Este bloque de código es completamente funcional pero se ve terrible! Para cuando llegamos a este Listingcomponente secundario, ya sabemos que estamos haciendo referencia a una lista, por lo que se props.listingve y se siente redundante. Este bloque de código puede verse mucho más limpio mediante la desestructuración.

Podemos lograr esto en el parámetro de la función al pasar el argumento props:

const Listing = ({ listing }) => ( 

Title: {listing.title}

Type: {listing.type}

Location: {listing.location.city}, {listing.location.state}, {listing.location.country}

);

Aún mejor, podemos desestructurar aún más los objetos anidados como a continuación:

const Listing = ({ listing: { title, type, location: { city, state, country } }}) => ( 

Title: {title}

Type: {type}

Location: {city}, {state}, {country}

);

¿Puedes ver cuánto más fácil es leer esto? En este ejemplo, hemos desestructurado tanto listingslas llaves internas listing.

Un problema común es desestructurar solo las claves como lo hacemos a continuación e intentar acceder al objeto:

{ location: { city, state, country } }

En este escenario, no podríamos acceder al locationobjeto a través de una variable llamada ubicación.

In order to do so, we’d have to define it first with a simple fix like so:

{ location, location: { city, state, country } }

This wasn’t glaringly obvious to me at first, and I’d occasionally run into problems if I wanted to pass an object like location as a prop after destructuring its contents. Now you’re equipped to avoid the same mistakes I made!

Class Components

The idea is very much the same in class components, but the execution is a little different.

Take a look below:

import React, { Component } from 'react';
class Listing extends Component { render() { const { listing: { title, type, location: { city, state, country } } } = this.props;
return ( 

Title: {title}

Type: {type}

Location: {city}, {state}, {country}

) }}

You may have noticed in the parent example that we can destructure the Component object as we import React in class components. This isn’t necessary for functional components as we won’t be extending the Component class for those.

Next, instead of destructuring in the argument, we destructure wherever the variables are being called. For example, if we take the same Listing child component and refactor it into a class, we would destructure in the render function where the props are being referenced.

The downside to destructuring in class components is that you’ll end up destructuring the same props each time you use it in a method. Although this can be repetitive, I’d argue that a positive is it clearly outlines which props are being used in each method.

In addition, you won’t have to worry about side effects such as accidentally changing a variable reference. This method keeps your methods separate and clean, which can be a huge advantage for other operations during your projects such as debugging or writing tests.

Thanks for reading! If this helped you, please clap and/or share this article so it can help others too! :)