В чем преимущество обертывания fetch в обещание?
Я вижу, как люди заключают метод fetch в обещание. Я не могу понять выгоду от этого? Fetch сам возвращает обещание, и вы можете извлечь из него то, что вам нужно.
let url = 'https://jsonplaceholder.typicode.com/users';
fetch(url)
.then(function(response){
//console.info(response.json());
return response.json();
})
.then(function(data){
console.info(JSON.stringify(data));
})
.catch(function(err){
//console.info(err);
err = 'this is an error';
console.info(err);
})
по сравнению с этим
return new Promise((resolve, reject) => {
fetch(url)
.then(res => res.json())
.then(data => resolve(data))
.catch(err => reject(err));
});
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 2
"It returns a Promise that resolves to the Response to that request, whether it is successful or not."
Бессысленно. Это просто то, что делают люди, которые, вероятно, привыкли работать с такими вещами, как jQuery Deferreds, которые не имеют надлежащей реализации A+ Promise. Если бы вы хотели, вы могли бы сделать это, если бы вы использовали что-то вроде Bluebird, я думаю, но это более или менее бессмысленно.
На самом деле есть смысл. Я приведу вам три примера, где этот сценарий очень полезен.
Допустим, у нас есть много мест, в которых мы вызываем дистанционный отдых API. Может быть, сотни страниц или даже больше. И теперь нам нужно вставлять настраиваемый заголовок в каждый отправляемый запрос. Хм... Если бы у нас была наша обертка, вызываемая из многих мест, а затем одна выборка из нашей обертки, то мы можем просто добавить новый заголовок внутри нашей обертки, и все вызовы будут содержать новый заголовок.
Мы провели рефакторинг нашего кода, и теперь у нас есть новая блестящая оболочка для fetch. Мы вставили наш собственный заголовок, и все работает нормально. Но через некоторое время мы обнаружили, что, скажем, axios — гораздо лучшая библиотека, чем использование fetch. К счастью (ха!) мы завернули выборку и теперь имеем только единственное место для рефакторинга. Если бы мы этого не сделали, нам пришлось бы пройти сотни или даже больше мест, чтобы изменить... Теперь у нас есть возможность даже не просто изменить его, а реализовать что-то вроде "Стратегического шаблона", где мы можем использовать один или другой (fetch или axios), который мы можем динамически переключать.
Поскольку мы оборачиваем эти реализации, мы контролируем наш интерфейс, который мы будем использовать в дальнейшем в нашем коде. Если какая-то обернутая третья библиотека изменится, например. имя его свойства, мы исправим это только в нашей обертке. Остальная часть нашего приложения использует наш интерфейс, который остается неизменным.
Краткий обзор: когда вы его переносите, у вас теперь есть только одно место для изменения, если возникнет необходимость в этом изменении, также вы можете переключать несколько реализаций в будущем. Это хорошая практика, особенно при работе со сторонними библиотеками, заключать их в оболочку или создавать адаптеры.
Надеюсь это поможет.
Вы отвечаете на вопрос "В чем преимущество упаковки fetch в функция?". Это не то, что спросили.
Вы правы, я пропустил момент.
Пользы ноль. Это распространенная ошибка, которую люди допускают при использовании промисов. (Если
Promiseне относится к нативному промису, правильным способом его обернуть будетPromise.resolve, а не конструктор.)