در Fetch API، دریافت پاسخ HTTP مثل 404 یا 500 معمولاً باعث رد شدن Promise نمی‌شود. برنامه ابتدا باید وضعیت پاسخ را بررسی کند و سپس داده را بخواند. خطای شبکه، لغو درخواست، وضعیت HTTP و پاسخ JSON نامعتبر دلیل‌های متفاوتی برای شکست‌اند و کاربر برای هرکدام ممکن است به پیام متفاوتی نیاز داشته باشد.
وضعیت رابط را قبل از نوشتن درخواست مشخص کنید
یک فهرست محصولات چهار وضعیت عادی دارد: در حال بارگیری، دادهٔ موجود، نتیجهٔ خالی و خطا. نتیجهٔ خالی یعنی سرور پاسخ معتبر داده ولی موردی پیدا نشده است. خطا یعنی دادهٔ قابل نمایش به دست نیامده است. اگر کاربر فیلتر جدید انتخاب کند، درخواست قبلی را لغو کنید تا پاسخ قدیمی روی نتیجهٔ تازه ننشیند. در رابطی که چند منبع داده دارد، از نمایش خطای یک بخش برای کل صفحه پرهیز کنید.
یک تابع کوچک برای خواندن JSON
async function fetchJson(url, signal) {
const response = await fetch(url, { signal });
if (!response.ok) {
const error = new Error("Request failed");
error.status = response.status;
throw error;
}
return response.json();
}در رابط کاربری، وضعیت 401 را طبق جریان ورود برنامه مدیریت کنید. برای 404 توضیح دهید منبع پیدا نشده و در 503 امکان تلاش مجدد را نشان دهید. اگر سرور عمداً 204 برمی‌گرداند، تابعی استفاده کنید که انتظار بدنهٔ JSON نداشته باشد. اگر درخواست لغو شد، از نام خطای لغو یا وضعیت سیگنال برای جلوگیری از نمایش پیام اضافی استفاده کنید.
نمونهٔ تغییر سریع فیلتر
اگر فیلتر قیمت سه بار عوض شود، برای هر درخواست یک AbortController بسازید و قبل از فرستادن درخواست بعدی، قبلی را لغو کنید. هنگام به‌روزرسانی وضعیت رابط، بررسی کنید درخواست هنوز جدیدترین درخواست است. در درخواست تغییر داده، تلاش مجدد خودکار را فقط با توجه به رفتار عملیات و پشتیبانی سرور طراحی کنید. خطای موقت نباید باعث ثبت دوبارهٔ سفارش شود.
برای آزمون، پاسخ موفق، فهرست خالی، 404، بدنهٔ نامعتبر و لغو درخواست را شبیه‌سازی کنید. پیام عمومی را برای کاربر نمایش دهید و جزئیات فنی لازم برای عیب‌یابی را بدون توکن، رمز یا دادهٔ شخصی در گزارش ثبت کنید. راهنمای آزمون نرم‌افزار · مستندات Fetch در MDN