Size: a a a

JavaScript.Ninja

2020 July 03

II

Ivan Ivanov in JavaScript.Ninja
Vladimir Klimov
Контекст - способ доставить данные компонентам, а редакс - библиотека для управления этими данными🤷‍♂
Зачем писать "свой редакс"? Чем это лучше? Не нравится редакс - возьмите другой менеджер состояния, их хватает
Мой вопрос был почему контекст это проблема для классов а не почему контекст хуже редакса
источник

VK

Vladimir Klimov in JavaScript.Ninja
Ivan Ivanov
Зачем тянуть в бандл менеджер состояния если есть react state?
Если вам нужна функциональность менеджера состояния - вам придется писать его самому🤷‍♂
источник

II

Ivan Ivanov in JavaScript.Ninja
Ivan Ivanov
Зачем тянуть в бандл менеджер состояния если есть react state?
Не в том плане что всегда есть смысл использовать нативный стейт, а чтоб его не использовать нужно понять зачем это тебе
источник

II

Ivan Ivanov in JavaScript.Ninja
Vladimir Klimov
Если вам нужна функциональность менеджера состояния - вам придется писать его самому🤷‍♂
Да, но не факт что она нужна
источник

VK

Vladimir Klimov in JavaScript.Ninja
Ivan Ivanov
Мой вопрос был почему контекст это проблема для классов а не почему контекст хуже редакса
Та не проблема, скорее всего речь была об апи чуть более неудобном
источник

II

Ivan Ivanov in JavaScript.Ninja
Vladimir Klimov
Та не проблема, скорее всего речь была об апи чуть более неудобном
Вот в этом и был вопрос в чем он чуть более не удобный
источник

A

A A in JavaScript.Ninja
Допустим для redux есть connect,  можно конечно store затащить и из него dispatch вытащить
источник

II

Ivan Ivanov in JavaScript.Ninja
так коннект это HOC который пишется в пару строчек. Для редакса есть биндинг пакет react-redux.
источник

VK

Vladimir Klimov in JavaScript.Ninja
Ivan Ivanov
Вот в этом и был вопрос в чем он чуть более не удобный
Просто больше писать)
Ну, типа, писать какой-то хок с consumer-ом
источник

A

A A in JavaScript.Ninja
Ivan Ivanov
так коннект это HOC который пишется в пару строчек. Для редакса есть биндинг пакет react-redux.
Это то понятно
источник

A

A A in JavaScript.Ninja
Но тут ты должен писать свой, и оборачивать свой каждый классовый компонент
источник

II

Ivan Ivanov in JavaScript.Ninja
A A
Но тут ты должен писать свой, и оборачивать свой каждый классовый компонент
Так ты и в connect их оборачиваешь
источник

II

Ivan Ivanov in JavaScript.Ninja
Мой поинт был в том что это проблема ровно такая же и редакс ничего особенного не делает
источник

II

Ivan Ivanov in JavaScript.Ninja
Кроме конечно того что есть готовый пакет с HOC
источник

A

A A in JavaScript.Ninja
Ещё меня напрягало, что нет нормального devtools для контекста, как скажем в редакс
источник

VK

Vladimir Klimov in JavaScript.Ninja
Ivan Ivanov
Мой поинт был в том что это проблема ровно такая же и редакс ничего особенного не делает
Ну, да, это вообще не  аргумент в пользу редакса, конечно)
источник

EN

El Nasurov in JavaScript.Ninja
Ребят, подскажите, пожалуйста, как в интерцепторе аксиоса правильно сохранить пришедший запрос, чтобы отравить его позже ?

Реализую механизм обновления рефреш-токена и необходимо все запросы, которые сервис генерирует, пока рефреш-токен обновляется, собирать в массив, пока запрос на рефреш-токен не будет полностью обработан. Далее предполагаю, когда рефреш токен будет полностью обработан, новый токен поставлен, отправлять все собранные запросы из массива.

В данный момент делаю вот так. Однако, как я предполагаю, из-за 'return refreshTrack.push(response)'. аксиос предполагает, что вернули из интерцептора не запрос, а нечто другое, и поэтому сразу фейлит этот запрос (он попадает в interceptors.response без тела ответа).

Axios.interceptors.request.use(
 (response) => {
   if (isRefreshUpdating && response.url !== 'refresh-token') {
     return refreshTrack.push(response);
   }

   return response;
 }, (err) => err);

*isRefreshUpdating булевая переменная, которая замыкается, когда начинается процесс обновления токена.
источник

IK

Illya Klymov in JavaScript.Ninja
Потому что пуш возвращает не элемент
источник

EN

El Nasurov in JavaScript.Ninja
Я понимаю.

Но ведь, если я верну элемент (в данном кейсе этот объект response - то есть запрос), то аксиос его отправит.

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

А когда новый рефреш-токен прилетит и будет "поставлен", я запушу все собранные таким образом запросы, которые уже отправятся на бэк с новым токеном.


Возможно, изложенная мною идея в корне неверная и не подходит для механизма обновления рефреш-токена)
источник

v

vasilich in JavaScript.Ninja
Чем гугленые солюшены не подошли?
Для аксиоса из должно быть мульйон
источник