V
и зачем для такого "побыстрее"? :)
ну можно получить какой то фидбек сразу, типа да да.. хотели в 21 году или бац узнаю что в конце этого года завезут
Size: a a a
2020 August 10
V
при таком общении ты можешь получить более качественный фидбек
V
имхо
IK
Вряд ли :)
V
с другими работало (ну когда про баги писал)
IK
про баги - да. А вот роадмап - это удел продактов всегда )
EN
Подскажите, пожалуйста, как справляться с подобным "notifications hell".
Есть axios в проекте, где он в своем хуке на response error проверяет "типичные" ошибки:
- 500 (Internal Server Error)
- isAxiosError с кодом ECONNABORTED (Время ожидания ответа истекло)
- ошибки с Network Error (Проблемы с соединением с интернетом) и другие (которые я забыл обработать на уровне axios). Когда данные ошибки происходят, отображается нотификация с соответствующим сообщением.
Однако есть рауты, на которых параллельно запускается большое кол-во запросов и в случае, когда у юзера одна из выше перечисленных проблем, у него будет огромное полотно этих нотификаций, равное количеству сделанных запросов..
Что обычно применяют во избежании такого ? Какая-то умная проверка на запрет отображения повторяющихся нотификаций ?
Есть axios в проекте, где он в своем хуке на response error проверяет "типичные" ошибки:
- 500 (Internal Server Error)
- isAxiosError с кодом ECONNABORTED (Время ожидания ответа истекло)
- ошибки с Network Error (Проблемы с соединением с интернетом) и другие (которые я забыл обработать на уровне axios). Когда данные ошибки происходят, отображается нотификация с соответствующим сообщением.
Однако есть рауты, на которых параллельно запускается большое кол-во запросов и в случае, когда у юзера одна из выше перечисленных проблем, у него будет огромное полотно этих нотификаций, равное количеству сделанных запросов..
Что обычно применяют во избежании такого ? Какая-то умная проверка на запрет отображения повторяющихся нотификаций ?
2020 August 11
V
про баги - да. А вот роадмап - это удел продактов всегда )
еще лучше если их контакты
NR
El Nasurov
Подскажите, пожалуйста, как справляться с подобным "notifications hell".
Есть axios в проекте, где он в своем хуке на response error проверяет "типичные" ошибки:
- 500 (Internal Server Error)
- isAxiosError с кодом ECONNABORTED (Время ожидания ответа истекло)
- ошибки с Network Error (Проблемы с соединением с интернетом) и другие (которые я забыл обработать на уровне axios). Когда данные ошибки происходят, отображается нотификация с соответствующим сообщением.
Однако есть рауты, на которых параллельно запускается большое кол-во запросов и в случае, когда у юзера одна из выше перечисленных проблем, у него будет огромное полотно этих нотификаций, равное количеству сделанных запросов..
Что обычно применяют во избежании такого ? Какая-то умная проверка на запрет отображения повторяющихся нотификаций ?
Есть axios в проекте, где он в своем хуке на response error проверяет "типичные" ошибки:
- 500 (Internal Server Error)
- isAxiosError с кодом ECONNABORTED (Время ожидания ответа истекло)
- ошибки с Network Error (Проблемы с соединением с интернетом) и другие (которые я забыл обработать на уровне axios). Когда данные ошибки происходят, отображается нотификация с соответствующим сообщением.
Однако есть рауты, на которых параллельно запускается большое кол-во запросов и в случае, когда у юзера одна из выше перечисленных проблем, у него будет огромное полотно этих нотификаций, равное количеству сделанных запросов..
Что обычно применяют во избежании такого ? Какая-то умная проверка на запрет отображения повторяющихся нотификаций ?
У нас в одном из приложений тосты с сообщениеми через 5 сек сами закрываются
EN
У нас в одном из приложений тосты с сообщениеми через 5 сек сами закрываются
Это да, в данном кейсе они также закрываются по истечении определённых секунд.
Тут как бы проблема в том, что при ошибке сразу нескольких параллельных запросов, юзер увидит нотификацию по каждому из них, хотя ему хватило бы лишь одной, чтобы понять, что у него проблема..
Пример.
У юзера появились проблемы с соединением, когда он находился на рауте /profile. Он совершает переход на раут /main, где происходит большое количество параллельных запросов. Каждый из этих запросов фейлится ошибкой Network Error и так как ошибка "общая/типовая", она обрабатывается на уровне хука axios, который генерит нотификацию с месседжем "Проблемы с соединением с интернетом". Соответственно, на каждый запрос будет сгенерирована такая нотификация, отсюда и получаем, что юзер перейдя на /main раут увидит целую кучу этих нотификаций, когда ему хватило бы одной, чтобы понять в чем дело.
Тут как бы проблема в том, что при ошибке сразу нескольких параллельных запросов, юзер увидит нотификацию по каждому из них, хотя ему хватило бы лишь одной, чтобы понять, что у него проблема..
Пример.
У юзера появились проблемы с соединением, когда он находился на рауте /profile. Он совершает переход на раут /main, где происходит большое количество параллельных запросов. Каждый из этих запросов фейлится ошибкой Network Error и так как ошибка "общая/типовая", она обрабатывается на уровне хука axios, который генерит нотификацию с месседжем "Проблемы с соединением с интернетом". Соответственно, на каждый запрос будет сгенерирована такая нотификация, отсюда и получаем, что юзер перейдя на /main раут увидит целую кучу этих нотификаций, когда ему хватило бы одной, чтобы понять в чем дело.
NR
El Nasurov
Это да, в данном кейсе они также закрываются по истечении определённых секунд.
Тут как бы проблема в том, что при ошибке сразу нескольких параллельных запросов, юзер увидит нотификацию по каждому из них, хотя ему хватило бы лишь одной, чтобы понять, что у него проблема..
Пример.
У юзера появились проблемы с соединением, когда он находился на рауте /profile. Он совершает переход на раут /main, где происходит большое количество параллельных запросов. Каждый из этих запросов фейлится ошибкой Network Error и так как ошибка "общая/типовая", она обрабатывается на уровне хука axios, который генерит нотификацию с месседжем "Проблемы с соединением с интернетом". Соответственно, на каждый запрос будет сгенерирована такая нотификация, отсюда и получаем, что юзер перейдя на /main раут увидит целую кучу этих нотификаций, когда ему хватило бы одной, чтобы понять в чем дело.
Тут как бы проблема в том, что при ошибке сразу нескольких параллельных запросов, юзер увидит нотификацию по каждому из них, хотя ему хватило бы лишь одной, чтобы понять, что у него проблема..
Пример.
У юзера появились проблемы с соединением, когда он находился на рауте /profile. Он совершает переход на раут /main, где происходит большое количество параллельных запросов. Каждый из этих запросов фейлится ошибкой Network Error и так как ошибка "общая/типовая", она обрабатывается на уровне хука axios, который генерит нотификацию с месседжем "Проблемы с соединением с интернетом". Соответственно, на каждый запрос будет сгенерирована такая нотификация, отсюда и получаем, что юзер перейдя на /main раут увидит целую кучу этих нотификаций, когда ему хватило бы одной, чтобы понять в чем дело.
Ну можно тротлить по 100мс и собирать вместе такие сообщения. Но опять же это не техническая проблема. Вопросы такие надо задавать ux-дизайнеру или тому, кто отвечает за продукт. Опять же если ошибок валится много, то у юзера наверное больше голова будет болеть не из за их отображения, а потому что приложение из за них не может нормально работать??
AS
El Nasurov
Это да, в данном кейсе они также закрываются по истечении определённых секунд.
Тут как бы проблема в том, что при ошибке сразу нескольких параллельных запросов, юзер увидит нотификацию по каждому из них, хотя ему хватило бы лишь одной, чтобы понять, что у него проблема..
Пример.
У юзера появились проблемы с соединением, когда он находился на рауте /profile. Он совершает переход на раут /main, где происходит большое количество параллельных запросов. Каждый из этих запросов фейлится ошибкой Network Error и так как ошибка "общая/типовая", она обрабатывается на уровне хука axios, который генерит нотификацию с месседжем "Проблемы с соединением с интернетом". Соответственно, на каждый запрос будет сгенерирована такая нотификация, отсюда и получаем, что юзер перейдя на /main раут увидит целую кучу этих нотификаций, когда ему хватило бы одной, чтобы понять в чем дело.
Тут как бы проблема в том, что при ошибке сразу нескольких параллельных запросов, юзер увидит нотификацию по каждому из них, хотя ему хватило бы лишь одной, чтобы понять, что у него проблема..
Пример.
У юзера появились проблемы с соединением, когда он находился на рауте /profile. Он совершает переход на раут /main, где происходит большое количество параллельных запросов. Каждый из этих запросов фейлится ошибкой Network Error и так как ошибка "общая/типовая", она обрабатывается на уровне хука axios, который генерит нотификацию с месседжем "Проблемы с соединением с интернетом". Соответственно, на каждый запрос будет сгенерирована такая нотификация, отсюда и получаем, что юзер перейдя на /main раут увидит целую кучу этих нотификаций, когда ему хватило бы одной, чтобы понять в чем дело.
Добавляй CancelToken и отменяй не актуальные запросы после первого критического фейла.
AS
Заодно и трафик юзеру сэкономишь
DN
подскажите плз, дебажу socket.io
Причина в том что на одной из прошивок начал падать socket.io с disconnect с причиной transport error
Начал дебажить, на норм прошивке и на поломанной вроде шлю одинаковые данные, но в дебаге сокета вижу разное существенное время их обработки. От чего это может зависеть?
Вот долго и тут со временем падает дисконнект
Причина в том что на одной из прошивок начал падать socket.io с disconnect с причиной transport error
Начал дебажить, на норм прошивке и на поломанной вроде шлю одинаковые данные, но в дебаге сокета вижу разное существенное время их обработки. От чего это может зависеть?
Вот долго и тут со временем падает дисконнект
DN
а вот нормальная работа
AN
Привет всем! Кто как создал и использует свою component library? Как отдельный репо, как монорепо, или еще какие варианты?
AP
Мы используем. Плюс видел у некторых.
AP
Раскажу как я видел, это монорепа со всеми глупыми компонентами. И подключается она как npm модуль.
AP
У меня возник такой вопрос, он вообще холиварный, но никто не может дать внятного ответа. Как оценить свой градуэйт? Мидл, мидл+, сеньер. Интересен именно технический навык.
AP
Вот как определить свой градуэйт?