Does not work well with axios timeout functionality
ktayah opened this issue · 7 comments
When using this with axios's timeout functionality on a request, there seems to be a bug that breaks the cookie storage of the state after the HTTP request made by axios with the timeout request. I'll add some code to show what I mean.
const aFunction = () => async dispatch => {
dispatch({
type: 'Action 1'
});
axios.get('url', { timeout: 10000 });
dispatch({
type: 'Action 2'
});
The state change caused by Action 2 will not be present when the application is reloaded or revisited, it will use Action 1's state changes as the last state changes made and store those to the cookies.
Hi Kevin, in order to help, may I ask where you dispatch the thunk action above? On the server or client, in getInitialProps or somewhere else? Does it work without the axios timeout setting?
Also, you're not awaiting axios.get. Do you do so in your real code?
In my code, I do use an await on the axios call. And I run the function above in the client. As it turns out I was quick to blame the timeout functionality after it briefly functioning once I removed the timeout option for the axios call.
The function itself behaves as expected. It is only when the the page is reloaded or revisited is the state of the app not able to capture any action after the axios call. Action 1 is the last state change stored to the cookies, but before reloading Action 2 is called and the change occur. I'll attach a screenshot in my particular case of the code. I'll also show where it is being called.
My code is also publicly view able here.
May #2 apply to you as well and your second action makes the state exceed a cookie size limit?
That seems likely, since even before reloading the application cookies are only updated up until action 1. Action 2 is not stored. However not sure how to go about reducing the size of the cookies as I only have one reducer whitelisted to be saved to the cookies.
According to RFC6265, browsers should at least support 4096-byte-large cookies. If you get near that size, the easiest fix may be to restructure your Redux store (for instance using one whitelisted reducer that stores important-to-persist data only, and dynamically fetching dependent data from your API using Redux Thunk or Redux Saga or so). Alternatively, redux-cookie-middleware also looks pretty promising (I had not discovered that yet when I decided to use redux-persist and redux-persist-cookie-storage).
I appreciate the info and guidance, I'll probably go with the other library you recommended or use something that uses local storage.
I'm gonna close this then. Best of success!