Web-Dev-For-Beginners/translations/he/7-bank-project/4-state-management

בניית אפליקציית בנקאות חלק 4: מושגים בניהול מצב

שאלון לפני השיעור

שאלון לפני השיעור

מבוא

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

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

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

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

דרישות מוקדמות

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

וודא שיש לך את הרכיבים הבאים מוכנים לפני שתמשיך:

הגדרה נדרשת:

• השלם את שיעור שליפת הנתונים - האפליקציה שלך צריכה לטעון ולהציג נתוני חשבון בהצלחה
• התקן Node.js במערכת שלך כדי להפעיל את ה-API של השרת
• הפעל את API השרת באופן מקומי כדי לטפל בפעולות נתוני החשבון

בדיקת הסביבה שלך:

וודא ששרת ה-API שלך פועל כראוי על ידי ביצוע הפקודה הזו בטרמינל:

curl http://localhost:5000/api
# -> should return "Bank API v1.0.0" as a result

מה הפקודה הזו עושה:

• שולחת בקשת GET לשרת ה-API המקומי שלך
• בודקת את החיבור ומוודאת שהשרת מגיב
• מחזירה מידע על גרסת ה-API אם הכול עובד כראוי

---

אבחון בעיות מצב נוכחיות

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

בואו נבצע ניסוי פשוט שמגלה את אתגרי ניהול המצב הבסיסיים:

🧪 נסה את מבחן האבחון הזה:

1. התחבר לאפליקציית הבנקאות שלך ועבור ללוח הבקרה
2. רענן את דף הדפדפן
3. שים לב מה קורה לסטטוס ההתחברות שלך

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

בעיות ביישום הנוכחי:

המשתנה הפשוט account מהשיעור הקודם יוצר שלוש בעיות משמעותיות שמשפיעות הן על חוויית המשתמש והן על תחזוקת הקוד:

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

האתגר הארכיטקטוני:

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

💡 מה אנחנו באמת מנסים להשיג כאן?

ניהול מצב עוסק למעשה בפתרון שתי חידות בסיסיות:

1. איפה הנתונים שלי?: מעקב אחר המידע שיש לנו ומאיפה הוא מגיע
2. האם כולם באותו עמוד?: לוודא שמה שהמשתמשים רואים תואם למה שבאמת קורה

תוכנית הפעולה שלנו:

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

הבנת זרימת הנתונים הזו:

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

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

⚠️ נושא מתקדם: לא נעסוק בעדכוני ממשק אוטומטיים שמופעלים על ידי שינויי מצב, מכיוון שזה כולל מושגים של תכנות תגובתי. שקול זאת כשלב הבא מצוין במסע הלמידה שלך!

משימה: מרכז את מבנה המצב

בואו נתחיל להפוך את ניהול המצב המפוזר שלנו למערכת מרכזית. השלב הראשון הזה יבסס את הבסיס לכל השיפורים שיבואו.

שלב 1: צור אובייקט מצב מרכזי

החלף את הכרזת account הפשוטה:

let account = null;

באובייקט מצב מובנה:

let state = {
  account: null
};

למה השינוי הזה חשוב:

• מרכז את כל נתוני האפליקציה במקום אחד
• מכין את המבנה להוספת מאפייני מצב נוספים בהמשך
• יוצר גבול ברור בין מצב לבין משתנים אחרים
• מבסס דפוס שמתרחב ככל שהאפליקציה שלך גדלה

שלב 2: עדכן דפוסי גישה למצב

עדכן את הפונקציות שלך כדי להשתמש במבנה המצב החדש:

בפונקציות register() ו-login(), החלף:

account = ...

ב:

state.account = ...

בפונקציה updateDashboard(), הוסף את השורה הזו בתחילת הקוד:

const account = state.account;

מה העדכונים הללו משיגים:

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

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

יישום עדכוני מצב מבוקרים

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

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

ניהול מצב בלתי ניתן לשינוי:

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

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

יתרונות של ניהול מצב בלתי ניתן לשינוי:

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

בלתי ניתן לשינוי ב-JavaScript עם Object.freeze():

JavaScript מספקת את Object.freeze() כדי למנוע שינויים באובייקטים:

const immutableState = Object.freeze({ account: userData });
// Any attempt to modify immutableState will throw an error

פירוט מה קורה כאן:

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

💡 צלילה עמוקה: למד על ההבדל בין אובייקטים בלתי ניתנים לשינוי שטחיים ועמוקים בתיעוד MDN. הבנת ההבדל הזה חיונית למבני מצב מורכבים.

משימה

בואו ניצור פונקציה חדשה updateState():

function updateState(property, newData) {
  state = Object.freeze({
    ...state,
    [property]: newData
  });
}

בפונקציה הזו, אנחנו יוצרים אובייקט מצב חדש ומעתיקים נתונים מהמצב הקודם באמצעות אופרטור הפיזור (...). לאחר מכן אנחנו מחליפים מאפיין מסוים של אובייקט המצב עם הנתונים החדשים באמצעות הערת סוגריים [property] להשמה. לבסוף, אנחנו נועלים את האובייקט כדי למנוע שינויים באמצעות Object.freeze(). כרגע יש לנו רק את המאפיין account שמאוחסן במצב, אבל עם הגישה הזו תוכל להוסיף כמה מאפיינים שתרצה למצב.

נעדכן גם את אתחול המצב כדי לוודא שהמצב ההתחלתי נעול גם הוא:

let state = Object.freeze({
  account: null
});

לאחר מכן, עדכן את פונקציית register על ידי החלפת ההשמה state.account = result; ב:

updateState('account', result);

עשה את אותו הדבר עם פונקציית login, החלף state.account = data; ב:

updateState('account', data);

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

צור פונקציה חדשה logout():

function logout() {
  updateState('account', null);
  navigate('/login');
}

ב-updateDashboard(), החלף את ההפניה return navigate('/login'); ב-return logout();;

נסה לרשום חשבון חדש, להתנתק ולהתחבר שוב כדי לבדוק שהכול עדיין עובד כראוי.

טיפ: תוכל להסתכל על כל שינויי המצב על ידי הוספת console.log(state) בתחתית updateState() ופתיחת הקונסולה בכלי הפיתוח של הדפדפן שלך.

יישום שימור נתונים

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

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

שאלות אסטרטגיות לשימור נתונים:

לפני יישום שימור, שקול את הגורמים הקריטיים הבאים:

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

אפשרויות אחסון בדפדפן:

דפדפנים מודרניים מספקים מספר מנגנוני אחסון, כל אחד מיועד למקרי שימוש שונים:

ממשקי אחסון עיקריים:

1. localStorage: אחסון מפתח/ערך מתמשך

   • משמר נתונים לאורך סשנים בדפדפן ללא הגבלה
   • שורד הפעלות מחדש של הדפדפן ואתחול המחשב
   • מוגבל לדומיין האתר הספציפי
   • מושלם להעדפות משתמש ומצבי התחברות

2. sessionStorage: אחסון סשן זמני

   • פועל באופן זהה ל-localStorage במהלך סשנים פעילים
   • מתנקה אוטומטית כאשר לשונית הדפדפן נסגרת
   • אידיאלי לנתונים זמניים שלא צריכים להישמר

3. עוגיות HTTP: אחסון משותף עם השרת

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

דרישת סריאליזציה של נתונים:

גם localStorage וגם sessionStorage מאחסנים רק מחרוזות:

// Convert objects to JSON strings for storage
const accountData = { user: 'john', balance: 150 };
localStorage.setItem('account', JSON.stringify(accountData));

// Parse JSON strings back to objects when retrieving
const savedAccount = JSON.parse(localStorage.getItem('account'));

הבנת סריאליזציה:

• ממירה אובייקטים של JavaScript למחרוזות JSON באמצעות JSON.stringify()
• משחזרת אובייקטים מ-JSON באמצעות JSON.parse()
• מטפלת באובייקטים מקוננים מורכבים ומערכים באופן אוטומטי
• נכשלת בפונקציות, ערכים לא מוגדרים והתייחסויות

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

משימה: יישום התמדה באמצעות localStorage

בואו ניישם אחסון מתמיד כך שמשתמשים יישארו מחוברים עד שיתנתקו באופן מפורש. נשתמש ב-localStorage כדי לשמור נתוני חשבון בין סשנים בדפדפן.

שלב 1: הגדרת תצורת האחסון

const storageKey = 'savedAccount';

מה מספקת הקבועה הזו:

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

שלב 2: הוספת התמדה אוטומטית

הוסף את השורה הזו בסוף הפונקציה updateState():

localStorage.setItem(storageKey, JSON.stringify(state.account));

פירוט מה קורה כאן:

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

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

שלב 3: שחזור מצב בעת טעינת האפליקציה

צור פונקציית אתחול לשחזור נתונים שמורים:

function init() {
  const savedAccount = localStorage.getItem(storageKey);
  if (savedAccount) {
    updateState('account', JSON.parse(savedAccount));
  }

  // Our previous initialization code
  window.onpopstate = () => updateRoute();
  updateRoute();
}

init();

הבנת תהליך האתחול:

• מאחזר כל נתוני חשבון שמורים מ-localStorage
• מפרש את מחרוזת ה-JSON חזרה לאובייקט JavaScript
• מעדכן את המצב באמצעות פונקציית העדכון המבוקרת שלנו
• משחזר את סשן המשתמש באופן אוטומטי בעת טעינת הדף
• מתבצע לפני עדכוני מסלול כדי להבטיח שהמצב זמין

שלב 4: אופטימיזציה למסלול ברירת המחדל

עדכן את מסלול ברירת המחדל כדי לנצל את ההתמדה:

ב-updateRoute(), החלף:

// Replace: return navigate('/login');
return navigate('/dashboard');

למה השינוי הזה הגיוני:

• מנצל את מערכת ההתמדה החדשה שלנו בצורה יעילה
• מאפשר ללוח הבקרה לטפל בבדיקות אימות
• מנתב להתחברות באופן אוטומטי אם אין סשן שמור
• יוצר חוויית משתמש חלקה יותר

בדיקת היישום שלך:

1. התחבר לאפליקציית הבנקאות שלך
2. רענן את דף הדפדפן
3. ודא שאתה נשאר מחובר ונמצא בלוח הבקרה
4. סגור ופתח מחדש את הדפדפן
5. חזור לאפליקציה שלך ואשר שאתה עדיין מחובר

🎉 הישג נפתח: יישמת בהצלחה ניהול מצב מתמיד! האפליקציה שלך מתנהגת עכשיו כמו אפליקציית אינטרנט מקצועית.

איזון בין התמדה לטריות נתונים

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

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

🧪 גילוי בעיית טריות הנתונים:

1. התחבר ללוח הבקרה באמצעות חשבון test
2. הרץ את הפקודה הזו בטרמינל כדי לדמות עסקה ממקור אחר:

curl --request POST \
     --header "Content-Type: application/json" \
     --data "{ \"date\": \"2020-07-24\", \"object\": \"Bought book\", \"amount\": -20 }" \
     http://localhost:5000/api/accounts/test/transactions

3. רענן את דף לוח הבקרה שלך בדפדפן
4. בדוק אם אתה רואה את העסקה החדשה

מה הבדיקה הזו מדגימה:

• מראה כיצד localStorage יכול להפוך ל"מיושן" (לא עדכני)
• מדמה תרחישים אמיתיים שבהם שינויים בנתונים מתרחשים מחוץ לאפליקציה שלך
• מגלה את המתח בין התמדה לטריות נתונים

אתגר התיישנות הנתונים:

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

אסטרטגיית פתרון:

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

משימה: יישום מערכת רענון נתונים

ניצור מערכת שמביאה באופן אוטומטי נתונים עדכניים מהשרת תוך שמירה על היתרונות של ניהול מצב מתמיד.

שלב 1: יצירת מעדכן נתוני חשבון

async function updateAccountData() {
  const account = state.account;
  if (!account) {
    return logout();
  }

  const data = await getAccount(account.user);
  if (data.error) {
    return logout();
  }

  updateState('account', data);
}

הבנת הלוגיקה של הפונקציה הזו:

• בודקת אם משתמש מחובר כרגע (state.account קיים)
• מנתבת להתנתקות אם לא נמצא סשן תקף
• מביאה נתוני חשבון עדכניים מהשרת באמצעות הפונקציה הקיימת getAccount()
• מטפלת בשגיאות שרת בצורה חלקה על ידי התנתקות מסשנים לא תקפים
• מעדכנת את המצב עם נתונים עדכניים באמצעות מערכת העדכון המבוקרת שלנו
• מפעילה התמדה אוטומטית ב-localStorage דרך הפונקציה updateState()

שלב 2: יצירת מנהל רענון ללוח הבקרה

async function refresh() {
  await updateAccountData();
  updateDashboard();
}

מה הפונקציה הזו משיגה:

• מתאמת את תהליך רענון הנתונים ועדכון ממשק המשתמש
• ממתינה לטעינת נתונים עדכניים לפני עדכון התצוגה
• מבטיחה שלוח הבקרה מציג את המידע העדכני ביותר
• שומרת על הפרדה נקייה בין ניהול נתונים לעדכוני ממשק משתמש

שלב 3: שילוב עם מערכת המסלולים

עדכן את תצורת המסלול שלך כדי להפעיל רענון באופן אוטומטי:

const routes = {
  '/login': { templateId: 'login' },
  '/dashboard': { templateId: 'dashboard', init: refresh }
};

איך עובד השילוב הזה:

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

בדיקת מערכת רענון הנתונים שלך:

1. התחבר לאפליקציית הבנקאות שלך
2. הרץ את פקודת curl מהשלב הקודם כדי ליצור עסקה חדשה
3. רענן את דף לוח הבקרה שלך או נווט ממנו וחזור
4. ודא שהעסקה החדשה מופיעה מיד

🎉 איזון מושלם הושג: האפליקציה שלך עכשיו משלבת את החוויה החלקה של מצב מתמיד עם הדיוק של נתוני שרת עדכניים!

אתגר סוכן GitHub Copilot 🚀

השתמש במצב סוכן כדי להשלים את האתגר הבא:

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

הנחיה: צור מערכת ניהול מצב משופרת שכוללת: 1) מערך היסטוריית מצב שעוקב אחר כל המצבים הקודמים, 2) פונקציות ביטול וחזרה שיכולות לחזור למצבים קודמים, 3) כפתורי ממשק משתמש לפעולות ביטול/חזרה בלוח הבקרה, 4) מגבלת היסטוריה של 10 מצבים כדי למנוע בעיות זיכרון, ו-5) ניקוי נכון של ההיסטוריה כאשר המשתמש מתנתק. ודא שפונקציונליות הביטול/חזרה עובדת עם שינויים במאזן החשבון ונשמרת בין רענוני דפדפן.

למד עוד על מצב סוכן כאן.

🚀 אתגר: אופטימיזציית אחסון

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

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

ניתוח אופטימיזציה:

הערך את יישום ה-localStorage הנוכחי שלך ושקול את השאלות האסטרטגיות הבאות:

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

אסטרטגיית יישום:

• זהה את הנתונים החיוניים שחייבים להתמיד (כנראה רק זיהוי משתמש)
• שנה את יישום ה-localStorage שלך כדי לאחסן רק נתוני סשן קריטיים
• ודא שנתונים עדכניים תמיד נטענים מהשרת בביקורים בלוח הבקרה
• בדוק שהגישה האופטימלית שלך שומרת על אותה חוויית משתמש

שיקול מתקדם:

• השווה את היתרונות והחסרונות בין אחסון נתוני חשבון מלאים לבין רק אסימוני אימות
• תעד את ההחלטות וההנמקות שלך עבור חברי צוות עתידיים

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

מבחן לאחר ההרצאה

מבחן לאחר ההרצאה

משימה

יישום דיאלוג "הוסף עסקה"

הנה דוגמה לתוצאה לאחר השלמת המשימה:

---

הצהרת אחריות:
מסמך זה תורגם באמצעות שירות תרגום AI Co-op Translator. למרות שאנו שואפים לדיוק, יש לקחת בחשבון שתרגומים אוטומטיים עשויים להכיל שגיאות או אי דיוקים. המסמך המקורי בשפתו המקורית צריך להיחשב כמקור סמכותי. עבור מידע קריטי, מומלץ להשתמש בתרגום מקצועי אנושי. איננו אחראים לאי הבנות או פירושים שגויים הנובעים משימוש בתרגום זה.