במאמר הזה נסביר על כמה גישות לטיפול בשגיאות בעבודה עם Fetch API. ה-Fetch API מאפשר לשלוח בקשה למשאב מרוחק ברשת. כשמבצעים קריאה מרחוק לרשת, דף האינטרנט שלכם חשוף למגוון שגיאות פוטנציאליות ברשת.
בקטעים הבאים מתוארות שגיאות אפשריות ומוסבר איך לכתוב קוד שמספק רמה סבירה של פונקציונליות ועמיד בשגיאות ובתנאי רשת בלתי צפויים. קוד עמיד שומר על שביעות הרצון של המשתמשים ושומר על רמת שירות סטנדרטית באתר.
צפייה מראש לשגיאות פוטנציאליות ברשת
בקטע הזה מתואר תרחיש שבו המשתמש יוצר סרטון חדש בשם "My Travels.mp4"
ואז מנסה להעלות את הסרטון לאתר לשיתוף סרטונים.
כשעובדים עם Fetch, קל להתמקד בנתיב הרצוי שבו המשתמש מעלה את הסרטון בהצלחה. עם זאת, יש דרכים אחרות שהן לא חלקות כל כך, אבל מפתחי האינטרנט חייבים לתכנן אותן. נתיב כזה (לא נעים) יכול לקרות בגלל שגיאה של המשתמש, תנאי סביבה בלתי צפויים או באג באתר לשיתוף סרטונים.
דוגמאות לשגיאות משתמש
- המשתמש מעלה קובץ תמונה (כמו JPEG) במקום קובץ וידאו.
- המשתמש מתחיל להעלות את קובץ הווידאו הלא נכון. לאחר מכן, באמצע ההעלאה, המשתמש מציין את קובץ הווידאו הנכון להעלאה.
- המשתמש לוחץ בטעות על 'ביטול ההעלאה' בזמן העלאת הסרטון.
דוגמאות לשינויים בסביבה
- החיבור לאינטרנט עובר למצב אופליין בזמן העלאת הסרטון.
- הדפדפן יופעל מחדש בזמן ההעלאה של הסרטון.
- השרתים של אתר שיתוף הסרטונים מופעלים מחדש בזמן שהסרטון נטען.
דוגמאות לשגיאות באתר לשיתוף סרטונים
- אתר שיתוף הסרטונים לא יכול לטפל בשם קובץ עם רווח. במקום
"My Travels.mp4"
, צריך להזין שם כמו"My_Travels.mp4"
או"MyTravels.mp4"
. - באתר לשיתוף סרטונים לא ניתן להעלות סרטון שגודל הקובץ שלו חורג מהגודל המקסימלי הקביל.
- אתר שיתוף הווידאו לא תומך בקודק הווידאו של הסרטון שהועלו.
הדוגמאות האלה יכולות לקרות בעולם האמיתי, והן אכן קורות. יכול להיות נתקלתם בדוגמאות כאלה בעבר. נבחור דוגמה אחת מכל אחת מהקטגוריות הקודמות ונדבר על הנקודות הבאות:
- מהי התנהגות ברירת המחדל אם שירות שיתוף הווידאו לא יכול לטפל בדוגמה הזו?
- מה המשתמש מצפה שיקרה בדוגמה?
- איך נוכל לשפר את התהליך?
טיפול בשגיאות באמצעות Fetch API
שימו לב שבדוגמאות הקוד הבאות נעשה שימוש ב-await
ברמה העליונה (תמיכה בדפדפנים) כי התכונה הזו יכולה לפשט את הקוד.
מתי מתקבלות שגיאות ב-Fetch API
בדוגמה הזו נעשה שימוש בהצהרה של try
/catch
block כדי לתפוס שגיאות שמתרחשות בתוך הבלוק try
. לדוגמה, אם Fetch API לא יכול לאחזר את המשאב שצוין, תופיע שגיאה. בתוך בלוק catch
כזה, חשוב לספק חוויית משתמש משמעותית. אם מוצג למשתמש סמל ספינר (ממשק משתמש נפוץ שמייצג סוג של התקדמות), אפשר לבצע את הפעולות הבאות בתוך בלוק catch
:
- מסירים את סמל הטעינה מהדף.
- עליכם לספק מסרים מועילים שמסבירים מה הבעיה ואילו אפשרויות עומדות לרשות המשתמש.
- על סמך האפשרויות הזמינות, מציגים למשתמש לחצן 'ניסיון חוזר'.
- מאחורי הקלעים, שולחים את פרטי השגיאה לשירות למעקב אחר שגיאות או לקצה העורפי. הפעולה הזו מתעדת את השגיאה כדי שניתן יהיה לאבחן אותה בשלב מאוחר יותר.
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. לפעמים, מפתחי הקצה העורפי, מהנדסי השירות ומנהלי התפעול של המפתחים יכולים לספק תובנות ייחודיות לגבי מקרים קיצוניים אפשריים שלא צפיתם.
כשיש שגיאה בניתוח התגובה מהרשת
דוגמת הקוד הזו מדגימה סוג אחר של שגיאה שעשויה להתרחש בניתוח גוף התגובה. הממשק 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)
}
סיכום
אחד מהיבטים חשובים בטיפול בשגיאות הוא הגדרת החלקים השונים שיכולים להשתבש. לכל תרחיש, חשוב לוודא שיש לכם חלופה מתאימה למשתמש. בנוגע לבקשת אחזור, כדאי לשאול את עצמכם שאלות כמו:
- מה קורה אם שרת היעד מושבת?
- מה קורה אם Fetch מקבל תגובה לא צפויה?
- מה קורה אם החיבור לאינטרנט של המשתמש נכשל?
בהתאם למורכבות של דף האינטרנט, אפשר גם לצייר תרשים זרימה שמתאר את הפונקציונליות ואת ממשק המשתמש בתרחישים שונים.