Prototype for v19 support #82
Conversation
| @@ -172,13 +172,13 @@ function fixConfig(axios, config) { | |||
| */ | |||
| export default function axiosRetry(axios, defaultOptions) { | |||
| axios.interceptors.request.use(config => { | |||
| const currentState = getCurrentState(config); | |||
| const currentState = getCurrentState(axios); | |||
There was a problem hiding this comment.
Does this not use a single state per whole axios instance? Will that not make requesting separate resources with the same axios instance impossible, because their retry states will be the same instead of independent?
There was a problem hiding this comment.
Indeed. But it does not cause too much trouble I guess... I personally tend to create as many custom Axios instances as microservices (apis) my app talks to, e.g.:
const todosApiClient = axios.create({ baseURL: 'https://todos-api.com' });
const todosApiClientWithRetry = axiosRetry(todosApiClient, { ... });
const usersApiClient = axios.create({ baseURL: 'https://users-api.com' });
const usersApiWithLogger = axiosLogger(usersApiClient, { ... });
// etc.There was a problem hiding this comment.
While that is true, and it is nice that it works for you, it is certainly not standard and very much unexpected behavior for anyone who reuses axios instance for different MS. Or for example has axios instance for a single domain but the domain is API gateway and so different resources can have vastly different availability.
Right now this change would make safe axios instance reuse impossible.
Keeping retry state in config.adapter as seen in https://github.com/softonic/axios-retry/pull/76/files would not work?
There was a problem hiding this comment.
The API gateway is an interesting use case, we should indeed find a way to support it.
On one side, I'm not super keen to follow the config.adapter approach as we shouldn't modify what we don't own. On the other side, I don't see how we could pass the axios-retry state from one retry to the next in a reliable way...
There was a problem hiding this comment.
...unless we decorate Axios request method in order to store the axios-retry state in a local "cache", the cache could be a WeakMap and the key, the config passed to the request method.
There was a problem hiding this comment.
The WeakMap idea sounds pretty good to me, compatibility with ie < 11 aside. Either with the request object itself as key, as you say, or on some id that is generated in an interceptor.
There was a problem hiding this comment.
One solution could come from Axios itself axios/axios#2207
|
Has there been any progress on this? |
|
Hey guys, what is preventing this MR to be merged and a new version to be released? |
|
can this be merged in? |
|
Hey there 👋, if you're waiting for axios/axios#2207 to be released instead, please give a quick update. There is no need to copy their communication habits. :) |
|
I think, if this fix works with axios@latest - push it. |
|
Looks like with axios 0.19.1 this PR is not needed anymore. |
Resolves #59