Ismerje meg a kellékek megsemmisítésének alapjait a React-ben

Amikor először megismertem az ES6-ot, haboztam használni. Sok nagyszerű dolgot hallottam a fejlesztésekről, ugyanakkor megszoktam a dolgok jó eredeti módját, és itt egy új szintaxist dobtak rám, hogy megtanuljam.

Egy ideig elkerültem azzal a feltevéssel, hogy „ha nem törik el, ne javítsa meg”, de nemrégiben imádtam az egyszerűségét és azt a tényt, hogy a JavaScriptben ez a norma.

A React segítségével, amely teljes mértékben átfogja az ES6 szintaxist, a roncsolás számos előnnyel jár a kód javításában. Ez a cikk áttekinti az objektumok megsemmisítésének alapjait, és azt, hogy ez hogyan vonatkozik a React kellékeire.

A szerkezetátalakítás okai

Javítja az olvashatóságot

Ez egy hatalmas fejlõdés a React-ben, amikor átadod a kellékeket. Ha időt szán a kellékeinek megsemmisítésére props / this.props, minden kellék előtt megszabadulhat .

Ha különböző fájlokba vonja össze az összetevőket, akkor egy praktikus hely is lesz arra, hogy a fülek váltása nélkül gyorsan hivatkozhasson arra, hogy milyen kellékeket ad le. Ez a kettős ellenőrzés segít elkapni azokat a hibákat, mint például a felesleges kellékek vagy elírások átadása.

Továbbléphet egy propTypevalidálás hozzáadásával , amely lehetővé teszi, hogy meghatározza minden átadott ajánlat típusát. Fejlesztői környezetben ez aktiválja a React-ot, hogy figyelmeztetést naplózzon, ha a típus eltér a definiáltól .

A kellékeket nehéz lehet nyomon követni a bonyolult alkalmazásokban, ezért a kellékek egyértelmű meghatározása a továbbadás során rendkívül hasznos mindenki számára, aki olvassa a kódját.

Rövidebb kódsorok

Lásd a következőket az ES6 előtt:

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

Hosszú, nehézkes és túl sok kódsort tartalmaz. A szerkezetátalakítással a kód sokkal világosabbá válik.

Az alábbi példában gyakorlatilag kettőre csökkentettük a sorok számát:

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

Szintaktikus cukor

Szebbé, tömörebbé teszi a kódot, és úgy írta, mint aki tudja, mit csinál. Kissé megismétlem az első pontot itt, de akkor is, ha ez javítja az olvashatóságot, miért ne tennéd meg?

Funkcionális és osztálykomponensek

A React-ban történő átalakítás hasznos mind a funkcionális, mind az osztály-összetevők számára, de csak kissé eltérően érhető el.

Vegyük fontolóra szülő komponenst alkalmazásunkban:

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

Funkcionális alkatrészek

Ebben a példában szeretnénk átadni egy listingobjektumot a tulajdonságok tömbjéből, hogy a gyermek komponens megjelenjen.

Így néz ki egy funkcionális komponens:

const Listing = (props) => ( 

Title: {props.listing.title}

Type: {props.listing.type}

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

);

Ez a kódblokk teljesen működőképes, de szörnyen néz ki! Mire eljutunk ehhez a Listinggyermekkomponenshez, már tudjuk, hogy hivatkozunk egy listára, ezért props.listingfeleslegesnek tűnik és úgy érzi. Ez a kódblokk a pusztítás révén sokkal tisztábbá tehető.

Ezt a function paraméterben érhetjük el, amikor átadjuk a props argumentumot:

const Listing = ({ listing }) => ( 

Title: {listing.title}

Type: {listing.type}

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

);

Még jobb, hogy a beágyazott objektumokat tovább roncsolhatjuk, mint az alábbiak:

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

Title: {title}

Type: {type}

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

);

Látja, mennyivel könnyebb ezt olvasni? Ebben a példában mind listingsa kettőt, mind a benne lévő kulcsokat megsemmisítettük listing.

Egy általános gotcha csak azokat a kulcsokat roncsolja szét, mint mi az alábbiakban, és megpróbálja elérni az objektumot:

{ location: { city, state, country } }

Ebben a forgatókönyvben nem tudnánk hozzáférni az locationobjektumhoz egy hely nevű változón keresztül.

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