Да, и еще хорошая практика не использовать библиотеки где можно

и так хорошо обойтись встроенными возможностями js.
Зачем вам axios если есть fetch?

нужно два инстанса на подменные апи

fetch не покрывает базовые потребности работы с апи, поэтому для него тоже понадобится обертка

А какие для примера могут возникнуть еще потребности?

хотя бы выброс ошибок при 400-500 кодах, фетч этого не умеет

fetch умеет в интерцепторы, в baseUrl? Fetch умеет автоматом парсить json и ловиться с помощью try catch? Зачем каждый раз писать для него обертку, если можно заюзать аксиос

Ну так можно проверить if(!response.ok) throw new Error(response.statusText);

Это хрень

верно, а еще можно написать свои интерсепторы, а еще можно написать автоматическое раскрытие .json(), а еще.. о, вот и обертка готова

Кто мешает сделать константы для BASE_URL и для всех точек входа и вводить их при запросе?

+++

я имею в виду HOST/first/api в константу

зачем всем этим заниматься, тратить время и тестировать, если за тебя это уже сделали? ты ничего не выиграешь, кроме того, что повторишь сделанную работу

или просто подключить axios где всё изначально есть, всё отлажено, где точно всё будет работать, да?

А что мешает заюзать готовую обертку?)

fetch умеет парсить много форматов и если при вызове json - json не валидный, то ошибка выбрасывается и ловится в try/catch

Так в том то и дело что мне ничего прикручивать не надо. Максимум закрепить некоторые поля при POST запросе

имело ввиду не тупо 500 словить а с пробросом уже готового респонса

Большинство ошибок кетчем у него не ловятся, для их отлова нужно писать функцию/класс обертку, и в итоге получается этот же аксиос, только кастрированный

Вы на любой случай жизни используете готовую библиотеку?)

я да

Нукс расскажите что не ловится catch)

тебе сервер вернул 400 ошибку, по дефолту фетч не свалится с ошибкой

Если бизнес не требует самописное решение - да

Мне нужно сделать однострочную проверку с выбросом ошибки и все

Бизнес также не требует лишних зависимостей

а еще пробросить кучу данных в эту ошибку, чтобы они были доступны в catch’е, а еще выяснить, почему у тебя запрос свалился с ошибкой - это сервер умер и это нативная ошибка фетча, либо это сервер вернул 400/500-ые коды и вот уже не 1 строчка, и даже не 3

Зачем кучу данных? Достаточно текста ошибки. У меня есть AlertError это ошибка которую нужно показать пользователю и встроенная ошибка которую не нужно показывать. С сервера приходит только то что нужно показать. Ошибка fetch не покажется.

ну и не стоит забывать, что фетч до сих пор не научился в отслеживание прогресса загрузки, поэтому если тебе понадобится такая фича, то тебе придется выкинуть фетч на помойку

интересно, а код уже в catch не нужен? а response? а если нужно что-то большее, чем показать текст? обработка ошибок далеко не всегда заключается в том, чтобы показать тост юзеру

+