Added additional detail to "props-in-getInitialState" anti-pattern doc
While seemingly self-explanatory, this clarifies the reasons props usage in getInitialState might be considered an antipattern.
David Granado committed
Jan 13, 2016 at 16:20 UTC
fb5cd2f7aece37b03b721b5dad510c26c50c2f17
1 file changed
+4
-2
docs/tips/10-props-in-getInitialState-as-anti-pattern.md
+4
-2
@@ -11,7 +11,9 @@ next: dom-event-listeners.html
11
>
12
> This isn't really a React-specific tip, as such anti-patterns often occur in code in general; in this case, React simply points them out more clearly.
13
14
-Using props, passed down from parent, to generate state in `getInitialState` often leads to duplication of "source of truth", i.e. where the real data is. Whenever possible, compute values on-the-fly to ensure that they don't get out of sync later on and cause maintenance trouble.
14
+Using props to generate state in `getInitialState` often leads to duplication of "source of truth", i.e. where the real data is. This is because `getInitialState` is only invoked when the component is first created.
15
+
16
+Whenever possible, compute values on-the-fly to ensure that they don't get out of sync later on and cause maintenance trouble.
17
18
**Bad example:**
19
@@ -43,7 +45,7 @@ ReactDOM.render(<MessageBox name="Rogers"/>, mountNode);
45
46
(For more complex logic, simply isolate the computation in a method.)
47
46
-However, it's **not** an anti-pattern if you make it clear that synchronization's not the goal here:
48
+However, it's **not** an anti-pattern if you make it clear that the prop is only seed data for the component's internally-controlled state:
49
50
```js
51
var Counter = React.createClass({