Пару недель тому узнал что отменить запрос, посланный через fetch не так просто и кроссбраузерно как мне казалось. А еще очень многословно. А еще promise, возвращаемый fetch-ем будет rejected, поэтому в обработке ошибок нужно отличать ошибки аборта запроса от других ошибок.
Решил переехать на axios, но у того синтаксис того как делать аборты незавершенных запросов более вырвиглазный (личное мнение) чем у fetch.
Ухты интересно, не знал про существование AbortController & AbortSignal, был пропозал к Promise чтоб отменять запрос, но его самого кенсельнули :D
Встречал различные POC, где писали обертки вокруг fetch + Promise, а вообще, какой у тебя юзкейс?
Передергивать апи до того как предыдущий запрос завершится (случай когда интернет медленный а пользователь быстрый).
Вызов api https://github.com/podgorniy/media-manager/blob/master/src/client/api.ts#L51
Самое неприятное это что axios пролез в то место где я обрабатываю ошибку запроса. А еще что ошибка теперь не просто “ошибка”, а “может быть ошибка, может быть отмененный запрос”. https://github.com/podgorniy/media-manager/blob/master/src/client/app-state.ts#L161
Более широко проблема стоит в том чтобы состояние клиента соответствовало последнему состоянию которое накликал пользователь.
Понял проблематику,
Да согласен, теперь axios прямая зависимость в app-state, можно конечно axios.isCancel абстрагировать в api.ts, тогда прямая зависимость скроется, но все равно пользователь api должен обладать тем знанием что “ошибка может быть не совсем ошибка”, возможно общий эррор хендлер создать…
Ээээ… RxJS Observable уже сто лет в обед имеет кучу методов для этого. Среди которых
unsubscribe
throttling
debounce
http://reactivex.io/rxjs/class/es6/Observable.js~Observable.html
В интернете полно статей
RXJS - это свой мир. Если использовать эту библиотеку, то все приложение нужно моделировать вокруг нее. Статья что ты кинул - про то как свести запрос-ответ к RXJS стримам. В моем случае я все свожу к Mobx observables и еще один слой абстракции в виде RXJS был бы лишним.