[10.0.0-alpha.2] - setState() doesn't apply state when called within componentWillMount
See original GitHub issueIn 10.0.0-alpha.2, state does not set properly from componentWillMount
. It seems this has been experienced by others in the past in componentWillReceiveProps
. Here’s a simple test case:
export class TestComponent extends Component {
//This does not work:
componentWillMount() {
this.setState({message:"componentWillMount"});
}
/*
//This works:
componentDidMount() {
this.setState({message:"componentDidMount"});
}
*/
render() {
return <p>State came through from {this.state.message || 'nothing =('}</p>;
}
}
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:7 (4 by maintainers)
Top Results From Across the Web
javascript - setState in componentWillMount doesn't reflect in ...
I am making an ajax request In my componentWillMount function of react component. I have a state variable. I set the state of...
Read more >React.Component
Binding event handler methods to an instance. You should not call setState() in the constructor() . Instead, if your component needs to use...
Read more >componentWillMount() vs componentDidMount()
Using a fetch call within componentWillMount() causes the component to render with empty data at first, because componentWillMount() will ...
Read more >Is it good to use `setState()` in `componentWillMount()` method?
componentWillMount() is invoked immediately before mounting occurs. It is called before render() , therefore setting state in this method will not trigger a...
Read more >React - Releases
Use it instead of ReactDOM.hydrate in conjunction with the new React DOM ... Fix multiple setState() calls in componentWillMount() in shallow renderer.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
probably so. but i… i think there is a better way to solve these problems. maybe we do not need
s
. let me think about it.We’ll likely keep them around until they are completely removed in
react
. We still need them for allUNSAFE_*
methods in compat which are just aliased to the unprefixed lifecycle methods. They need to be called in the correct order inside the diff and that’s why we don’t gain any size benefits until they are removed completely.