А что использует большинство?!

axios

Why ?! В чем профит?!

В том, что он работает

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

Предлагаю ознакомиться с документацией axios. Вопросы должны отпасть после этого)

Тогда надо получается потратить время и на фетч и на аксиос, чтоб разобраться с каждым и понять в чем разница и преимущество одного над другим. Для этого я вопрос и задал , чтоб не тратить время зря

Бери axios Время сэкономит

Ок только я так и не понял в чем преимущество.

Можешь просто оглавление посмотреть тогда.

открой первую страницу документации, там все по пунктам расписано

в фетче нет интерцепторов. Но никто не мешает написать обёртку.

Если он даже не знает что это, какие ещё обёртки) Пусть берёт axios и не страдает хернёй)

Изучать что-то хоть axios, хоть fetch - это не тратить время зря.

Из 3 ваших сообщений не одного полезного, просто спам! Зачем тратить свое время , чтоб сделать вид, что ты умный?!

Открой почитай Доку или хотя бы оглавление. Очень полезное сообщение, мне кажется)

Ну хз помоему спам

Мм.. Дока это спам. Ок

Дока не спам, спам твое 7 сообщение не по делу

Ты троллишь что ли?

Ну хоть считать умеешь. Не всё потеряно)

Чувак, мне тебя жаль, раз ты можешь позволить тратить столько времени на спам в телеге не по делу. Пошел бы лучше покодил - денег заработал, на худуой конец женой/девушкой занялся…

Себя пожалей

Спасибо за совет. Мне тебя тоже жаль, что ты считаешь пустой тратой времени изучение технологий и их документации. Удачи

Слушай ну я знаю архитектуру арм и риск5, могу в фпга и микроконтроллеры на си и плюсах, могу десктоп на qt и gtk ,знаю бэк php и go. Знаю немного js. И мне просто надо дергать свою apiшку с простым фронтом на вью. Я не хочу тратить много времени чтоб погрузиться в доку и разобрать все ньюансы для того, чтобы написать несколько запросов на бэк, поэтому я здесь! Спросил , что лучше, чтоб не тратить время зря. Ты просто сидишь тут и тролишь типо ты умный. А на самом деле ты скорее всего даже не знаешь как https работает…

Ты закончил?

(не спам)

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

Fetch умеет АБСОЛЮТНО всё, что нужно для реализации коннекта с бэком на Vue SPA Кроме resend xhr в Хроме

выкидывать ошибки при 500-ых кодах он тоже умеет?

Все ошибки и не ошибки должен обрабатывать программер по статусу ответа Fetch - транспортный уровень, он должен отвечать только за ошибки в соединении

в реальном приложении никто не проверяет в каждом ответе все статус коды, вместо этого удобнее выкидывать [разные] ошибки при 4xx/5xx кодах, поэтому ты в любом случае будешь писать этот функционал вокруг фетча и придешь к какой-нибудь своей обертке

Обертка всегда должна быть Сперва у меня на проекте был axios, с интерсепторами (до меня делали) Я сделал обертку и свои интерсепторы, не привязанные к аксиос Потом сделал всё через JSON-RPC, но это факультативно Потом захотелось использовать fetch - поменял на него Увидел, что с Хромом проблемы, нашел простую промисную реализацию XHR и добавил его Итого у меня сейчас модуль http.ts с экспортируемой функцией request() (которую пользует уже jsonRpc(), а последнюю все api.users, api.products и так далее) И в модуле http.ts есть еще три функции - requestXhr(), requestFetch() и requestAxios() Любую из них могу вставить внутрь request() и всё будет работать Включая авторизацию, загрузку файлов и другие варианты использования HTTP Разницы между ними ни-ка-кой, кроме того, что axios требует зависимость. По-моему, очень красиво. Транспортный уровень делает только то, что должен. Бизнес логика - на программе. Если на бэке эксепшн - я получаю обычный 200 с описанием ошибки и стектрейсом в форме json-a. По любому программер должен это обработать как-то. Оформил всё это как модуль и подключаю через git modules в разные свои проекты. Сильно экономит время. Разные проекты только разные интерсепторы используют, потому что в них бизнес-логика, остальное - одинаково

оно-то может и красиво, но не особо понятно, зачем нужны 3 разные реализации, обычно одной хватает вообще для всего и заменяют ее крайне редко и по каким-нибудь очень специфичным причинам >Если на бэке эксепшн - я получаю обычный 200 а если бэк умер и отдается 500, как это обрабатывается и на каком этапе ты это выясняешь?

А мне не нравится подход, когда ожидаемые ошибки с HTTP выкидываются глобальными исключениями. В JS, где нет ни throws даже в TS, где нельзя ловить конкретное исключение, неприятно смешивать ошибки и исключения, выкидывая всё, чтобы потом где-то на каком-то уровне ловить. Для ожидаемых бизнесовых ошибок предпочёл бы возвращать как результат операции. А для общих - добавлять возможность устанавливать обработчик из самого приложения, типа httpClient.onUnauthenticated(() => react)

Три реализации в данном случает просто эволюционно получились. Пользуюсь фетчем. Остальные много не занимают байт. > а если бэк умер и отдается 500, как это обрабатывается и на каком этапе ты это выясняешь? В моем случае JSON-RPC разделяет ошибки транспортного уровня от ошибок приложения Водная: 300, 400 и 500 ошибки в работающем SPA приложении возникать не должны (не только использующем JSON-RPC). Если они случаются - это критичная ошибка приложения, которую можно обработать в общем - показать тоаст "Ошибка" без описания деталей. Если бэк умер (404) - будет ошибка транспортного уровня (на обертке fetch). Это общая ошибка выше. Ну либо можно проверить наличие сети и написать про отвал соединения. Если умерла база данных (500 в RESTe) - приходит 200 JSON-RPC error message со стек трейсом (не в проде ессно). Тоже обрабатывается как общая ошибка. Если ошибка бизнес-логики (пользователь не создается потому что такой username уже есть) - это обрабатывается в программе. Приходит ответ 200 с описанием и обрабатывается он соответствующим модулем (api.users.createUser())

есть такое, но с этим ничего особо уже не поделаешь - даже если перейти на условный Result<Value, Error>, то все равно где-то придется по-прежнему ловить ошибки и обмазываться try/catch в разных сценариях ну и в большинстве проектов это стандартная история, когда axios выбрасывает какую-нибудь ошибку и нужно ее где-нибудь перехватить, тут хотя бы можно удобно комбинировать это с <ErrorBoundary />, чтобы можно было написать 1 раз и не думать больше об этом

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

Если у тебя простой проект с несколькими вызовами к бэку из компонент или стора, тогда да, согласен, - axios way более developer friendly. И то, это в большой степени скорей многолетняя привычка. Для более-менее нормальных проектов всё равно пишется инфраструктура для общения с бэком, и вся реализация лежит в одном изолированном месте и никого не раздражает

обычно хейтеры аксиоса (коим я являюсь) ссылаются на то что ты грузишь 30кб только ради 1% фичей которые то дефакто и заменяются в пару касаний