-
Notifications
You must be signed in to change notification settings - Fork 216
Coding Standard
Within your react component, you should order your methods like so:
- lifecycle methods (in chronological order:
getDefaultProps
,getInitialState
,componentWillMount
,componentDidMount
,componentWillReceiveProps
,shouldComponentUpdate
,componentWillUpdate
,componentDidUpdate
,componentWillUnmount
) - everything else
render
Example:
<Component onClick={this.handleClick} onLaunchMissiles={this.handleLaunchMissiles} />
This is consistent with React's event naming: onClick
, onDrag
,
onChange
, etc.
Example:
<Component onLaunchMissiles={this.handleLaunchMissiles} />
Elements that span more than 80 characters or contain multiple nodes should open on a separate line.
Yes:
return (
<div>
<div>
...
</div>
</div>
);
Yes:
return <div>...</div>;
No:
return <div> // "div" is on the same line as "return"
<div>
...
</div>
</div>;
Fit them all on the same line if you can. If you can't, put each property on a line of its own, indented four spaces, in sorted order. The closing angle brace should be on a line of its own, indented the same as the opening angle brace. This makes it easy to see the props at a glance.
Yes:
<div className="highlight" key="highlight-div">
<div
className="highlight"
key="highlight-div"
>
<Image
className="highlight"
key="highlight-div"
/>
No:
<div className="highlight" // property not on its own line
key="highlight-div"
>
<div // closing brace not on its own line
className="highlight"
key="highlight-div">
<div // property is not sorted
key="highlight-div"
className="highlight"
>
Every .jsx file should export a single react class, and nothing else. This is for testability: the fixture framework requires it to function.
Note the file can still define multiple classes, it just can't export more than one.
It's useful to think of the React world as divided into "logic" components and "presentation" components.
"Logic" components have application logic, but do not emit HTML themselves.
"Presentation" components are typically reusable, and do emit HTML.
Logic components can have internal state, but presentation components never should.
Prefer props to state.
You almost always want to use props. By avoiding state when possible, you minimize redundancy, making it easier to reason about your application.
A common pattern -- which matches the "logic" vs. "presentation" component distinction -- is to create several stateless components that just render data, and have a stateful component above them in the hierarchy that passes its state to its children via props. The stateful component encapsulates all of the interaction logic, while the stateless components take care of rendering data in a declarative way.
Copying data from props to state can cause the UI to get out of sync and is especially bad.
Use propTypes.
React Components should always have complete propTypes. Every attribute of this.props should have a corresponding entry in propTypes. This documents that props need to be passed to a model.
If you as passing data through to a child component, you can use
the prop-type <child-class>.propTypes.<prop-name>
.
Avoid these non-descriptive prop-types:
React.PropTypes.any
React.PropTypes.array
React.PropTypes.object
Instead, use
React.PropTypes.arrayOf
React.PropTypes.objectOf
React.PropTypes.instanceOf
React.PropTypes.shape
As an exception, if passing data through to a child component, and you
can't use <child-class>.propTypes.<prop-name>
for some reason, you
can use React.PropType.any
.
Do not use data-
attributes or classes. All information
should be stored in Javascript.