вопрос, в чем подход с возвратом [error, responseData] лучше того, чтобы из API слоя просто пробрасывать дальше ошибку, а в компоненте ловить в catch-блоке ?
Есть сакральный смысл какой-то или просто это увиделось более удобным ?
Вообще, я задумался, что есть смысл возвращать и сырой response в случае чего.
А по поводу ошибки, то там есть несколько сценариев, если брать во внимание сам axios.
А еще мне сейчас нравится больше возвращать данные или ошибку и ловить это через if (response instanceof Error) { ... }
Так а в чем разница то будет, на саму ошибку это ведь никак не влияет.. Т.е. в первом случае мы возвращаем ошибку из catch блока API слоя return [error], а в компоненте получаем как первый элемент массива. А в другом случае, ошибку пробрасываем из .catch блока API-слоя throw error и ловим ее в .catch блоке компонента и обрабатываем Получается саму ошибку это ведь никак не касается. Меняется просто способ получения этой ошибки
Если Вы не хотите обрабатывать ошибку в слое транспорта, а хотите работать с ней в слое отображения, то можно опустить момент с try catch в слое транспорта.
Не, я просто хотел понять, почему мы именно к такому подходу подошли.. Думал может есть какие-то важные плюсы у первого над вторым, поэтому я собственно и спросил
Важным плюсом первого есть то, что можно обработать ошибку на уровне транспорта. Под обработать, я имею введу привести её к общему виду или к Ошибке свойственной приложению.
теперь я понял смысл этой строчки, где мы в if-е определяем тип ошибки и делаем необходимую нам логику в зависимости от той или иной ошибки)
Да, главное держать обработчики внутри API уровня, они могут быть разными для отдельных endpoints. Ну и еще структуру ошибок можете себе придумать с конструкторами, тогда будет проще с ними работать, переводить их на разные языки и т. д.
Обсуждают сегодня