Fetch API: отделяне на заявката от проверката на отговора

Полезно е да знаеш

Fetch API дава на JavaScript интерфейс за изпращане на HTTP заявки и обработка на отговорите. Обикновено функцията fetch получава адрес и по желание настройки за заявката. Тя връща Promise, който при изпълнение предоставя обект Response. След това програмата може да разгледа статуса, заглавките и съдържанието. Тази последователност разделя няколко задачи, които при четене на кратък пример лесно се възприемат като едно действие: изпращане, получаване, оценяване и използване на данните. [1]

Особено важна е разликата между мрежов неуспех и HTTP отговор със статус за грешка. Fetch не отхвърля Promise само защото сървърът е отговорил с 404. Затова кодът трябва да проверява получения статус. [1] Свойството Response.ok е булева стойност, която показва дали статусът е в диапазона от 200 до 299. [2] Така приложението има удобна първа проверка, но все пак трябва да определи какво означава успешният отговор за неговата собствена задача.

Нека разгледаме измислен каталог, който зарежда данни за избрана книга. За него можем да опишем поне четири различни ситуации: книгата е намерена, адресът връща липсващ ресурс, обменът не завършва и съдържанието няма очакваните полета. Посетителят не се интересува от имената на обектите в програмата, но има нужда да разбере кой резултат е настъпил. Именно затова общото съобщение „нещо се обърка“ не е достатъчно добра спецификация на поведението.

Прочитането на тялото също е отделна асинхронна стъпка. Методът json предоставя обработка като JSON, а text позволява прочитане като текст. [1] Изборът трябва да съответства на договора с услугата. Ако приложението очаква списък от книги, практическата проверка може да опише кои полета използва и как реагира, когато те липсват. Така получаването на синтактично валидно съдържание не се смесва с потвърждение, че данните са подходящи за показване.

За учебен тест е полезно адресът да се смени с контролирани примери, които връщат различни отговори. За всеки пример записваме очаквания надпис, състоянието на бутона и съдържанието на резултатния списък. Не е необходимо да се изпращат реални промени към чужда услуга, за да се провери интерфейсът. Добре описаният сценарий позволява да се види дали програмата правилно различава получаване на отговор, успешен статус и пригодни данни.

При завършване на функцията е полезно да се провери дали всички избрани пътища приключват разбираемо. Индикаторът за зареждане трябва да има описан край, а повторният опит да започва от известно състояние. Това превръща кратката мрежова операция в завършена потребителска функция. Fetch предоставя механизма за обмен, но ясното поведение идва от отделните проверки и от предварително определеното значение на всеки възможен резултат за конкретната страница. В каталога проверката трябва да разграничава липсваща книга от неуспешно прочитане на получения отговор.