تفاعل مع أفضل الممارسات والنصائح التي يجب أن يعرفها كل مطور. الجزء 1

مرحبا يا هبر! أقدم إليكم ترجمة المقال "تفاعل مع أفضل الممارسات ونصائح يجب على كل مطور تفاعل أن يعرف النقطة 1" بواسطة Alex Devero.



React هي واحدة من المكتبات الأكثر شعبية لبناء واجهات المستخدم التفاعلية. في هذه المقالة ، سأريك بعض الأمثلة على أفضل ممارسات React التي ستساعدك على أن تصبح مطورًا أفضل. تحقق من هذه التعليمات للحصول على أفضل في كتابة رمز رد الفعل.

المحتويات:

1. حافظ على مكوناتك صغيرة
2. تجنب تكديس المكونات
3. تقليل استخدام مكونات الدولة
4. استخدام المكونات الوظيفية مع السنانير والمذكرة بدلا من المكونات في الطبقات
5. لا تستخدم الدعائم في حالتها الأصلية.

خاتمة: تفاعل مع أفضل الممارسات والنصائح التي يجب على كل مطور معرفتها الجزء 1

1. حافظ على مكوناتك صغيرة

يعد الاحتفاظ بالمكونات صغيرة الحجم أحد أفضل ممارسات React التي يمكن أن تعمل العجائب. يمكن أن يساعدك تطبيق هذه الممارسة التي تبدو بسيطة على كتابة تعليمات برمجية أكثر نظافة يمكن صيانتها. ناهيك عن أنه يمكن أن يساعد في الحفاظ على العقل ، أو على الأقل ما تبقى.

هناك قاعدة واحدة ثبت من الإبهام التي يمكنك استخدامها. ألقِ نظرة على طريقة العرض. إذا كان يحتوي على أكثر من 10 سطور ، فمن المحتمل أن يكون مكونك كبيرًا جدًا ، كما أنه مرشح جيد لإعادة تشكيل وتقسيمه إلى عدة مكونات أصغر. تذكر أن إحدى أفكار استخدام React ، أو جزء من فلسفته ، هي إعادة استخدام الكود.

الهدف هو إنشاء أجزاء من التعليمات البرمجية التي تكتبها مرة واحدة ، ثم استخدامها مرارًا وتكرارًا عند الحاجة. من وجهة النظر هذه ، ليس من المنطقي دمج كل بياناتك في مكون واحد كبير ، ملف واحد. وحتى إذا كنت لا تهتم حقًا برمز يمكن إعادة استخدامه ، فكر في الأمر. ما مدى سهولة دعم المكونات التي تحتوي على مئات أسطر التعليمات البرمجية؟

سيكون من الصعب الحفاظ على هذا المكون وتصحيحه وتحديثه. هذا يعني أيضًا أن أي عمل مع هذا المكون سيستغرق وقتًا أطول. بمعنى آخر ، فإن أداءك الكلي سيعاني. وعاجلاً أم آجلاً ، سوف يدفعك ذلك إلى الجنون. أو ستجعل زملائك في الفريق وزملائك مجانين ، وسيبدأون في دفعك إلى الجنون.

مهما اخترت ، ستفقد عقلك قريبًا وربما تصنع أعداء لنفسك. لا يستحق كل هذا العناء. حافظ على مكوناتك صغيرة. حافظ على الصداقات والعقلانية والوقت والإنتاجية. تبسيط تصحيح الأخطاء وتحديثها وصيانتها. النظر في مثال واحد.

كان

/// // file: index.jsx import React from 'react' const books = [ { category: 'Business', price: '$20.00', name: 'Private Empires', author: 'Steve Coll' }, { category: 'Philosophy', price: '$25.00', name: 'The Daily Stoic', author: 'Ryan Holiday' }, { category: 'Sport', price: '$15.95', name: 'Moneyball', author: 'Michael Lewis' }, { category: 'Biography', price: '$21.00', name: 'Titan', author: 'Ron Chernow' }, { category: 'Business', price: '$29.99', name: 'The Hard Thing About Hard Things', author: 'Ben Horowitz' }, { category: 'Fiction', price: '$4.81', name: 'Limitless: A Novel', author: 'Alan Glynn' } ] class Bookshelf extends React.Component { render() { const tableRows = [] this.props.books.forEach((book) => { tableRows.push( <tr> <td>{book.name}</td> <td>{book.author}</td> <td>{book.price}</td> <td>{book.category}</td> </tr> ) }) return ( <div> <form> <input type="text" placeholder="Search..." /> <button>Search</button> </form> <table> <thead> <tr> <th>Name</th> <th>Author</th> <th>Price</th> <th>Category</th> </tr> </thead> <tbody>{tableRows}</tbody> </table> </div> ) } } // Render Bookshelf component ReactDOM.render(<Bookshelf books={booksData} />, document.getElementById('container')) 

أصبح

 /// // file: books-data.js const books = [ { category: 'Business', price: '$20.00', name: 'Private Empires', author: 'Steve Coll' }, { category: 'Philosophy', price: '$25.00', name: 'The Daily Stoic', author: 'Ryan Holiday' }, { category: 'Sport', price: '$15.95', name: 'Moneyball', author: 'Michael Lewis' }, { category: 'Biography', price: '$21.00', name: 'Titan', author: 'Ron Chernow' }, { category: 'Business', price: '$29.99', name: 'The Hard Thing About Hard Things', author: 'Ben Horowitz' }, { category: 'Fiction', price: '$4.81', name: 'Limitless: A Novel', author: 'Alan Glynn' } ] export default booksData /// // file: components/books-table.jsx import React from 'react' class BooksTable extends React.Component { render() { const tableRows = [] this.props.books.forEach((book) => { tableRows.push( <tr> <td>{book.name}</td> <td>{book.author}</td> <td>{book.price}</td> <td>{book.category}</td> </tr> ) }) return ( <table> <thead> <tr> <th>Name</th> <th>Author</th> <th>Price</th> <th>Category</th> </tr> </thead> <tbody>{tableRows}</tbody> </table> ) } } export default BooksTable /// // file: components/search-bar.jsx import React from 'react' class SearchBar extends React.Component { render() { return ( <form> <input type="text" placeholder="Search..." /> <button>Search</button> </form> ) } } export default SearchBar /// // file: components/bookshelf.jsx import React from 'react' // Import components import BooksTable from './components/books-table' import SearchBar from './components/search-bar' class Bookshelf extends React.Component { render() { return ( <div> <SearchBar /> <BooksTable books={this.props.books} /> </div> ) } } export default Bookshelf /// // file: index.jsx import React from 'react' // Import components import Bookshelf from './components/bookshelf // Import data import booksData from './books-data' // Render Bookshelf component ReactDOM.render(<Bookshelf books={booksData} />, document.getElementById('container')) 

2. تجنب تراكم المكونات

يجب أن تطبق كل قاعدة بحذر. ينطبق هذا أيضًا على أفضل ممارسات React ، خاصة تلك السابقة. عندما يتعلق الأمر بالمكونات ، من السهل جدًا الإفراط في ذلك وكتابة حتى أصغر أجزاء التعليمات البرمجية في شكل مكونات. لا تفعل هذا. ليس من المنطقي جعل كل فقرة أو امتداد أو مكون مكونًا.
فكر قبل أن تبدأ في تقسيم كل مكون إلى أجزاء صغيرة. يمكنك أن تفكر في المكون على أنه مزيج من "HTML" ، والذي يفعل شيئًا واحدًا فقط ، كونه مستقلاً ، وسوف يدركه المستخدم ككل. هل يعقل أن يجعل هذا الجزء من الكود مكونًا؟ إذا لم يكن كذلك ، ادمج هذا الرمز. خلاف ذلك ، تقسيم عليه.

دعونا نلقي نظرة على بعض الأمثلة لتوضيح هذا التعريف للمكون. مثال واحد هو حوار مشروط. يمكن أن يتكون هذا المكون من العديد من العناصر الصغيرة ، مثل divs والعناوين وفقرات النص والأزرار وما إلى ذلك. نظريا ، كل هذه العناصر يمكن تمييزها إلى مكونات صغيرة.

في الممارسة العملية ، هذا لا طائل منه. نعم ، يمكن أن توجد بعض هذه العناصر بشكل مستقل عن بعضها البعض. ومع ذلك ، هل من المفيد حقًا إنشاء مكون يتكون من فقرة واحدة أو عنوان واحد فقط؟ ماذا سيحدث بعد ذلك؟ مكون للتسمية ، المدخلات أو حتى تمتد؟ هذا النهج غير مستدام.

لحسن الحظ ، هناك طريقة أخرى للنظر في هذا. يمكنك استخدام منهجية التصميم الذري كدليل. في التصميم الذري ، ينقسم كل شيء إلى ست فئات: الذرات والجزيئات والكائنات الحية والقوالب والصفحات والأدوات المساعدة. تبدأ بأصغر العناصر ، مثل الأزرار والروابط والاختصارات والمدخلات ، إلخ. هذه ذرات.

ثم تجمع الذرات وتصنع الجزيئات. يمكن أن تكون أمثلة الجزيئات عبارة عن مربع حوار مشروط أو نموذج أو نافذة منبثقة أو قائمة منسدلة أو التنقل وما إلى ذلك. علاوة على ذلك ، يمكنك الجمع بين جزيء مع آخر أو مع ذرة وإنشاء كائن حي. مثال على كائن حي هو العنوان أو قائمة المنتجات أو سلة التسوق. لم تعد القوالب والصفحات والأدوات المساعدة مهمة.

كيف يمكن الجمع بين التصميم الذري وهاتين أفضل الممارسات لمكونات React؟ دعونا لا تعقيد. يمكن للمكون أن يكون أكثر من ذرة ، أي جزيء ، كائن حي ، أو حتى قالب أو صفحة ، إذا تم نقلها إلى الحد الأقصى. في هذا المعنى ، فإن التسمية ، العنوان ، الفقرة ليست مكونات ، لأنها ذرات.
ومع ذلك ، مربعات حوار مشروطة ، النماذج ، النوافذ المنبثقة ، القوائم المنسدلة ، إلخ. هي مكونات ، لأنها تتعلق إما بالجزيئات أو بفئة الكائن الحي. لا تزال هناك بعض العناصر المشكوك فيها ، مثل زر. نعم ، من وجهة نظر التركيب الذري فهي ذرة. ومع ذلك ، يمكن أن توجد بشكل مستقل ، في العديد من الاختلافات ، ولا تزال تعمل.

في مثل هذه الحالات ، أقترح عدم التفكير في أفضل ممارسات React ، وأسترشد فقط بغرائزي الداخلية. في النهاية ، أنت الذي ستعمل مع الكود. الشيء المهم هو أنك مرتاح. لذلك لا تتبع بشكل أعمى بعضًا من أفضل الممارسات. وإذا كنت تعمل في فريق؟ شارك أفكارك حول هذا الأمر مع زملائك.

3. الحد من استخدام مكونات الدولة

هذا هو واحد من أفضل ممارسات React التي تم تطبيقها لبعض الوقت. ومع ذلك ، أصبحت هذه الممارسة أكثر شعبية مع ظهور React 16.8.0 وخطافات React. قبل ذلك ، عندما تريد استخدام الحالة أو أي طريقة لدورة الحياة ، كان عليك أيضًا استخدام مكون ذي حالة. لم يكن هناك طريقة أخرى.

السنانير غيرت ذلك. بعد أن تم كشف النقاب عنها رسميًا ، لم يعد مطورو React مقتصرين على المكونات الفعالة لأنهم بحاجة إلى استخدام الحالة. بفضل الخطافات ، يمكن لمطوري React الآن كتابة مكونات عديمة الحالة باستخدام أساليب الحالة وحتى دورة الحياة كما يحلو لهم.

لماذا هذا مهم؟ مكونات عديمي الجنسية أو وظيفية هي عموما أفضل من مكونات الدولة عندما يتعلق الأمر بالأداء. السبب هو أنه لا توجد طرق لدولة أو حياة. وبعبارة أخرى ، رمز أقل لتنفيذ وكذلك نقل. بالطبع ، يمكن أن يكون هذا الاختلاف ملحوظًا ، غير مرئي تقريبًا ، إذا كنت تعمل في مشروع صغير جدًا.

ومع ذلك ، قد تضاف هذه الاختلافات الصغيرة مع نمو مشروعك. فكر أيضًا في عدد سطور التعليمات البرمجية التي يتطلبها مكون الحالة مقارنة بالخطوط الوظيفية. الوظيفة هي أيضا أقصر وغالبا ما تكون أسهل في القراءة. دعنا ننظر إلى مكون الزر ، المعرّف كمكون مع تحكم الدولة ووظائفها. أي واحد تحب أكثر؟

 // Button defined as a stateful component class Button extends React.Component { handleClick = () => { // Do something } render() { return( <button type="button" onClick={this.handleClick}>Click me</button> ) } } // Button defined as a functional component const Button = () => { const handleClick = () => { // Do something } return( <button type="button" onClick={handleClick}>Click me</button> ) } 

4. استخدام المكونات الوظيفية مع السنانير والمذكرة بدلا من المكونات في الطبقات

كما ناقشنا بالفعل ، لم تعد بحاجة إلى استخدام مكونات حالة لمجرد استخدام الحالة. علاوة على ذلك ، يعتقد بعض مطوري React أيضًا أنه في المستقبل ، سوف يبدأ React في الابتعاد عن الفصول الدراسية. هل هذا صحيح ، الآن لا يهم. الشيء المهم هو أن أحد العناصر الوظيفية يمكنه الآن استخدام الحالة بفضل الخطافات.
وثانيا ، استخدام المكونات الوظيفية له مزاياه. TLDR؟ لا يوجد فئة والميراث ومنشئ. لا يوجد هذه الكلمة. رد فعل صارم أفضل الممارسات. إشارة عالية لنسبة الضوضاء. مكونات تورم وهياكل البيانات السيئة هي أسهل على الفور. الرمز أسهل في الفهم والتحقق منه. ومرة أخرى ، الأداء أفضل.

وأكثر شيء واحد. عارض العديد من مطوري React المكونات الوظيفية. تتمثل إحدى المشكلات في أنه ، كمطور React ، لا يمكنك التحكم في عملية العرض عند استخدام مكون وظيفي. عندما يتغير شيء ما ، فإن React تقوم بإرجاع مكون وظيفي ، بغض النظر عما إذا كان المكون نفسه قد تم تغييره.
في الماضي ، كان الحل هو استخدام مكون خالص. يوفر المكون النظيف القدرة على مقارنة الحالة والدعائم. هذا يعني أن React يمكنه "التحقق" مما إذا كانت محتويات المكون أو الدعائم أو المكون نفسه قد تغيرت. إذا كان الأمر كذلك ، فسوف يعيدها. وإلا ، فسيتم تخطي إعادة التقديم وسيعيد استخدام آخر نتيجة تم تقديمها. تقديم أقل يساوي أداء أفضل.
مع React 16.6.0 ، لم تعد هذه مشكلة ، ولم تعد الحجة ضد المكونات الوظيفية صالحة. ما تغير اللعبة كان المذكرة. جلبت Memo مقارنة ضحلة مع مكون وظيفي ، والقدرة على "التحقق" مما إذا كان محتوى المكون أو الدعائم أو المكون نفسه قد تغير.

مرة أخرى ، استنادًا إلى هذه المقارنة ، ستقوم React بإرجاع المكون مرة أخرى أو إعادة استخدام نتيجة العرض الأخير. باختصار ، تتيح لك المذكرة إنشاء مكونات وظيفية "نظيفة". لم يعد هناك أي سبب لاستخدام مكونات الحالة ، أو المكونات النقية. على الأقل إذا كنت لا تحتاج إلى التعامل مع حالة صعبة.

في هذه الحالة ، يجب أن تفكر في استخدام شيء أكثر قابلية للتحجيم وإدارته ، مثل MobX أو Redux أو Flux ، بدلاً من حالة المكونات. خيار آخر ممكن هو استخدام السياق. على أي حال ، وبفضل الخطافات والمذكرات ، تعد المكونات الوظيفية بالتأكيد من أفضل ممارسات React التي تستحق التفكير فيها.

5. لا تستخدم الدعائم في حالتها الأصلية

هذه واحدة من أفضل ممارسات React التي أود أن أعرفها عندما بدأت التعلم. ثم لم أكن أعرف أن استخدام الدعائم في الحالة الأولية كانت فكرة سيئة للغاية. لماذا هذه فكرة سيئة؟ المشكلة هي أنه يتم استدعاء المنشئ مرة واحدة فقط أثناء إنشاء المكون.

هذا يعني أنه عند إجراء بعض التغييرات على الدعائم في المرة القادمة ، لن يتم تحديث حالة المكونات. وسوف تحتفظ بمعناها السابق. ثم افترضت خطأ أن الدعائم تتم مزامنتها مع الدولة. وبالتالي ، عندما تتغير بعض التفاصيل ، ستتغير الحالة لتعكس هذا التغيير. لسوء الحظ ، هذا ليس كذلك.

قد لا تكون هذه مشكلة إذا كنت تريد أن تتلقى الحالة قيمًا من الدعائم مرة واحدة فقط أثناء العرض الأولي ، ويمكنك التحكم في الحالة داخل المكون. خلاف ذلك ، يمكنك حل هذه المشكلة مع componentDidUpdate. كما يقول الاسم ، تتيح لك طريقة دورة الحياة هذه تحديث عنصر عندما يتغير شيء ما ، مثل الدعائم.

إذا قررت استخدام هذه الطريقة ، تذكر شيئًا واحدًا. لن تشارك في العرض الأولي ، ولكن فقط في المرحلة التالية. لذلك ، تأكد من تهيئة حالة المكون مع القيم اللازمة ، وربما تم الحصول عليها من الدعائم. ثم استخدم componentDidUpdate لتحديث هذه القيم والمكون حسب الحاجة.

خاتمة: تفاعل مع أفضل الممارسات والنصائح التي يجب على كل مطور معرفتها الجزء 1

تهانينا! لقد أنهيت للتو الجزء الأول من هذه السلسلة المصغرة من المقالات حول أفضل ممارسات React. اليوم ، تعرفت على خمس ممارسات يمكنك استخدامها لجعل رمز رد الفعل أقصر وأبسط وأفضل وأفضل وأسرع في القراءة والصيانة. الآن يعود الأمر إليك في تنفيذ الممارسة التي توافق عليها وتبدأ في استخدامها.

في الجزء التالي ، ستتعرف على مجموعة مختلفة من أفضل الممارسات والنصائح لمساعدتك على تحسين رمز React ، وكذلك مهارات البرمجة الخاصة بك. حتى ذلك الحين ، خذ ما تعلمته اليوم وقضي بعض وقتك في التدرب.

إذا أعجبك هذا المقال ، فيرجى الاشتراك.

تم النشر في الأصل إلى مدونة Alex Devero.