למה Recoil React נשבר בקנה מידה גדול: סימפטומים וצווארי בקבוק
Recoil React מפסיק להיות צפוי בדיוק ברגע שהאפליקציה גדלה מעבר לעשרה מסכים. כל עוד יש מעט אטומים וסלקטורים, ניהול ה-state של React נראה שקוף: שמת ערך — הקומפוננטה התעדכנה. בקנה מידה גדול התמונה משתנה: אותה ישות מתחילה לחיות בשני מקומות, והממשק מגיב לשינויים שהמשתמש לא ביצע.
הסימפטום הראשון — דה-סינכרון. סלקטור שקורא כמה אטומים בבת אחת מחושב מחדש לאורך שרשרת התלויות, ואם חלק מה-state מתעדכן מחוץ לגרף (ישירות בקומפוננטה, דרך state מקומי או תופעת לוואי), חלקים שונים של המסך מציגים גרסאות שונות של אותם נתונים. המשתמש רואה מונה מיושן לצד רשימה מעודכנת, וכמעט בלתי אפשרי לשחזר זאת בסביבת בדיקות.
השני — רי-רנדורים של קומפוננטות. אטום מתעדכן בשלמותו, וכל המנויים מקבלים ערך חדש, גם אם השתנה שדה אחד מתוך עשרים. ככל שהעץ עמוק יותר, כך יקר יותר כל מעבר מיותר: זמן התגובה גדל לא באופן ליניארי אלא במדרגות, ובמסכים כבדים הקלט מתחיל לפגר אחרי הלחיצות.
השלישי — דליפות מנויים. קומפוננטה שנרשמה לאטום ופורקה ללא ביטול מנוי תקין ממשיכה להחזיק רפרנס ולקבל עדכונים. מנויים כאלה מצטברים במעברים בין אזורים, הזיכרון גדל, וחישובים מחדש של סלקטורים ברקע אוכלים בשקט את תקציב הפריים.
כאב נפרד — ריבוי האטומים. כל אטום חדש מוסיף צומת לגרף התלויות, ובלי מבנה מפורש (קיבוץ לפי דומיינים, מקור אמת יחיד לישויות קשורות) הדיבוג הופך לחיפוש מחט: לא ברור מי בדיוק דרס את הערך ולמה הסלקטור החזיר את הישן.
כל ארבע הבעיות — על ארכיטקטורת גרף ה-state, ולא על הכלי עצמו. מפרקים איך זה נסגר: היכן גבולות האטומים, איך לבודד מנויים ולשמור על תגובת הממשק עם צמיחת האפליקציה.
מה נותן ניהול מצב בנוי היטב: אפקט והשוואת גישות
ניהול מצב באפליקציית React מפסיק להיות "סתם store" כשמסכים נספרים בעשרות, והנתונים מגיעים ממספר מקורות. Recoil React פותר זאת באמצעות מודל אטומי: כל אטום הוא פיסת מצב עצמאית, ומנויים מתרעננים מחדש רק כאשר הוא משתנה.
בפועל זה מסיר את הסיבה העיקרית לירידות ביצועים — רינדורים מחדש מדורגים של כל העץ כאשר שדה אחד מתעדכן.
סלקטורים ונתונים נגזרים
סלקטור ב-Recoil הוא פונקציה טהורה מעל אטומים, ולא חישוב מחדש ידני בתוך הקומפוננטה. נתונים נגזרים (סכומים, מסננים, אגרגטים על רשימות) מחושבים פעם אחת ונשמרים במטמון עד לשינוי התלויות.
בממשקים עם טבלאות סיכום זה מסיר חישובים חוזרים בכל רינדור: רשימה של מאות שורות מסוננת ללא השהיות מורגשות, והלוגיקה של החישוב חיה במקום אחד, ולא מתפזרת בין קומפוננטות.
ארכיטקטורת מצב וצפיות
אטומים מקובצים לפי דומיינים, וסלקטורים אסינכרוניים לוקחים על עצמם טעינה ומטמון. סוג הכשל "המצב התפצל" — כאשר חלק מהמסך מציג נתונים ישנים וחלק חדשים — נסגר בכך שמקור האמת הוא אחד, והעדכונים עוברים דרך תלויות מפורשות. זמן התגובה הופך לצפוי: מנויים צרים לא גוררים אחריהם בלוקים שכנים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מצב מקומי של קומפוננטות | טפסים קטנים, ווידג'טים מבודדים | לא מתרחב: נתונים משוכפלים בין ענפי העץ |
| הקונטקסט של React | נתונים גלובליים שמשתנים לעתים רחוקות (ערכת נושא, locale) | כל שינוי מרנדר מחדש את כל צרכני הקונטקסט |
| Store חיצוני (בסגנון Redux) | אפליקציות גדולות עם משמעת עדכונים קפדנית | הרבה קוד תבניתי, אופטימיזציה ידנית של מנויים |
| מודל אטומי (Recoil) | הרבה פיסות מצב עצמאיות, נתונים נגזרים | דורש משמעת בגבולות האטומים, אחרת הקשרים מסתבכים |
Recoil נותן מנויים גרנולריים במקום שבו קונטקסט ו-store מונוליטי מפסידים במספר הרינדורים מחדש. הבחירה נקבעת על ידי מבנה הנתונים, ולא על ידי אופנה: ככל שיש יותר מקורות עצמאיים, כך גדול יותר הרווח של המודל האטומי.
כיצד אנו מגדירים מצב: שלבי עבודה הנדסית
הטמעת ניהול מצב אינה מתחילה בהתקנת ספרייה, אלא בביקורת של אפליקציית React: בוחנים את עץ הקומפוננטות, מאתרים מקומות שבהם props מועברים דרך 4-5 רמות, ומסמנים קומפוננטות שמתרנדרות מחדש בכל שינוי של ה-store הגלובלי.
במקביל בונים מפת זרימות נתונים — אילו ישויות משותפות למסכים, אילו קיימות רק בתוך ענף, ואילו משוכפלות במצב מקומי ובמטמון בקשות. בלי המפה הזו Recoil React הופך לעוד אובייקט גלובלי, ובעיית הרינדורים החוזרים חוזרת בצורה חדשה.
- ביקורת ומפת מצב. מלאי: רשימת ישויות, הבעלים שלהן, תדירות השינויים, תלויות בין מסכים. מתעדים מה נשאר במצב מקומי, מה עובר ל-store משותף, ומה — למטמון נתוני שרת.
- תכנון גרף האטומים. מפרקים את המצב לאטומים לפי גבולות שינוי, ולא לפי מבנה העמודים: אטום אחד — מקור אמת עצמאי אחד. ערכים נגזרים מוציאים לסלקטורים, כדי שהחישובים לא ישוכפלו בקומפוננטות.
- הגדרת אטומים וסלקטורים. מחברים פרוביידר שורש ברמה העליונה, מתארים אטומים עם טיפוסים, מגדירים סלקטורים לאגרגטים ולפילטרים. סלקטורים אסינכרוניים סוגרים את טעינת הנתונים, ומסירים דגלי
isLoadingידניים מהקומפוננטות. - חיבור קומפוננטות. מעבירים מסכים לקריאה וכתיבה דרך hooks, מסירים props מתווכים. מנוי ממוקד משמעו ששינוי של אטום אחד לא גורר רינדור מחדש של כל העץ.
- בדיקת ביצועים. מנתחים פרופיל רינדור לפני ואחרי: בוחנים מספר רינדורים חוזרים לפעולה, זמן תגובת הממשק לקלט, התנהגות בעדכונים המוניים. בנפרד בודקים דליפות מנויים בעת פירוק.
- רגרסיה וייצוב. מריצים תרחישים שבהם המצב משתנה מכמה מקומות בו-זמנית, בודקים rollback ושחזור לאחר שגיאות בקשות.
- העברה לצוות. תרשים גרף המצב, מוסכמות שמות לאטומים, כללים של «מה לאן שמים» וניתוח שגיאות טיפוסיות — כדי שמפתח חדש לא ייצור מקור אמת שני.
תארו את המשימה — נחזור עם הערכה ותוכנית עבודה לאפליקציה שלכם.
במה שונה מצב מקומי של רכיב מאטום גלובלי?
מצב מקומי חי בתוך רכיב אחד ומת יחד איתו: useState שומר נתונים שנחוצים רק לצומת הזה בעץ — האם רשימה נפתחת פתוחה, מה הוזן בשדה החיפוש, איזו לשונית פעילה. כל עוד הערך לא חוצה את גבול הרכיב, אין סיבה להעלות אותו למעלה: שכבת הפשטה מיותרת מסבכת את הקריאה ומוסיפה רינדורים חוזרים.
אטום גלובלי ב-Recoil React הוא צומת מצב בעל שם מחוץ לעץ הרכיבים, שאליו יכול להירשם כל רכיב ישירות, בלי עטיפות מתווכות ובלי העברת מאפיינים דרך עשרה רבדים.
הקונטקסט של React תופס עמדת ביניים ולרוב הופך למקור שגיאות. הוא עובד היטב למה שמשתנה לעתים רחוקות ונקרא על ידי רבים: ערכת עיצוב, שפה נבחרת, נתוני משתמש מאומת. אבל ברגע שמכניסים לקונטקסט ערך שמשתנה לעתים קרובות, כל צרכן מרונדר מחדש בכל שינוי — גם אם הוא צריך רק חלק מהנתונים.
אטומים פותרים זאת באופן ממוקד: הרכיב נרשם לצומת מסוים ומתעדכן רק כשזה משתנה, וערכים נגזרים מחושבים דרך סלקטורים ונשמרים במטמון.
קריטריון הבחירה פשוט ונבדק בשלוש שאלות. הראשונה: כמה רכיבים קוראים את הערך — אחד או כמה ענפים לא קשורים בעץ? השנייה: באיזו תדירות הוא משתנה — פעם בסשן או עשרות פעמים בדקה? השלישית: האם צריך לשרוד פירוק רכיב, למשל במעבר בין מסכים?
אם הערך נקרא על ידי כמה ענפים מרוחקים והוא משתנה לעתים קרובות — זה אטום. אם הוא סטטי ונחוץ כמעט לכולם — קונטקסט. אם הוא חי בתוך טופס או ווידג'ט אחד — מצב מקומי.
טעות אופיינית — לגרור לאטומים גלובליים הכל באופן גורף "לעתיד". מצב טופס שנחוץ לעמוד אחד מתחיל לחיות בצומת גלובלי זמן רב מהנדרש ודורש ניקוי ידני ביציאה מהמסך. הטעות ההפוכה — להחזיק בקונטקסט סל קניות או מסננים שמשתנים בכל קליק: הממשק מתחיל לגמגם באופן מורגש ברשימות. אנחנו מסמנים את המצב לפי הקריטריונים האלה לפני תחילת העבודה, ולא אחרי התלונות הראשונות על מהירות.
מקרה בוחן: כיצד סילקנו את חוסר הסנכרון של המצב באזור האישי
אזור אישי עם מספר בלוקים בלתי תלויים — פרופיל, התראות, היסטוריית פעולות, מונים — נתקל במהירות בבעיה: כל בלוק מושך את הנתונים שלו ושומר את המצב שלו, ובעת רענון של מדור אחד מתרנדר מחדש כל המסך.
לפני הטמעת Recoil אפליקציית ה-React התנהגה בדיוק כך: כל פעולה בווידג'ט אחד גרמה לרינדור מחדש של העץ כולו, וחלק מהנתונים שוכפלו במצב המקומי של הקומפוננטות ובמאגר המשותף.
התחלנו במדידה, ולא בשכתוב. אספנו פרופיל של רינדורים מחדש לפי תרחישי מפתח — פתיחת האזור האישי, החלפת סינון בהיסטוריה, סימון התראות כנקראו — ותיעדנו שלושה מדדים: שיעור הרינדורים המיותרים של קומפוננטות, זמן התגובה של הממשק לפעולת המשתמש ומספר הפניות לשרת עבור נתונים שכבר נטענו.
מה שינינו
המצב פוצל לאטומים: פרופיל, רשימת ההתראות, סינוני ההיסטוריה והמונים הפכו ליחידות נפרדות עם מינויים משלהם. הקומפוננטה מאזינה כעת רק לאטום שהיא זקוקה לו — רענון ההתראות אינו נוגע עוד בהיסטוריית הפעולות. ערכים נגזרים (לא-נקראו, סיכומים לפי סינון) הועברו לסלקטורים, כדי לא לאחסן ערך מחושב פעמיים.
פניות כפולות הוסרו באמצעות מטמון ברמת האטום: הנתונים נטענים פעם אחת ומשמשים מחדש את כל הבלוקים, במקום להיות מבוקשים שוב בכל מעבר בין לשוניות.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור רינדורים מיותרים | גבוה, גדל עם מספר הבלוקים | ירד פי כמה |
| זמן תגובת הממשק | השהיה מורגשת בפעולות | תגובה בטווח הנתפס כמיידי |
| פניות לשרת עבור כפילויות | חוזרות בכל מעבר | טעינה בודדת עם שימוש חוזר |
נציין בנפרד את היכולת לחזור אחורה: האטומים מבודדים, ולכן ניתן להחזיר את הסכמה הקודמת עבור בלוק אחד מבלי לגעת בשאר. הגישה מבוססת על Recoil — ספריית ניהול מצב עבור React, שבה הנתונים חיים באטומים ובסלקטורים, והקומפוננטות נרשמות באופן ממוקד.
מקרה בוחן זה של React מדגים את העיקר: אופטימיזציה של מצב אינה תלויה בספרייה, אלא בשאלה אילו נתונים ומי בדיוק קורא אותם.
היסוסים לפני הטמעה: תאימות, מיגרציה, חזרה לאחור והרשאות
מעבר ל-Recoil React הוא לעתים רחוקות "שדה ירוק" — בדרך כלל מדובר באפליקציה חיה עם מצב פעיל, מהדורות וצוות שלא יכול לעצור. לכן השאלה המרכזית אינה "איך לשכתב", אלא "איך לשכתב כך שבכל רגע ניתן יהיה לחזור אחורה".
אנו מבצעים מיגרציה של המצב בחלקים: תחילה מוציאים חלקים בלתי תלויים (ערכת נושא, מסננים, סשן משתמש) לאטומים ולסלקטורים, ומשאירים את השאר במאגר הקודם, ורק לאחר התנהגות יציבה מעבירים ענפים תלויים.
סדר כזה מספק בנייה עובדת בכל שלב ונקודת חזרה ברורה — הפעלת דגל מחזירה את הלוגיקה הקודמת בלי לחזור מהמהדורה כולה.
מה יקרה אם נצטרך לחזור מהשינויים?
החזרה מתוכננת מראש, ולא ברגע האירוע. אנו מחזיקים את המצב בשכבות מבודדות, ולכן החזרה היא החלפת מקור הנתונים עבור ענף מסוים, ולא שחזור מגיבוי. כל שלב במיגרציה מתועד כשינוי נפרד עם תיאור של מה בדיוק הושפע — ניתן לחזור נקודתית, בלי לפגוע בחלקים שכבר הועברו.
מה אם יש לנו סטאק לא סטנדרטי? Recoil משתלב באפליקציית React קיימת בלי לשכתב קומפוננטות — משתנה רק שכבת הגישה למצב, והתצוגה והלוגיקה של ההצגה נשארות. מה בנוגע להרשאות?
אנו עובדים במאגר שלכם דרך ענפים נפרדים ו-pull request, וההרשאות ניתנות לפי עקרון המינימום ההכרחי: המהנדסים שלנו אינם מקבלים גישה לסודות פרודקשן, ותצורות הסביבות מועברות דרך מערכת ניהול הסודות שלכם.
הלקוח מקבל לידיו:
- תרשימי זרימת נתונים: אילו אטומים וסלקטורים קיימים, מי קורא אותם ומי משנה אותם;
- תצורות אטומים עם תיאור מפתחות, ערכי ברירת מחדל וכללי איפוס;
- מדיניות גישה למאגר ולסביבות עם חלוקת תפקידים;
- תיעוד המצב: מחזור חיים, נקודות הרשמה, התנהגות בעת טעינה מחדש;
- מפת מיגרציה עם רשימת הענפים שהועברו ואלה שנשארו במאגר הקודם;
- הוראות חזרה לאחור עבור כל חלק שהועבר;
- מערך בדיקות המכסה מעברי מצב קריטיים.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית מיגרציה המותאמת לסטאק שלכם ולתהליכים הנוכחיים.