Lær det grundlæggende i destruktureringsrekvisitter i React

Da jeg først lærte om ES6, var jeg tøvende med at begynde at bruge den. Jeg havde hørt en masse gode ting om forbedringerne, men på samme tid var jeg bare blevet vant til den gode, originale måde at gøre ting på, og her blev en ny syntaks kastet på mig for at lære.

Jeg undgik det et stykke tid under forudsætning af "hvis det ikke er i stykker, skal du ikke rette det", men jeg er for nylig blevet glad for dets enkelhed og det faktum, at det er ved at blive normen i JavaScript.

Med React, der fuldt ud omfavner ES6-syntaksen, tilføjer destrukturering en række fordele ved at forbedre din kode. Denne artikel vil gennemgå det grundlæggende i destruktureringsgenstande, og hvordan det gælder for rekvisitter i React.

Årsager til destruktion

Forbedrer læsbarheden

Dette er en kæmpe opside i React, når du sender rekvisitter ned. Når du har taget dig tid til at ødelægge dine rekvisitter, kan du slippe af props / this.propsforan hver prop.

Hvis du abstraherer dine komponenter i forskellige filer, har du også et praktisk sted at hurtigt henvise til, hvilke rekvisitter du sender uden at skulle skifte fane. Denne dobbelttjek hjælper dig med at opfange fejl som at overføre overskydende rekvisitter eller skrivefejl.

Du kan gå et skridt videre ved at tilføje propTypevalidering, som giver dig mulighed for at definere typen for hver prop, du sender ind. Når du er i et udviklingsmiljø, udløser dette React til at logge en advarsel, hvis typen er forskellig fra den definerede .

Rekvisitter kan være vanskelige at holde styr på i komplekse apps, så det er utroligt nyttigt at definere dine rekvisitter, når du sender dem ned, for alle, der læser din kode.

Kortere kodelinjer

Se følgende før 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

Det er langt, klodset og tager alt for mange linjer med kode. Med destruktureringen bliver din kode meget mere tydelig.

I eksemplet nedenfor har vi effektivt skåret ned antallet af linjer til to:

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

Syntaktisk sukker

Det får koden til at se pænere ud, mere kortfattet, og som en, der ved, hvad de laver, skrev den. Jeg gentager noget det første punkt her, men hvis det forbedrer læsbarheden, hvorfor så ikke gøre det igen?

Funktionelle kontra klasse komponenter

Destruktion i React er nyttigt for både funktionelle og klassekomponenter, men opnås bare en smule anderledes.

Lad os overveje en overordnet komponent i vores ansøgning:

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

Funktionelle komponenter

I dette eksempel ønsker vi at videregive et listingobjekt fra vores matrix med egenskaber, som den underordnede komponent skal gengives.

Sådan ser en funktionel komponent ud:

const Listing = (props) => ( 

Title: {props.listing.title}

Type: {props.listing.type}

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

);

Denne kodeblok er fuldt funktionel, men ser forfærdelig ud! Når vi kommer til denne Listingunderordnede komponent, ved vi allerede, at vi henviser til en fortegnelse, så det props.listingser ud og føles overflødigt. Denne kodeblok kan få det til at se meget renere ud gennem destruktureringen.

Vi kan opnå dette i funktionsparameteren, når vi passerer i rekvisita-argumentet:

const Listing = ({ listing }) => ( 

Title: {listing.title}

Type: {listing.type}

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

);

Endnu bedre, vi kan yderligere destruere indlejrede genstande som nedenfor:

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

Title: {title}

Type: {type}

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

);

Kan du se, hvor meget lettere dette er at læse? I dette eksempel har vi ødelagt begge listingsog nøglerne indeni listing.

En fælles gotcha ødelægger kun nøglerne, som vi gør nedenfor, og prøver at få adgang til objektet:

{ location: { city, state, country } }

I dette scenarie ville vi ikke være i stand til at få adgang til locationobjektet via en variabel med navnet placering.

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.

Tak for læsningen! Hvis dette hjalp dig, bedes du klappe og / eller dele denne artikel, så den også kan hjælpe andre! :)