🤖

クリーンなReactコードを書くためのESLintを調べた

3 min read

背景

「クリーンなReactプロジェクトの21のベストプラクティス」という記事があります。

https://qiita.com/baby-degu/items/ea4eede60bbe9c63a348

この記事に書いてあるプラクティスのいくつかはESLintで自動で対応することができます。

現時点で私が気づいているESLintルールについてまとめておきます。

recommendルールについて

plugin:react/recommendedとかeslint:recommendedに含まれているルールはすでに使っているケースが多いと思うので、解説しないつもりですがもし間違って紹介していたらすみません(recommendedに含まれているルールをつぶさに調べたことも特に無いので、復習になればいいかなと思ってはいる)。

記事内のプラクティスについて

たとえば「フラグメントを使用する」のプラクティスについては、個人的には人によって見解が分かれるところだと思います。そういったそもそものプラクティスの見解が分かれそうに思うところは調査していません。

ESLintルール

JSXの省略形を使用する

BAD

return (
    <Navbar showTitle={true} />
);

GOOD

return(
    <Navbar showTitle />
)

={true}は省略可能なので

https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-boolean-value.md

こちらのルールを使います。

        'react/jsx-boolean-value': 'error'

これでeslint --fixすると={true}の部分を消してくれます。

文字列属性に波括弧は不要

BAD

return(
    <Navbar title={"My Special App"} />
)

GOOD

return(
    <Navbar title="My Special App" />
)

https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-curly-brace-presence.md

こちらのESLintルールを使うことで、余分な波括弧を削除してくれます。

    'react/jsx-curly-brace-presence': 'error',

自己終了タグ

BAD

<SomeComponent variant="stuff"></SomeComponent>

GOOD

<SomeComponent variant="stuff" />

https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/self-closing-comp.md

こちらのESLintルールを使います。

    'react/self-closing-comp': [
      'error',
      {
        component: true,
        html: true,
      },
    ],

テンプレートリテラルを使用する

文字列の連結に+を使うのではなく、テンプレートリテラルで行うのがいいというベストプラクティスです。
こちらについてはprefer-templateというルールがあります。

https://eslint.org/docs/rules/prefer-template

注意

ただしこのルール、テンプレートリテラルに変換後の中括弧内に余分な空白が入る挙動が見受けられました。

  // BEFORE
  const hoge = 'hoge' + token;

  // AFTER
  const hoge = `hoge${  token}`;

// ---

  // BEFORE
  const hoge = 'hoge'+token;

  // AFTER
  const hoge = `hoge${token}`;

どうも、ソースコード中に意図的に開けていた空白の分、中括弧内に挿入される仕様のようです。個人的にはちょっと気持ち悪いかなと思いました。

順番にインポートする

本記事によると、以下の順でインポートを書くのが鉄則とのこと。

  • ビルトイン
  • 外部
  • 内部

ビルトインというのは、React16以前のReactにおけるimport Reactのように、ソースコード中で直接利用するわけじゃないけどimportしなければいけないもののことを指しているのかな。

ビルトインかどうかまで読み取るのはおそらくESLintの責務内では厳しいものかと思うのですが、以下のルールが近しい役割を果たしてくれます。

https://github.com/lydell/eslint-plugin-simple-import-sort

たしかにリーダブルにできそうですが、プロジェクトの途中から入れると差分がかなり大きくなるし、IDEでeslint fixを自動で実行していると鬱陶しそうな気がするので、使うとしても初期開発時から入れるのかなと感じました。

暗黙の戻り値を使用する

BAD

const add = (a, b) => {
    return a + b;
}

上記のように、単にreturnするだけの関数だったら、アロー関数の省略形で書けるので書きましょうというルール。

以下のルールで設定可能っぽい。とはいえ、あとからreturnの前にフックとかを書き足そうと思っているときにautofixで消されてしまうと悲しいのでこれも好みによるのかな。

https://eslint.org/docs/rules/arrow-body-style

コンポーネントの命名

コンポーネントにはパスカルケースで命名しましょうというベストプラクティス。

以下のルールで対応できます。これも意外とrecommendedに入っていませんでした。

https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-pascal-case.md

引用符

「JSX の属性には二重引用符を使い、その他の JS には一重引用符を使います。」とのことですが、普通のJSにシングルクォーテーション使うかどうかは好みかと思います。全部バッククォートでいいやんという論説もあるかと思いますし。

JSXに使う引用符については、以下のルールで対応できます。

https://eslint.org/docs/rules/jsx-quotes

感想

意外とrecommendedに入っていないルールでも、あると助かるものが多くてためになったし、早速手元のプロジェクトで設定してみた。

余談1

以下の記事がほとんどここまで調べた内容を包含していて、こっちのほうがいいのではないかとなった。知らないことがたくさんあるものですね・・・

https://qiita.com/yamadashy/items/e64762e407b8dd5e0247

余談2

この記事が染みる。

全部のeslintルールを一旦ONにするという発想があるのは初めて知った。それはそれで面白い。

https://qiita.com/khsk/items/0f200fc3a4a3542efa90

Discussion

ログインするとコメントできます