Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Added additional detail to "props-in-getInitialState" anti-pattern doc #5849

Merged
merged 1 commit into from
Jan 14, 2016
Merged

Added additional detail to "props-in-getInitialState" anti-pattern doc #5849

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions docs/tips/10-props-in-getInitialState-as-anti-pattern.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:**

Expand Down Expand Up @@ -43,7 +45,7 @@ ReactDOM.render(<MessageBox name="Rogers"/>, 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({
Expand Down