Apprenez les bases de la déstructuration des accessoires dans React

Quand j'ai découvert ES6 pour la première fois, j'hésitais à l'utiliser. J'avais entendu beaucoup de bonnes choses sur les améliorations, mais en même temps, je venais de m'habituer à la bonne façon originale de faire les choses et voici une nouvelle syntaxe qui m'a été lancée pour apprendre.

Je l'ai évité pendant un certain temps sous la prémisse «si ce n'est pas cassé, ne le réparez pas», mais j'ai récemment pris goût à sa simplicité et au fait que cela devient la norme en JavaScript.

Avec React, qui embrasse pleinement la syntaxe ES6, la déstructuration ajoute de nombreux avantages à l'amélioration de votre code. Cet article passera en revue les bases de la déstructuration des objets et son application aux accessoires dans React.

Raisons de la déstructure

Améliore la lisibilité

C'est un énorme avantage dans React lorsque vous transmettez des accessoires. Une fois que vous avez pris le temps de déstructurer vos accessoires, vous pouvez vous en débarrasser props / this.propsdevant chaque accessoire.

Si vous extrayez vos composants dans différents fichiers, vous aurez également un endroit pratique pour référencer rapidement les accessoires que vous transmettez sans avoir à changer d'onglet. Cette double vérification vous aide à détecter les erreurs telles que la transmission d'accessoires en excès ou les fautes de frappe.

Vous pouvez aller plus loin en ajoutant la propTypevalidation, qui vous permet de définir le type de chaque accessoire que vous passez. Lorsque vous êtes dans un environnement de développement, cela déclenche React pour enregistrer un avertissement si le type est différent de celui défini .

Les accessoires peuvent être difficiles à suivre dans les applications complexes, donc définir clairement vos accessoires au fur et à mesure que vous les transmettez est extrêmement utile pour quiconque lit votre code.

Lignes de code plus courtes

Voir ce qui suit avant 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

C'est long, maladroit et prend beaucoup trop de lignes de code. Avec la déstructuration, votre code devient beaucoup plus clair.

Dans l'exemple ci-dessous, nous avons effectivement réduit le nombre de lignes à deux:

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

Sucre syntaxique

Cela rend le code plus joli, plus succinct et comme quelqu'un qui sait ce qu'il fait l'a écrit. Je réitère un peu le premier point ici, mais encore une fois, si cela améliore la lisibilité, pourquoi ne le feriez-vous pas?

Composants fonctionnels et composants de classe

La déstructuration dans React est utile pour les composants fonctionnels et de classe, mais elle est réalisée un peu différemment.

Considérons un composant parent dans notre application:

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 ( ); }}

Composants fonctionnels

Dans cet exemple, nous voulons transmettre un listingobjet de notre tableau de propriétés pour le composant enfant à rendre.

Voici à quoi ressemblerait un composant fonctionnel:

const Listing = (props) => ( 

Title: {props.listing.title}

Type: {props.listing.type}

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

);

Ce bloc de code est entièrement fonctionnel mais a l'air terrible! Au moment où nous arrivons à ce Listingcomposant enfant, nous savons déjà que nous référençons une liste, donc cela props.listingsemble et semble redondant. Ce bloc de code peut être rendu beaucoup plus propre grâce à la déstructuration.

Nous pouvons y parvenir dans le paramètre de fonction en passant dans l'argument props:

const Listing = ({ listing }) => ( 

Title: {listing.title}

Type: {listing.type}

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

);

Mieux encore, nous pouvons déstructurer davantage les objets imbriqués comme ci-dessous:

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

Title: {title}

Type: {type}

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

);

Pouvez-vous voir à quel point c'est plus facile à lire? Dans cet exemple, nous avons déstructuré à la fois listingset les clés à l'intérieur listing.

Un piège courant consiste à déstructurer uniquement les clés comme nous le faisons ci-dessous et à essayer d'accéder à l'objet:

{ location: { city, state, country } }

Dans ce scénario, nous ne pourrions pas accéder à l' locationobjet via une variable nommée location.

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! :)