Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
851 lines (630 sloc) 32.5 KB

Airbnb React/JSX Style Guide

A mostly reasonable approach to React and JSX

This style guide is mostly based on the standards that are currently prevalent in JavaScript, although some conventions (i.e async/await or static class fields) may still be included or prohibited on a case-by-case basis. Currently, anything prior to stage 3 is not included nor recommended in this guide.

このスタイルガイドは、最近のJavaScriptの流行に沿った標準に準じています。 しかしながら、いくつかの慣例(async/awaitやstatic class fieldsのようなもの)は、場合によって含まれていたり禁止されていたりします。 現在のところこのガイドでは、ステージ3以前のものは全て含まれていないか非推奨となっています。

Table of Contents

  1. Basic Rules(基本ルール)
  2. Class vs React.createClass vs stateless
  3. Mixins
  4. Naming(命名)
  5. Declaration(宣言)
  6. Alignment(位置揃え)
  7. Quotes(引用符)
  8. Spacing(スペース)
  9. Props(属性)
  10. Refs(参照)
  11. Parentheses(括弧)
  12. Tags(タグ)
  13. Methods(関数)
  14. Ordering(順序)
  15. isMounted

Basic Rules(基本ルール)

  • Only include one React component per file.

  • Always use JSX syntax.

  • Do not use React.createElement unless you're initializing the app from a file that is not JSX.

  • Reactコンポーネントは1ファイル1つとすること。

  • 常にJSX構文を使用すること。

  • JSXを使用していないファイルからのアプリケーション初期化でない限り、React.createElementを利用しないこと。

Class vs React.createClass vs stateless

// bad
const Listing = React.createClass({
  // ...
  render() {
    return <div>{this.state.hello}</div>;
  }
});

// good
class Listing extends React.Component {
  // ...
  render() {
    return <div>{this.state.hello}</div>;
  }
}

And if you don't have state or refs, prefer normal functions (not arrow functions) over classes:

そして、状態やrefsを保持しない場合、クラスより通常の関数(アロー関数ではない)の利用を推奨します。

// bad
class Listing extends React.Component {
  render() {
    return <div>{this.props.hello}</div>;
  }
}

// bad (relying on function name inference is discouraged)
const Listing = ({ hello }) => (
  <div>{hello}</div>
);

// good
function Listing({ hello }) {
  return <div>{hello}</div>;
}

Mixins

Why? Mixins introduce implicit dependencies, cause name clashes, and cause snowballing complexity. Most use cases for mixins can be accomplished in better ways via components, higher-order components, or utility modules.

なぜ?Mixinは暗黙的な依存関係をもたらし、名前の衝突を起こして、雪玉が坂道を転がるような複雑さの原因になります。Mixinの利用例のほとんどは、コンポーネント、higher-order components(高次コンポーネント)、ユーティリティモジュールなどのより良い方法で代用が可能です。

Naming(命名)

  • Extensions: Use .jsx extension for React components.

  • Filename: Use PascalCase for filenames. E.g., ReservationCard.jsx.

  • Reference Naming: Use PascalCase for React components and camelCase for their instances. eslint: react/jsx-pascal-case

  • 拡張子: Reactコンポーネントの拡張子には.jsxを利用すること。

  • ファイル名: ファイル名にはパスカル記法を利用すること. 例) ReservationCard.jsx.

  • 参照名: Reactコンポーネントにはパスカル記法を利用し、それらのインスタンスにはキャメル記法を利用すること。eslint: react/jsx-pascal-case

// bad
import reservationCard from './ReservationCard';

// good
import ReservationCard from './ReservationCard';

// bad
const ReservationItem = <ReservationCard />;

// good
const reservationItem = <ReservationCard />;
  • Component Naming: Use the filename as the component name. For example, ReservationCard.jsx should have a reference name of ReservationCard. However, for root components of a directory, use index.jsx as the filename and use the directory name as the component name:

  • コンポーネント名: ファイル名をコンポーネント名として利用すること。例えば、 ReservationCard.jsx の参照名は ReservationCard とするべき。しかし、コンポーネントがあるルート・ディレクトリの index.jsx は、ディレクトリ名をコンポーネント名として利用してください。

// bad
import Footer from './Footer/Footer';

// bad
import Footer from './Footer/index';

// good
import Footer from './Footer';
  • Higher-order Component Naming: Use a composite of the higher-order component's name and the passed-in component's name as the displayName on the generated component. For example, the higher-order component withFoo(), when passed a component Bar should produce a component with a displayName of withFoo(Bar).

Why? A component's displayName may be used by developer tools or in error messages, and having a value that clearly expresses this relationship helps people understand what is happening.

  • 高次コンポーネント名: 生成されたコンポーネントには、displayName に渡されたコンポーネント名と高次コンポーネント名を複合した名称を利用すること。例えば、高次コンポーネント withFoo() に対し、Barコンポーネントを渡す場合は、 生成されるコンポーネントの displayNamewithFoo(Bar) となるべきです。

なぜ?コンポーネントの displayName は開発者ツールやエラーメッセージの中で利用され、その関連を明確に表現する値を持つことは、何が起こっているかを理解するための助けになるでしょう。

// bad
export default function withFoo(WrappedComponent) {
  return function WithFoo(props) {
    return <WrappedComponent {...props} foo />;
  }
}

// good
export default function withFoo(WrappedComponent) {
  function WithFoo(props) {
    return <WrappedComponent {...props} foo />;
  }

  const wrappedComponentName = WrappedComponent.displayName
    || WrappedComponent.name
    || 'Component';

  WithFoo.displayName = `withFoo(${wrappedComponentName})`;
  return WithFoo;
}
  • Props Naming: Avoid using DOM component prop names for different purposes.

Why? People expect props like style and className to mean one specific thing. Varying this API for a subset of your app makes the code less readable and less maintainable, and may cause bugs.

  • Props名: DOMのprops名を異なる目的に利用することを避ける。

なぜ?人々はstyleclassNameなどのprops名を特定の1つのことを意味すると推測します。これらのAPIを変更することで、コードの可読性やメンテナンス性が下がり、不具合の原因になることもあります。

// bad
<MyComponent style="fancy" />

// bad
<MyComponent className="fancy" />

// good
<MyComponent variant="fancy" />

Declaration(宣言)

  • Do not use displayName for naming components. Instead, name the component by reference.

  • displayName をコンポーネントの名付けのために利用してはいけません。代わりにコンポーネントは参照ごとに名付けます。(訳注)ここ場合での参照とはクラス名のことだと思われます。

// bad
export default React.createClass({
  displayName: 'ReservationCard',
  // stuff goes here
});

// good
export default class ReservationCard extends React.Component {
}

Alignment(位置揃え)

// bad
<Foo superLongParam="bar"
     anotherSuperLongParam="baz" />

// good
<Foo
  superLongParam="bar"
  anotherSuperLongParam="baz"
/>

// if props fit in one line then keep it on the same line
<Foo bar="bar" />

// children get indented normally
<Foo
  superLongParam="bar"
  anotherSuperLongParam="baz"
>
  <Quux />
</Foo>  

Quotes(引用符)

  • Always use double quotes (") for JSX attributes, but single quotes (') for all other JS. eslint: jsx-quotes

Why? Regular HTML attributes also typically use double quotes instead of single, so JSX attributes mirror this convention.

  • JSX内の要素は常に二重引用符 (") を利用し、そのほかのJSには引用符 ('\) を利用すること。eslint: jsx-quotes

なぜ?標準のHTML要素も一般的に引用符の代わりに二重引用符を利用しているため、JSX要素もこの慣習に従っています。

// bad
<Foo bar='bar' />

// good
<Foo bar="bar" />

// bad
<Foo style={{ left: "20px" }} />

// good
<Foo style={{ left: '20px' }} />

Spacing(スペース)

// bad
<Foo/>

// very bad
<Foo                 />

// bad
<Foo
 />

// good
<Foo />
// bad
<Foo bar={ baz } />

// good
<Foo bar={baz} />

Props(属性)

  • Always use camelCase for prop names.

  • 属性名は常にキャメル記法を利用すること。

// bad
<Foo
  UserName="hello"
  phone_number={12345678}
/>

// good
<Foo
  userName="hello"
  phoneNumber={12345678}
/>
// bad
<Foo
  hidden={true}
/>

// good
<Foo
  hidden
/>

// good
<Foo hidden />
  • Always include an alt prop on <img> tags. If the image is presentational, alt can be an empty string or the <img> must have role="presentation". eslint: jsx-a11y/alt-text

  • <img> タグは常に alt 属性を含めること。 画像が単にプレゼンテーション用である場合は、 alt は空の文字列か <img> タグに role="presentation" を持つこと。eslint: jsx-a11y/alt-text

// bad
<img src="hello.jpg" />

// good
<img src="hello.jpg" alt="Me waving hello" />

// good
<img src="hello.jpg" alt="" />

// good
<img src="hello.jpg" role="presentation" />

Why? Screenreaders already announce img elements as images, so there is no need to include this information in the alt text.

  • <img>alt 属性の中では、"image", "photo", "picture"のような単語は利用しないこと。eslint: jsx-a11y/img-redundant-alt

なぜ?スクリーンリーダーは既に img 要素を画像であることを通知しているため、このような情報をaltのテキスト情報に含めることは不要です。

// bad
<img src="hello.jpg" alt="Picture of me waving hello" />

// good
<img src="hello.jpg" alt="Me waving hello" />
// bad - not an ARIA role
<div role="datepicker" />

// bad - abstract ARIA role
<div role="range" />

// good
<div role="button" />

Why? Inconsistencies between keyboard shortcuts and keyboard commands used by people using screenreaders and keyboards complicate accessibility.

なぜ?スクリーンリーダーやキーボードを利用する人々の中で、キーボードショートカットとキーボードコマンドの不整合を起すことは、アクセシビリティを複雑なものにしてしまいます。

// bad
<div accessKey="h" />

// good
<div />
  • Avoid using an array index as key prop, prefer a unique ID. (why?)

  • key 属性のようなものには配列の添字の利用を避け、一意なIDを利用すること。(なぜ?)

// bad
{todos.map((todo, index) =>
  <Todo
    {...todo}
    key={index}
  />
)}

// good
{todos.map(todo => (
  <Todo
    {...todo}
    key={todo.id}
  />
))}
  • Always define explicit defaultProps for all non-required props.

Why? propTypes are a form of documentation, and providing defaultProps means the reader of your code doesn’t have to assume as much. In addition, it can mean that your code can omit certain type checks.

  • 常に必須ではない全てのpropsに対して明示的にデフォルト値を定義すること。

なぜ?propTypesはドキュメントの一種であり、デフォルト値を提供することでコードの読者たる人々は多くのことを想定しなくて済みます。それに加えて、特定の型チェックを省略することができます。

// bad
function SFC({ foo, bar, children }) {
  return <div>{foo}{bar}{children}</div>;
}
SFC.propTypes = {
  foo: PropTypes.number.isRequired,
  bar: PropTypes.string,
  children: PropTypes.node,
};

// good
function SFC({ foo, bar, children }) {
  return <div>{foo}{bar}{children}</div>;
}
SFC.propTypes = {
  foo: PropTypes.number.isRequired,
  bar: PropTypes.string,
  children: PropTypes.node,
};
SFC.defaultProps = {
  bar: '',
  children: null,
};
  • Use spread props sparingly.

Why? Otherwise you're more likely to pass unnecessary props down to components. And for React v15.6.1 and older, you could pass invalid HTML attributes to the DOM.

  • propsのspread構文は控えめに使うこと。

なぜ?さもないと、あなたはかなりの確率で不要なpropsをコンポーネントに渡すことになります。React v15.6.1 とそれより古い場合、不正なHTMLアトリビュートをDOMに渡すことができます。

Exceptions:

  • HOCs that proxy down props and hoist propTypes

例外:

  • propTypesを巻き上げてpropsを代理で渡すようなHOC
function HOC(WrappedComponent) {
  return class Proxy extends React.Component {
    Proxy.propTypes = {
      text: PropTypes.string,
      isLoading: PropTypes.bool
    };

    render() {
      return <WrappedComponent {...this.props} />
    }
  }
}
  • Spreading objects with known, explicit props. This can be particularly useful when testing React components with Mocha's beforeEach construct.

  • 既知の明確なオブジェクトをspreadする場合。これは、MochaのbeforeEachでReactコンポーネントをテストする時など一部で有効です。

export default function Foo {
  const props = {
    text: '',
    isPublished: false
  }

  return (<div {...props} />);
}

Notes for use:

Filter out unnecessary props when possible. Also, use prop-types-exact to help prevent bugs.

利用上の注意:

可能であれば不要なpropsを取り除くこと。 そして、prop-types-exactを使って不具合を防止すること。

//good
render() {
  const { irrelevantProp, ...relevantProps  } = this.props;
  return <WrappedComponent {...relevantProps} />
}

//bad
render() {
  const { irrelevantProp, ...relevantProps  } = this.props;
  return <WrappedComponent {...this.props} />
}

Refs(参照)

// bad
<Foo
  ref="myRef"
/>

// good
<Foo
  ref={ref => { this.myRef = ref; }}
/>

Parentheses(括弧)

// bad
render() {
  return <MyComponent className="long body" foo="bar">
           <MyChild />
         </MyComponent>;
}

// good
render() {
  return (
    <MyComponent className="long body" foo="bar">
      <MyChild />
    </MyComponent>
  );
}

// good, when single line
render() {
  const body = <div>hello</div>;
  return <MyComponent>{body}</MyComponent>;
}

Tags(タグ)

// bad
<Foo className="stuff"></Foo>

// good
<Foo className="stuff" />
// bad
<Foo
  bar="bar"
  baz="baz" />

// good
<Foo
  bar="bar"
  baz="baz"
/>

Methods(関数)

  • Use arrow functions to close over local variables.

  • ローカル変数を閉じ込めるためにアロー関数を利用すること。

function ItemList(props) {
  return (
    <ul>
      {props.items.map((item, index) => (
        <Item
          key={item.key}
          onClick={() => doSomethingWith(item.name, index)}
        />
      ))}
    </ul>
  );
}
  • Bind event handlers for the render method in the constructor. eslint: react/jsx-no-bind

Why? A bind call in the render path creates a brand new function on every single render.

  • render関数のためのイベントハンドラはコンストラクタ内でbindすること。eslint: react/jsx-no-bind

なぜ?render上で呼び出されたbindは、1つの描画ごとに新しい関数を作成してしまいます。

// bad
class extends React.Component {
  onClickDiv() {
    // do stuff
  }

  render() {
    return <div onClick={this.onClickDiv.bind(this)} />
  }
}

// good
class extends React.Component {
  constructor(props) {
    super(props);

    this.onClickDiv = this.onClickDiv.bind(this);
  }

  onClickDiv() {
    // do stuff
  }

  render() {
    return <div onClick={this.onClickDiv} />
  }
}
  • Do not use underscore prefix for internal methods of a React component.

Why? Underscore prefixes are sometimes used as a convention in other languages to denote privacy. But, unlike those languages, there is no native support for privacy in JavaScript, everything is public. Regardless of your intentions, adding underscore prefixes to your properties does not actually make them private, and any property (underscore-prefixed or not) should be treated as being public. See issues #1024, and #490 for a more in-depth discussion.

  • Reactコンポーネントの内部関数ではアンダースコアを接頭語として利用しないこと。

なせ?接頭語にアンダースコアを使うことは、他の言語ではプライベートを表すものとして利用されます。しかし、他の言語と違い、JavaScriptではプライベートのネイティブのサポートはなく、全ては公開されています。あなたの意図に関わらず、プロパティに接頭語にアンダースコアをつけたとしても実際にはプライベートにはなりません。そしてプロパティ(接頭語にアンダースコアあり、なし)は公開として扱われなければなりません。詳細はこちらのIssue#1024と、こちら #490を参照してください。

// bad
React.createClass({
  _onClickSubmit() {
    // do stuff
  },

  // other stuff
});

// good
class extends React.Component {
  onClickSubmit() {
    // do stuff
  }

  // other stuff
}
// bad
render() {
  (<div />);
}

// good
render() {
  return (<div />);
}

Ordering(順序)

  • Ordering for class extends React.Component:
  1. optional static methods
  2. constructor
  3. getChildContext
  4. componentWillMount
  5. componentDidMount
  6. componentWillReceiveProps
  7. shouldComponentUpdate
  8. componentWillUpdate
  9. componentDidUpdate
  10. componentWillUnmount
  11. clickHandlers or eventHandlers like onClickSubmit() or onChangeDescription()
  12. getter methods for render like getSelectReason() or getFooterContent()
  13. optional render methods like renderNavigation() or renderProfilePicture()
  14. render
  • class extends React.Componentの順序:
  1. 任意の static 関数
  2. constructor
  3. getChildContext
  4. componentWillMount
  5. componentDidMount
  6. componentWillReceiveProps
  7. shouldComponentUpdate
  8. componentWillUpdate
  9. componentDidUpdate
  10. componentWillUnmount
  11. onClickSubmit()onChangeDescription() のようなクリックハンドラやイベントハンドラ
  12. getSelectReason()getFooterContent() のような*renderのためのGetter関数*
  13. renderNavigation()renderProfilePicture() のような付随的なrender関数
  14. render
  • How to define propTypes, defaultProps, contextTypes, etc...

  • propTypes, defaultProps, contextTypes などをどのように定義するか。

import React from 'react';
import PropTypes from 'prop-types';

const propTypes = {
  id: PropTypes.number.isRequired,
  url: PropTypes.string.isRequired,
  text: PropTypes.string,
};

const defaultProps = {
  text: 'Hello World',
};

class Link extends React.Component {
  static methodsAreOk() {
    return true;
  }

  render() {
    return <a href={this.props.url} data-id={this.props.id}>{this.props.text}</a>
  }
}

Link.propTypes = propTypes;
Link.defaultProps = defaultProps;

export default Link;
  1. displayName
  2. propTypes
  3. contextTypes
  4. childContextTypes
  5. mixins
  6. statics
  7. defaultProps
  8. getDefaultProps
  9. getInitialState
  10. getChildContext
  11. componentWillMount
  12. componentDidMount
  13. componentWillReceiveProps
  14. shouldComponentUpdate
  15. componentWillUpdate
  16. componentDidUpdate
  17. componentWillUnmount
  18. clickHandlers or eventHandlers like onClickSubmit() or onChangeDescription()
  19. getter methods for render like getSelectReason() or getFooterContent()
  20. optional render methods like renderNavigation() or renderProfilePicture()
  21. render
  1. displayName
  2. propTypes
  3. contextTypes
  4. childContextTypes
  5. mixins
  6. statics
  7. defaultProps
  8. getDefaultProps
  9. getInitialState
  10. getChildContext
  11. componentWillMount
  12. componentDidMount
  13. componentWillReceiveProps
  14. shouldComponentUpdate
  15. componentWillUpdate
  16. componentDidUpdate
  17. componentWillUnmount
  18. onClickSubmit()onChangeDescription() のような*クリックハンドラやイベントハンドラ**
  19. getSelectReason()getFooterContent() のような*renderのためのGetter関数*
  20. renderNavigation()renderProfilePicture() のような付随的なrender関数
  21. render

isMounted

Why? [isMounted is an anti-pattern][anti-pattern], is not available when using ES6 classes, and is on its way to being officially deprecated.

なぜ?[isMounted はアンチパターン][anti-pattern]。これはES6クラス構文を利用したときに利用できず、公式に非推奨となっています。 [anti-pattern]: https://facebook.github.io/react/blog/2015/12/16/ismounted-antipattern.html

Translation(翻訳)

This JSX/React style guide is also available in other languages:

このJSX/Reactスタイルガイドは他の言語でも利用可能です。:

⬆ back to top