עדכוני UI אופטימיים - Optimistic Updates מוסבר¶
לוחצים על לב באינסטגרם והלב מתמלא באדום מיד, לפני שיש לשרת בכלל סיכוי להגיב. מסמנים משימה כבוצעה באפליקציית To Do והיא נמחקת מהרשימה תוך שבריר שנייה. זו לא קסם, זו טכניקה שנקראת עדכון אופטימי, והיא אחת הדרכים הכי אפקטיביות לגרום לאפליקציה להרגיש מהירה גם כשהיא בעצם לא.
מה זה בעצם עדכון אופטימי¶
הרעיון פשוט: במקום לחכות לתשובת השרת לפני שמעדכנים את הממשק, אתם מעדכנים את הממשק מיד, על סמך ההנחה האופטימית שהבקשה תצליח. המשתמש לוחץ על כפתור "לייק", והלב מתמלא באותו רגע. רק ברקע, בלי שהמשתמש רואה, נשלחת בקשה לשרת שמנסה לשמור את השינוי בפועל.
זה הפוך מהגישה המסורתית, שבה מציגים מצב טעינה, מחכים לתשובה, ורק אז מעדכנים את המסך. הגישה המסורתית בטוחה יותר אבל מרגישה איטית, במיוחד בפעולות קטנות וקלות שהמשתמש מצפה שיקרו מיידית.
למה זה משנה כל כך את התחושה של האפליקציה¶
המוח האנושי רגיש מאוד לעיכובים, גם קטנים. עיכוב של חצי שנייה בין לחיצה על כפתור לתגובה חזותית כבר מספיק כדי שהאפליקציה תרגיש כבדה. כשמעדכנים את הממשק מיד, המשתמש מרגיש שהוא בשליטה, שהפעולה שלו "תפסה" באמת, גם אם ברקע עוד יש עבודה שממשיכה לקרות.
זו הסיבה שהטכניקה כל כך פופולרית בפעולות כמו לייקים, הוספת פריט לעגלת קניות, סימון משימה כבוצעה, או שליחת תגובה. אלה פעולות שברוב המקרים המוחלט מצליחות, ולכן ההימור על הצלחה משתלם.
הצד השני של המטבע - מה קורה כשזה נכשל¶
כאן מגיע החלק שהרבה מפתחים מתחילים שוכחים. אם עדכנתם את הממשק כאילו הפעולה הצליחה, ואז מתברר שהיא נכשלה, חייבים להחזיר את המצב לאחור. לב שהתמלא צריך להתרוקן שוב, פריט שנוסף לרשימה צריך להיעלם, ולצד זה כדאי להציג הודעה שמסבירה למשתמש שהפעולה לא הצליחה בפועל.
זה בדיוק המקום שבו עדכון אופטימי הופך ממשהו פשוט לכזה שדורש תכנון. צריך לשמור את המצב הקודם לפני שמשנים אותו, כדי שיהיה לאן לחזור. וצריך להחליט מה בדיוק לעשות ברגע הכישלון - האם פשוט לבטל את השינוי בשקט, או להציג הודעת שגיאה בולטת שמסבירה למשתמש מה קרה.
מזהים זמניים וסיבוכים נוספים¶
עדכון אופטימי הופך למורכב יותר כשמדובר בהוספת פריט חדש, ולא רק בשינוי פריט קיים. אם מוסיפים משימה חדשה לרשימה, לפריט הזה עדיין אין מזהה אמיתי מהשרת, כי השרת עוד לא ראה אותו. הפתרון הנפוץ הוא ליצור מזהה זמני בצד הלקוח, להציג את הפריט עם המזהה הזמני הזה, ואז כשהתשובה מהשרת מגיעה, להחליף אותו במזהה האמיתי.
זה נשמע פשוט אבל יש כאן לא מעט מקרי קצה - מה קורה אם המשתמש מספיק ללחוץ על הפריט לפני שהמזהה האמיתי הגיע? מה קורה אם שתי פעולות אופטימיות רצות במקביל? אלה בדיוק סוגי השאלות שספריות ניהול נתונים כמו React Query פותרות עבורכם באופן מובנה, עם תמיכה מוכנה בעדכונים אופטימיים ובחזרה אחורה במקרה של כישלון. אם אתם כבר עובדים עם ספרייה כזו, שווה לבדוק את התמיכה המובנית שלה בנושא לפני שאתם בונים הכל בעצמכם.
מתי לא כדאי להשתמש בטכניקה הזו¶
עדכון אופטימי לא מתאים לכל פעולה. בפעולות קריטיות, כמו תשלום או מחיקה בלתי הפיכה של נתונים, עדיף לחכות לאישור מהשרת לפני שמראים למשתמש שהפעולה הצליחה. גם בפעולות שבהן אחוז הכישלון גבוה יחסית, כמו הרשמה לשירות עם בדיקות תקינות מורכבות בצד השרת, ההימור על הצלחה פחות משתלם, כי המשתמש יראה הרבה יותר מקרים של "התבטלות" פתאומית של הפעולה שלו.
בקורס צד לקוח אנחנו נכנסים לעומק הפרקטי של הטכניקות האלה, כולל איך לבנות אותן בעצמכם לפני שאתם עוברים לספריות מוכנות.
לסיכום¶
עדכון אופטימי הוא כלי חזק שגורם לאפליקציות להרגיש מהירות ומגיבות, אבל הוא מגיע עם מחיר - צריך לתכנן מראש מה קורה כשההימור לא מצליח. תדעו להבחין באילו פעולות שווה להשתמש בטכניקה, ובאילו עדיף להישאר עם הגישה הבטוחה של חכה ואז עדכן.
נשמח לשמוע איך אתם מיישמים את זה אצלכם, בואו לשתף בדיסקורד.