Μάθετε τα βασικά των καταστρεπτικών στηριγμάτων στο 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

Συντακτική ζάχαρη

Κάνει τον κώδικα να φαίνεται πιο όμορφο, πιο σύντομο και σαν κάποιος που ξέρει τι κάνει να το έγραψε. Επαναλαμβάνω κάπως το πρώτο σημείο εδώ, αλλά και πάλι εάν βελτιώνει την αναγνωσιμότητα, γιατί δεν θα το κάνατε;

Λειτουργικά συστατικά έναντι κλάσης

Το Destructuring in 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φαίνεται και αισθάνεται περιττή. Αυτό το μπλοκ κώδικα μπορεί να γίνει πολύ πιο καθαρό με την καταστροφή.

Μπορούμε να το επιτύχουμε στην παράμετρο συνάρτησης καθώς περνάμε στο όρισμα στηρίγματα:

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.

Ένα κοινό gotcha καταστρέφει μόνο τα κλειδιά όπως κάνουμε παρακάτω και προσπαθούμε να αποκτήσουμε πρόσβαση στο αντικείμενο:

{ 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.

Ευχαριστώ για την ανάγνωση! Εάν αυτό σας βοήθησε, παρακαλώ χτυπήστε ή / και μοιραστείτε αυτό το άρθρο, ώστε να μπορεί να βοηθήσει και άλλους! :)