Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

The warning:

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 _class component.
Any idea where it can come from. Gotchas or things like that ?
I already looked at all the setState in my code and replaced them to make sure. Can't find where it comes from...
My observations so far:
Only happens in my tests
No problem in the browser
I thought I had more... but with more testing I got all confuse because it didn't fit the patterns I thought I understood...
So ! I understand what the error is but this time the warning is about a _class component so I'm lost... I just upgraded to react-router v4  and it needed a lot of changes so it's hard to localize the source of the warning.
Anyone had had a similar problem before ?
EDIT:
I found the setState that were causing problem. It was in react-router-server. I'll look into it to see if I can fix it !
Thanks @zerkms for the idea to look with a debugger to get the line number since there was no trace in the terminal.
I used the v8 experimental inspector(https://stackoverflow.com/a/39901169/3687661). Works pretty good :)
This is common due to async activities like API calls. For example, this happen when you try to set a state after you receive the data from the server and the corresponding page to receive that state is not mounted.
To avoid this, check if the component is mounted before setting state in that component. Use a flag to check, say this.mounted = true in componentDidMount and change the flag to false in componentWillUnmount. Use this.mounted across the component to check if the component is mounted. This will fix the warning.
Hope this helps!
                Thank you for taking the time to answer :) You can maybe add this link too for other people: facebook.github.io/react/blog/2015/12/16/…
– Yormi
                Oct 28, 2016 at 16:06
This usually happens when you call this.setState within a setTimeout or setInterval or some other deferred function. 
If you are using setTimeout/setInterval make sure you call clearTimeout/clearInterval in componentWillUnmount.
                I thought about that,  I really looked all my setState's. I don't have many. And after searching the code base, I have no setTimer nor setInterval. And the last times I had that warning, there was the name of the faulty component instead of _class so is it possible it's something with a library or the transpiler maybe ? Google is pretty quiet about it :P
– Yormi
                Oct 27, 2016 at 23:02
                @Yormi put a breakpoint on a line that emits that warning and you'd get a stack trace that points exactly to the malicious call.
– zerkms
                Oct 27, 2016 at 23:06
                A bit embarrassing, I'm not used to debugging in js with anything else than console.log... I don't have the line number with the warning in my terminal and it doesn't show up when I run the app in the browser. What is the easiest way to achieve that ? iron-node ? Btw, thanks for your help :)
– Yormi
                Oct 27, 2016 at 23:11
                @Yormi in the right part of the error message in the google chrome console there is a clickable file name + line number. You click on it then the exact place of the warning is show, and you put a breakpoint by clicking on the line number on the left. Then you refresh the page (or whatever you do to get that warning) and the debugger stops at that very line.
– zerkms
                Oct 29, 2016 at 1:10
                I manage to do it with the v8 node inspector as I wrote in the edit of the first post. But is there another way to start mocha's tests in the browser ?
– Yormi
                Oct 31, 2016 at 4:24
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.