יישום טיפול בשגיאות במהלך שימוש ב-Fetch API

Umar Hansa

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

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

חיזוי של שגיאות רשת פוטנציאליות

בקטע הזה מתואר תרחיש שבו משתמש יוצר סרטון חדש בשם "My Travels.mp4" ואז מנסה להעלות את הסרטון לאתר לשיתוף סרטונים.

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

דוגמאות לשגיאות משתמשים

• המשתמש מעלה קובץ תמונה (כגון JPEG) במקום קובץ וידאו.
• המשתמש מתחיל להעלות את קובץ הווידאו הלא נכון. לאחר מכן, במהלך ההעלאה, המשתמש מציין את קובץ הסרטון הנכון להעלאה.
• המשתמש לוחץ בטעות על "ביטול ההעלאה" בזמן העלאת הסרטון.

דוגמאות לשינויים סביבתיים

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

דוגמאות לשגיאות באתר שיתוף הסרטונים

• אתר שיתוף הסרטונים לא יכול לטפל בשם קובץ עם רווח. במקום "My Travels.mp4", הוא מצפה לשם כגון "My_Travels.mp4" או "MyTravels.mp4".
• אתר שיתוף הסרטונים אינו יכול להעלות סרטון שגודלו חורג מגודל הקובץ המרבי המותר.
• אתר שיתוף הסרטון אינו תומך ב-codec הווידאו שנכלל בסרטון שהועלה.

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

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

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

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

פעולה	אתר שיתוף הסרטונים לא יכול לטפל בשם קובץ עם רווח. במקום "My Travels.mp4", הוא מצפה לשמות כמו "My_Travels.mp4" או "MyTravels.mp4".
מה קורה כברירת מחדל	המשתמש צריך להמתין לסיום ההעלאה. אחרי שמעלים את הקובץ ובסרגל ההתקדמות מופיע הכיתוב '100%', בסרגל ההתקדמות מוצגת ההודעה 'יש לנסות שוב'.
מה המשתמש מצפה	המשתמש מצפה לקבל התראה על מגבלות שמות הקבצים לפני תחילת ההעלאה, או לפחות במהלך השנייה הראשונה של ההעלאה.
מה אפשר לשפר	באופן אידיאלי, שירות שיתוף הסרטונים תומך בשמות קבצים עם רווחים. האפשרויות החלופיות הן להודיע למשתמש על מגבלות של שמות קבצים לפני תחילת ההעלאה. לחלופין, שירות שיתוף הסרטונים אמור לדחות את ההעלאה באמצעות הודעת שגיאה מפורטת.

טיפול בשגיאות באמצעות Fetch API

לתשומת ליבכם, בדוגמאות הבאות לקוד נעשה שימוש ברמה העליונה await (תמיכה בדפדפנים), כי התכונה הזו יכולה לפשט את הקוד.

כאשר ה-API של אחזר שולח שגיאות

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

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

try {
  const response = await fetch('https://website');
} catch (error) {
  // TypeError: Failed to fetch
  console.log('There was an error', error);
}

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

כשקוד סטטוס הרשת מייצג שגיאה

בדוגמת הקוד הזו, נשלחת בקשה לשירות בדיקה של HTTP שמגיב תמיד עם קוד הסטטוס של HTTP 429 Too Many Requests. מעניין שהתגובה לא מגיעה לבלוק catch. סטטוס 404, בין חלק מקודי הסטטוס האחרים, אינו מחזיר שגיאת רשת אלא נפתר כרגיל.

כדי לבדוק אם קוד מצב ה-HTTP בוצע בהצלחה, אפשר להשתמש בכל אחת מהאפשרויות הבאות:

• המאפיין Response.ok מאפשר לקבוע אם קוד הסטטוס היה בטווח בין 200 ל-299.
• אפשר להשתמש במאפיין Response.status כדי לבדוק אם התגובה הצליחה.
• להשתמש במטא-נתונים אחרים, כמו Response.headers, כדי להעריך אם התשובה הצליחה.

let response;

try {
  response = await fetch('https://httpbin.org/status/429');
} catch (error) {
  console.log('There was an error', error);
}

// Uses the 'optional chaining' operator
if (response?.ok) {
  console.log('Use the response here!');
} else {
  console.log(`HTTP Response Code: ${response?.status}`)
}

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

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

כשיש שגיאה בניתוח תגובת הרשת

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

let json;

try {
  const response = await fetch('https://httpbin.org/html');
  json = await response.json();
} catch (error) {
  if (error instanceof SyntaxError) {
    // Unexpected token < in JSON
    console.log('There was a SyntaxError', error);
  } else {
    console.log('There was an error', error);
  }
}

if (json) {
  console.log('Use the JSON here!', json);
}

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

שימו לב לתרחיש הבא: יש לכם משאב מרוחק שמחזיר תגובת JSON תקינה, והוא מנותח בהצלחה באמצעות השיטה Response.json(). ייתכן שהשירות יופסק. אחרי הירידה, מוחזר 500 Internal Server Error. אם לא משתמשים בשיטות מתאימות לטיפול בשגיאות במהלך ניתוח JSON, הדף עלול להיקטע עבור המשתמש בגלל שגיאה שלא טופלה.

מתי צריך לבטל את בקשת הרשת לפני שהיא מסתיימת

בדוגמה הזו לקוד נעשה שימוש ב-AbortController כדי לבטל בקשה פעילה. בקשה פעילה היא בקשת רשת שהתחילה אך לא הושלמה.

התרחישים שבהם ייתכן שתצטרכו לבטל בקשה פעילה עשויים להשתנות, אבל בסופו של דבר תלויים בתרחיש לדוגמה ובסביבה שלכם. הקוד הבא מדגים איך להעביר AbortSignal ל-Fetch API. ה-AbortSignal מצורף אל AbortController וה-AbortController כולל שיטה abort() שמציינת לדפדפן שצריך לבטל את בקשת הרשת.

const controller = new AbortController();
const signal = controller.signal;

// Cancel the fetch request in 500ms
setTimeout(() => controller.abort(), 500);

try {
  const url = 'https://httpbin.org/delay/1';
  const response = await fetch(url, { signal });
  console.log(response);
} catch (error) {
  // DOMException: The user aborted a request.
  console.log('Error: ', error)
}

סיכום

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

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

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