تعرف على أساسيات إتلاف الدعائم في 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.

شكرا للقراءة! إذا كان هذا قد ساعدك ، فيرجى التصفيق و / أو مشاركة هذه المقالة حتى تساعد الآخرين أيضًا! :)