Научете основите на реструктурирането на реквизита в React

Когато за първи път научих за ES6, се колебаех да започна да го използвам. Бях чул много страхотни неща за подобренията, но в същото време току-що бях свикнал с добрия оригинален начин на правене на нещата и тук ми беше хвърлен нов синтаксис, за да се науча.

Избягвах го известно време под предпоставката „ако не се е счупил не го оправяй“, но наскоро харесах неговата простота и факта, че това се превръща в норма в JavaScript.

С React, който напълно възприема синтаксиса ES6, деструктурирането добавя множество предимства за подобряване на вашия код. Тази статия ще разгледа основите на деструктурирането на обекти и как се прилага за подпори в React.

Причини за деструктуриране

Подобрява четливостта

Това е огромно предимство в React, когато предавате реквизити. След като отделите време да деструктурирате реквизита си, можете да се отървете props / this.propsот всеки реквизит.

Ако абстрахирате компонентите си в различни файлове, ще имате и удобно място за бързо препращане на реквизита, който предавате, без да се налага да превключвате раздели. Тази двойна проверка ви помага да улавяте грешки като предаване на излишни реквизити или печатни грешки.

Можете да отидете стъпка по-нататък, като добавите propTypeвалидиране, което ви позволява да дефинирате типа на всеки реквизит, който предавате. Когато сте в среда за разработка, това задейства React за регистриране на предупреждение, ако типът е различен от дефинирания .

Реквизитите могат да бъдат трудни за проследяване в сложни приложения, така че ясното дефиниране на реквизита, докато ги предавате, е изключително полезно за всеки, който чете кода ви.

По-кратки редове код

Вижте следното преди 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

Той е дълъг, тромав и отнема твърде много редове код. С деструктурирането вашият код става много по-ясен.

В примера по-долу ефективно сме намалили броя на редовете до два:

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

Синтактична захар

Това прави кода да изглежда по-хубав, по-лаконичен и като някой, който знае какво прави, го е написал. Повтарям донякъде първата точка тук, но след това отново, ако тя подобрява четливостта, защо не го направите?

Функционални срещу клас Компоненти

Деструктурирането в React е полезно както за функционални компоненти, така и за клас, но се постига малко по-различно.

Нека разгледаме родителски компонент в нашето приложение:

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

Функционални компоненти

В този пример искаме да предадем listingобект от нашия масив от свойства, за да се изобрази дъщерният компонент.

Ето как би изглеждал функционален компонент:

const Listing = (props) => ( 

Title: {props.listing.title}

Type: {props.listing.type}

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

);

Този блок код е напълно функционален, но изглежда ужасно! Докато стигнем до този Listingдъщерен компонент, вече знаем, че се позоваваме на списък, така че props.listingизглежда и се чувства излишен. Този блок код може да се направи да изглежда много по-чист чрез деструктуриране.

Можем да постигнем това във параметъра на функцията, докато предаваме аргумента props:

const Listing = ({ listing }) => ( 

Title: {listing.title}

Type: {listing.type}

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

);

Дори по-добре, можем допълнително да деструктурираме вложени обекти като по-долу:

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

Title: {title}

Type: {type}

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

);

Можете ли да видите колко по-лесно се чете това? В този пример сме деструктурирали и двете, listingsи ключовете вътре listing.

Често срещан проблем е деструктурирането само на ключовете, както правим по-долу, и опит за достъп до обекта:

{ location: { city, state, country } }

В този сценарий няма да имаме достъп до 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! :)