להגיב צריך רכיב עדכן מחדש

במהלך הפיתוח ב- React האם תהית אי פעם מתי ומדוע מפעילים את שיטת ה- render () של רכיב? או מתי להשתמש בשיטות מחזור חיים פחות ברורות צריך ComponentUpdate ()?

אם התשובה חיובית לאפליקציה שלך עשויות להיות בעיות ביצועים. קרא את הדברים ותוכל לתקן אותם בקלות.

הכל מסתכם באיך ש- React עובד מתחת למכסה המנוע. ההבטחה הגדולה של React היא שהיא בוערת במהירות בעיבוד אלמנטים בדף.

לשם כך React שומר בזיכרון שתי גרסאות של ה- DOM:

• הגרסה של ה- DOM המוצגת כעת
• הגרסה הבאה של ה- DOM שתוצג

זה משווה בין השניים ומעדכן את ה- DOM המוצג רק עם החלקים שהשתנו. תהליך זה נקרא פיוס עצים. שורש העץ המוערך לצורך פיוס הוא מרכיב שאביזריו השתנו.

גדול. עכשיו בין אם תכננתם את זה ובין אם לא, אפליקציית האינטרנט שלכם עוקבת אחר חלקי המכולה / המיצג המפוצלים במידה מסוימת. ראה כאן וכאן להגדרות. המשמעות היא שכל תצוגה מורכבת באפליקציה שלך עשויה מרכיב מכולה המחזיק את ההיגיון ויש בו הרבה להציג רכיבים רק בילדותם.

זה דפוס טוב מאוד. אם אתה מסתכל מקרוב יותר זה אומר שכל אינטראקציה של המשתמש בתצוגה תשפיע על המכולה עצמה ותגרום לעיבוד שלה ושל כל ילדיה. נניח שיש לך רשימה של אלמנטים עם תצוגה מהודרת של טקסט, תמונה וכפתור צהוב "הוסף למועדפים". המודל המינימלי עבור אלמנט רשימה יכול להיות:

product = { imageUrl: '...', title: '...', isFavourite: false }

רשימת המועדפים עשויה להגיע ממקור נתונים אחר. בלי קשר, ארגון הרכיבים שלך נראה כנראה כך:

המטפל נקרא בלחיצה על המשתמש ושומר את צד שרת המידע (או מתמיד בחנות או כל דבר אחר) ומפעיל שינוי ב- this.props.elements.

התוצאה של לחיצה בודדת מפעילה את עיבוד המכולה ושל כל השורות ברשימה רק כדי לעדכן תיבת סימון אחת.

זה המקום שבו shouldComponentUpdate () נכנס לשחק. אתה יכול להגיד ל- React לא לעבד שורות שאינן צריכות להשתמש בשיטה זו.

class ListItem extends Component { shouldComponentUpdate(nextProps, nextState) { return nextProps.isFavourite != this.props.isFavourite; } ... }

הנה מקרה קונקרטי: בפרויקט אפליקציות בשוק היה לנו מבט על ניהול מוצרים עבור המוכרים. ברשימה היה דפוס "טען יותר כאשר המשתמש גולל למטה" ופעולות פריט מוטבע "להראות / להסתיר" כדי להגדיר את הנראות של כל מוצר. הכל היה בסדר כאשר מוכרים היו מנהלים <100 מוצרים בלוח המחוונים שלהם. ואז מוכר נתון התחיל להיכנס ולפרסם יותר מ -300 מוצרים ...

היה פיגור של ~ 600ms לפני שממשק המשתמש עודכן לאחר שמשתמש לחץ על הסמל "הפעל / השבת". הפיגור בהחלט נראה על ידי משתמש הקצה. באמצעות פרופיל Chrome ראינו שלוקח ל- React ~ 2ms לעבד שורה אחת. פעמים 300 ... הגענו עד 600 ms. הוספנו את הבדיקות shouldComponentUpdate () לתנאים המתאימים. זמן העיבוד לאחר לחיצה על המשתמש היה פחות מ -10 ms ...

הקמתי כאן פרויקט קטן המאפשר לשחזר את המקרה הזה. הפעל אותו וקרא את הערות הקוד כדי לראות את הקסם קורה.

אזהרה למשתמשי Redux

הבעיה שתוארה לעיל עשויה להתרחש לעתים קרובות יותר אם אתה משתמש ב- Redux ובוחר מחדש (או בספריות צינורות פעולה "מבוססות חנות" דומות).

באמצעות Redux ובחירה מחדש אתה דוחף פעולות לחנות ואתה מחבר את המאזינים לאחסון שינויים, גם בוחרים. סלקטורים זמינים ברחבי העולם ביישום וביישום גדול, די קל לרכיבים רבים למפות לאותם סלקטורים. שינויים בחנות עשויים לעורר שינויים באביזרים ובכך הופכים שאינם רלוונטיים לחלוטין עבור רכיבים מסוימים.

הנה העצה המבלבלת: אל תשתמש ב- shouldComponentUpdate () כדי למנוע ביצועים במקרים כאלה. ההיגיון שבפנים צריך ComponentUpdate צריך להסתכל רק על מה שרלוונטי לרכיב. זה לעולם לא אמור להקדים את ההקשרים שבהם משתמשים ברכיב. הסיבה היא שהקוד שלך יהפוך במהרה לבלתי ניתן לתחזוקה.

אם יש לך בעיות מסוג זה זה אומר שמבנה החנות שלך שגוי או שהסלקטורים אינם ספציפיים מספיק. אתה צריך להגיע לסבב דוגמנות חדש.

אני ממליץ על ההנחיות המדהימות של הדוד. זה מקדם אנקפסולציה של חנויות לכל מיכל ברמה גבוהה עם אזור גלובלי עבור מבני הנתונים המרכזיים המשתרעים על פני היישום כולו. זו גישה די בטוחה כדי למנוע טעויות בדוגמנות בחנויות.

תודה שקראת! אם אהבתם, אנא לחצו על כפתור המחיאות למטה. זה עוזר לאנשים אחרים לראות את הסיפור.