You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, I'm using react-resolver with react-router for permissions. So, if a user doesn't pass a certain requirement, they're redirected somewhere. This means that I don't really want to put something to the props.
I just want to avoid errors such as these:
Warning: setState(...): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op. Please check the code for the Resolver component.
Warning: setState(...): Cannot update during an existing state transition (such as within `render`). Render methods should be a pure function of props and state.
I'm curious if this is solved in react-router 2.0.
This exists because resolution happens, you attempt to redirect (which should be synchronous and immediate), but the router seems to trigger the redirect in the next event loop/tick/whatever, meaning the component still renders, mounts, etc. and then the redirect happens.
I'm all for a fix, but curious if this has been solved with the rewrite first.
Activity
ratson commentedon Jan 2, 2016
Encountered the same problem, @ericclemmons is there any way we could avoid it?
Update:
Just have read https://facebook.github.io/react/blog/2015/12/16/ismounted-antipattern.html
Seems it is the solution that
react-resolvercould implement to solve the problem.ericclemmons commentedon Jan 2, 2016
I'm curious if this is solved in
react-router2.0.This exists because resolution happens, you attempt to redirect (which should be synchronous and immediate), but the router seems to trigger the redirect in the next event loop/tick/whatever, meaning the component still renders, mounts, etc. and then the redirect happens.
I'm all for a fix, but curious if this has been solved with the rewrite first.
ratson commentedon Jul 9, 2016
This line could be executed after unmount regardless redirects, as promise is resolved asynchronously.
AFAIK, that's why the blog post suggest to cancelling the promise before unmount. Or am I missing something?
ericclemmons commentedon Jul 9, 2016
I suppose the only/best way around this is to track if the component is still mounted or not before calling
setState...[-]Plain Resolver[/-][+]Avoid setState on unmounted components[/+]