Вивчіть основи деструктурного реквізиту в 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об’єкта через змінну з іменем 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! :)