В спеке прямо указано, что при получении ответа можно уточнить тип ошибки Как код статуса, так и просто response.ok

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

В любом случае, это вопрос подхода

Кому-то нравится, кому-то нет

Это вопрос восприятия fetch как инструмента. fetch - инструмент отправки запросов, а не их обработки

Кому-то нравится, кому-то нет

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

fetch на промисах, у него достаточный функционал. Он даже за тебя может распарсить json-ку! Что еще для счастья нужно?)

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

Мне не мешает, но будет мешать другим. Потому что оболочка над fetch звучит как извращение

fetch на промисах, у него достаточный функционал. Он даже за тебя может распарсить json-ку! Что еще для счастья нужно?)

По секрету, как и JS

Мне не мешает, но будет мешать другим. Потому что оболочка над fetch звучит как извращение

У тебя искаженное представление об извращениях)

По секрету, как и JS

js на промисах?

js на промисах?

Сорри, не уточнил, я про JSON)

Я все равно тотально не въезжаю в то, что ты пытаешься донести

Есть вероятность, что я плохо знаю русский, но она стремится к нулю

Я все равно тотально не въезжаю в то, что ты пытаешься донести

4xx - такая же ошибка, как, например, невалидный JSON, и она не должна делегироваться туда, где ты её не ожидаешь

Спор уровня tabs vs spaces

Нет желания продолжать

Нет желания продолжать

Потому что ты в корне не прав Ошибки абсолютно разные. И если что-то позволяет отлавливать ошибки разного рода, это не значит, что они однотипны

Если тебе ответил сервер и сообщил, что на его стороне нет ошибок- каждая сторона справилась со своей задачей. Ты открыл соединение, отправил запрос и получил ответ. Какой ответ- другое дело. Если ты накосячил в чем-то с запросом (4хх явно на это намекает), значит ты должен разбираться, что не так. Инструмент по отправке запросов свое дело сделал. У него есть функционал проверки за тебя, какой статус у запроса

Потому что ты в корне не прав Ошибки абсолютно разные. И если что-то позволяет отлавливать ошибки разного рода, это не значит, что они однотипны

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

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

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

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

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

:)

чего проще написать function myFetch(...args) { return fetch(...args) .then(response => { if (!response.ok) throw new Error(response.statusText); return response; }) }

Закрываю тему генильных программистов, пойду молча писать на superagent

fetch отстойный хотя бы тем, что не умеет отменять запросы

"В соответствии с последним опросом StackOverflow 2017, React любят 67% опрошенных разработчиков, а AngularJS — 52%. “Отсутствие интересу к продолжению разработки” регистрирует большие значения для AngularJS(48%) в сравнении с React(33%). Далее, есть опрос statejs.com, сравнивающий “front-end фреймворки”. Касательно “удовлетворенности”, React набрал 92% для варианта “использовал бы снова”, Vue — 89%, Angular 2 — только 65%. Как насчет другого опроса об удовлетворенности пользователей? Эрик Элиотт запустил один в октябре 2016-го, чтобы оценить Angular 2 и React. Лишь 38% опрошенных людей использовали бы Angular 2 снова, в то время как 84% использовали бы снова React." https://habrahabr.ru/post/338068/

ПРивет! Никто не сталкивался случайно с ошибкой?

> TypeError: calling Promise constructor without new is invalid

Вроде русским по белому написано что не так

ты вызываешь промис без new

да я понимаю - но код генерю не я - это TypeScript

с конфигом "target": "es5",

new NavistorePromise

как создать класс дочерний от Promise?

Вот так вызывается - new есть

2 часа мучаюсь, это еще мягко сказано)))

Ты явно что-то не так делаешь короч

Уходи на flow

но подход правильный?

Уходи на flow

это шо?)

я тебе не помощник Ближе к концу года только собираюсь изучать типизацию

это как тайпскрипт, но от фейсбука Если очень сильно обобщенно

ну вот я начал - решил очередной проектик на TS сделать

и че-то засел с этим

в php7 c типизацией разбирался месяц назад - там как-то подобных проблем не было...

Уходи на flow

лекарство от всех болезней?))

это шо?)

пиздатая штука, которая типы данных сверяет

если юзаешь CRA, она уже под капотом есть

как создать класс дочерний от Promise?

2 часа мучаешься и ни разу не загуглил? https://www.google.ru/search?q=extend+promise

а нахер вообще наследоваться от Promise?

https://www.google.ru/search?q=extend+promise+why

2 часа мучаешься и ни разу не загуглил? https://www.google.ru/search?q=extend+promise

Именно это ни к чему и не привело

а нахер вообще наследоваться от Promise?

Чтобы расширить своими свойствами / методами

Именно это ни к чему и не привело

А первый результат поиска смотрел?

Чтобы расширить своими свойствами / методами

расширить своими свойствами / методами, чтобы ... что?

расширить своими свойствами / методами, чтобы ... что?

Чтобы можно было определить что промис уже порезолвлен или ещё нет. Или есть возможность под капотом?

А первый результат поиска смотрел?

Мерси, это что то новое, немного не так гуглил - дописывал ещё typescript и не было такого... щас не у компа не могу проверить

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

Нет. Код ошибки — штатное, описанное проведение http. Реджект промиса должен происходить тогда, когда запрос по каким-то причинам не смог выполниться вообще. И что тебе мешает в следующем же then вернуть промис, завершившийся ошибкой? Одна строка кода.

Чтобы можно было определить что промис уже порезолвлен или ещё нет. Или есть возможность под капотом?

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

ERROR: S client not available

Чтобы можно было определить что промис уже порезолвлен или ещё нет. Или есть возможность под капотом?

jquery deferred-ы способы на это

так же, как и Bluebird-промисы, но зачем - непонятно

надеюсь не для того, чтобы делать ад типа while(!promise.isFulfilled()) {} return promise.value()

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

Никакого, также как вообще ООП не имеет смысла)))

Но да - это тоже решение, но если промисов станет 10 - то очень костыльное

Никакого, также как вообще ООП не имеет смысла)))

да нет, я просто про то, что Promise - это по большей части механизм передачи данных, а не хранения, зачем передавать ниже сам промис вместо значения, которое он разрезолвил?

Но да - это тоже решение, но если промисов станет 10 - то очень костыльное

И часто есть необходимость разрезолвить c десяток разных промисов в одном месте? =)

У меня есть класс, в нем пачка аяксов. Класс могут дёргать разными его функциями внешние разработчики, это js-api для них. Последовательность вызова функций может быть любая. Но в функциях мне надо проверять стейт зависимых друг от друга аяксов

Чтобы можно было определить что промис уже порезолвлен или ещё нет. Или есть возможность под капотом?

Есть же Promise.all, Promise.race

И часто есть необходимость разрезолвить c десяток разных промисов в одном месте? =)

когда потребуется - будешь использовать deferred-ы ещё наверняка или мучаться спромисами. У меня недавно была задача которая решалась удобно только с деферредами, промисы создавали безумие

И если промис уже отрезолвлен, я просто выполняю сразу какие то действия, а если нет - то использую then

Вот как то так сжато попытался объяснить

await попробуй

И если промис уже отрезолвлен, я просто выполняю сразу какие то действия, а если нет - то использую then

т.е. ты всё равно пишешь ветку then, какой тогда смысл в синхронном действии?

когда тебе требуется отрезолвить его в разных меcтах кода при разных условиях - то единвенный путь это deferred

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

т.е. ты всё равно пишешь ветку then, какой тогда смысл в синхронном действии?

А если промис уже отрезвлен и выполнится потом его then - который написан допустим через пару аяксов, мы в then попадём? Тогда наверно этого и достаточно... просто так никогда не делал и с промисами работал тока в ангуляре... кстати с defer можно решить походу да и с all()

Короче идей вагон теперь, всем спасибо, думаю вопрос решён)

да, если подписываешься на отрезолвленный промис, колбек будет выполнен (но всё равно асинхронно!)

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

Ну я имел в виду then в разных местах

я имел ввиду создаешь объект сразу, а резолвишь где нужно

Я понял, короче спасибо, реально я чето перемудрил)))

Ребят, есть ли что-то еще на такую тему ? https://wtfjs.com/

Типо сборник странностей/интересностей на js

как в three js закрасить внутреннью область обьекта?

отвечай, ты спамер?

Нет)

Нет)

Я не буду у тебя ничего покупать

а то в 3 группы одновремено зашёл

Работа от 80к в неделю для безработных тут не прокатит