From fb5cd2f7aece37b03b721b5dad510c26c50c2f17 Mon Sep 17 00:00:00 2001 From: David Granado Date: Wed, 13 Jan 2016 16:20:07 -0600 Subject: [PATCH] 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. --- docs/tips/10-props-in-getInitialState-as-anti-pattern.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/tips/10-props-in-getInitialState-as-anti-pattern.md b/docs/tips/10-props-in-getInitialState-as-anti-pattern.md index fbfad60d99..70b41bf95f 100644 --- a/docs/tips/10-props-in-getInitialState-as-anti-pattern.md +++ b/docs/tips/10-props-in-getInitialState-as-anti-pattern.md @@ -11,7 +11,9 @@ next: dom-event-listeners.html > > 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. -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. +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. + +Whenever possible, compute values on-the-fly to ensure that they don't get out of sync later on and cause maintenance trouble. **Bad example:** @@ -43,7 +45,7 @@ ReactDOM.render(, mountNode); (For more complex logic, simply isolate the computation in a method.) -However, it's **not** an anti-pattern if you make it clear that synchronization's not the goal here: +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: ```js var Counter = React.createClass({