Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interceptors array potentially growing indefinitely #1380

Closed
pendenaor opened this issue Feb 22, 2018 · 12 comments
Closed

Interceptors array potentially growing indefinitely #1380

pendenaor opened this issue Feb 22, 2018 · 12 comments
Assignees

Comments

@pendenaor
Copy link

pendenaor commented Feb 22, 2018

Hi,

While testing my application, i notice that the handlers array of axios interceptors only increase, even if i use the eject method.

In fact, eject only nullify interceptor entry

this.handlers[id] = null;

and use always push new handler and return length - 1

return this.handlers.length - 1;

Is it not dangerous (or expensive) to have this type of behaviors?

Regards

@Axnyff
Copy link

Axnyff commented Mar 11, 2018

Hello,
I had a quick look and I don't really know what could be a good alternative (without breaking changes) because the ids are necessary to eject so new interceptors always need to be a new array key, we cannot just filter the array as this will change the ids.

Deleting keys instead of just putting null could help a little but it would just create sparse arrays, I'm not sure this is much better.

Maybe using a plain object to store the interceptors and another array to know in which order call the interceptor could work ( I don't think relying on keys order in object is a good idea, it's only sure to work in ES6 compliant implementation)

@pendenaor
Copy link
Author

pendenaor commented Mar 12, 2018

And reusing nulled index instead of returning directly the last one in use?

@Axnyff
Copy link

Axnyff commented Mar 12, 2018

Wouldn't that change the order of execution of interceptors?
I also think that there's a chance that somebody depends on the fact the the indexes always grow to keep track of the last added interceptor so I don't know if that would be ok

The more I think about it, the more I'd say that using just an object to store the interceptors could actually be a good idea.

@pendenaor
Copy link
Author

pendenaor commented Mar 12, 2018

Ok, order is important... maybe, a Map with an auto-incremented numeric key will be sufficient?

@Axnyff
Copy link

Axnyff commented Mar 12, 2018

Yes, that seems like the best idea. That's kind of what I was suggesting but with a plain JS object to make sure it will be ES5 compatible

@viktoriiakrause
Copy link

Hi!
Are there any updates on this issue?

@rohitkhatana
Copy link

@Axnyff Using plain JS object(Map implementation) looks good approach. is there any update/plan to implement it ?

@pendenaor
Copy link
Author

You have no guarantee that order of insertion is respected with plain js objet.

@rohitkhatana
Copy link

rohitkhatana commented Oct 15, 2019

We could have used Map :)
is there any other alternative/solution to the above problem @pendenaor

@pendenaor
Copy link
Author

pendenaor commented Oct 15, 2019

ES5 compatible? See #1380 (comment) where @Axnyff suggests object + array

@Axnyff
Copy link

Axnyff commented Oct 15, 2019

My PR should work with only an id and a count: #1410
I had some requested changes but I don't know how to profile for memory though

@jasonsaayman
Copy link
Member

Hi,

Please read more on this issue over at #1914

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants