Skip to content

Commit 5cd44d2

Browse files
bytetwingaearon
authored andcommitted
Refractor docs to indicate that state set to props in constructor will not recieve the updated props (#9404)
1 parent 446f186 commit 5cd44d2

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

docs/docs/reference-react-component.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -113,7 +113,7 @@ The constructor for a React component is called before it is mounted. When imple
113113

114114
The constructor is the right place to initialize state. If you don't initialize state and you don't bind methods, you don't need to implement a constructor for your React component.
115115

116-
It's okay to initialize state based on props if you know what you're doing. Here's an example of a valid `React.Component` subclass constructor:
116+
It's okay to initialize state based on props. This effectively "forks" the props and sets the state with the initial props. Here's an example of a valid `React.Component` subclass constructor:
117117

118118
```js
119119
constructor(props) {
@@ -124,7 +124,7 @@ constructor(props) {
124124
}
125125
```
126126

127-
Beware of this pattern, as it effectively "forks" the props and can lead to bugs. Instead of syncing props to state, you often want to [lift the state up](/react/docs/lifting-state-up.html).
127+
Beware of this pattern, as state won't be up-to-date with any props update. Instead of syncing props to state, you often want to [lift the state up](/react/docs/lifting-state-up.html).
128128

129129
If you "fork" props by using them for state, you might also want to implement [`componentWillReceiveProps(nextProps)`](#componentwillreceiveprops) to keep the state up-to-date with them. But lifting state up is often easier and less bug-prone.
130130

0 commit comments

Comments
 (0)