1. コンポーネントは小さく機能ごとに

これは基本のキでして、例えば一つのページに表示したい内容を全て同一のファイルに書いてしまったりしていると、コード量が膨大で可読性も低いしメンテも大変だしであまりメリットがありません。そこで、表示したいUIを機能ごとにコンポーネントに分けて使っていこうというのが本件であります。

この記事でもあるように • それぞれの小さなコンポーネントは、複数のプロジェクトで再利用することができる。

ので同じようなUIを使いまわせるので、効率的に開発できます。プロジェクトが大きくなればなるほどその効果は効いてくるので、序盤で汎用的なものを揃えておくのも良いかもしれません。

またコンポーネントの分け方についてはAtomic Designなんかが参考になるかと思います。

個人的には、ページ単位でのコンポーネントを作る際はほとんどと言っていいほどコンポーネントを分割していて、特に表示したい内容が多い場合はセクションごとに分割したりしています。その中で、汎用的なものがあればComponentsに作成し、独自性が強いものはディレクトリの同階層にpartialsディレクトリ内に作るようにしています。

4. CSSをJavaScriptに入れる

通常は全てのcssを一つのSCSSにまとめるのが一般的と書かれていますが（知らなかった）これを一つのjs内に入れちゃおうという発想ですね。

いわゆる「css in JS」というやつで、JavaScriptの中でCSSを記述し、コンポーネントに直接スタイルを適用する手法です。これにより、スタイルのスコープがコンポーネントに限定され、他のコンポーネントとのスタイルの衝突を避けることができます。また、スタイルとコンポーネントの関連性が高まるため、コードの保守性が向上します。

EmotionJSが代用的です。

import { jsx } from '@emotion/core';
let Component = props => {

  return (
   <div css={{ border: '1px solid black' }} {...props} />
  );
}

スタイルの付け方はTailWind CSSだったり色々派閥があるイメージですが、個人的には普段使っているCSS Modulesに馴染みがあるので今後も使っていきたいところ。

どれもグローバル汚染を防いでくれるので、使いやすい方を選ぶのが良い気がしています。

6.関数にちなんでコンポーネントに名前を付ける

これはコンポーネントの命名についてですね。この機能がどういう機能を持つかという基準で命名していこうということで、これがとある文脈を入れすぎちゃうと本当は使いまわせるのに名前のせいで使用が限定的だと思われるようになってしまうんですよね。本記事はから例を引用します。

ProductTable: この名前からは、製品のリストや情報を表示するテーブルのコンポーネントであることが直感的に理解できます。これにより、コンポーネントが何をするかが一目で明らかになり、コードを読む際の文脈も自然と理解しやすくなります。
Avatar vs. AuthorAvatar: 「Avatar」という名前は、任意のユーザーのアバター画像を表示する汎用性の高いコンポーネントであることを示します。一方、「AuthorAvatar」という名前は、その使用が特定の文脈（例えば、記事の著者のアバターを表示する場合）に限定されることを示唆しています。後者のように具体的な使用場面を名前に反映させると、そのコンポーネントの再利用性が低下する可能性があります。

ちなみに名前の付け方はこれ以外にも「動詞 + 名詞」といったパターンを統一することで管理しやすくなると思っていて、

動詞 + 名詞のパターンだったらそのコンポーネントがどんな役割かがパッと入ってきやすい印象があります。あとはディレクトリ内に Edit〇〇のようにソートされるので、編集系はこの辺だなーと探しやすくなったりも個人的にはしてます。

名詞が先のパターンもメリットがあって、Password〇〇といったようにディレクトリ内でソートされることで、機能ごとのグルーピングがされてる分、見通しが良くなったりする気もしています。どちらにもメリットはあるので、プロジェクト内で統一されていればどちらでも良いと思います。

11.一つのコンポーネントに関連するすべてのファイルは、一つのフォルダにあるべきである。

これも基本ですが、一つのコンポーネントに関するスタイルやカスタムhooksといった関連ファイルはコンポーネントファイルと同一のフォルダに入っていることで管理がしやすくなります。この内容自体は一般的に知られている構造だとは思います。補足的に書きたかったのは、コンポーネントはコマンドで生成できるようにしておいて、生成する内容をjsx,スタイル,カスタムhooksとかで汎用的にできればスムーズに開発ができるという点です。まあこれに関しては今のプロジェクトがそうだったってことが大きいですが、個人でプロジェクトを立ち上げるなら必ずコマンでの設定はやっておきたいですねー。story bookとか使うならここに入れるのもありかも。

12. Bitのようなツールを使う

これについては恥ずかしながら知らなかったんですが、どうやらコンポーネントのプロジェクト間で共有するためのツールだそうで、クラウド上で作ったコンポーネントを共有できるみたいです。またテスト、ドキュメント作成までを一括でサポートしているとのこと。ざっくりですがこれで効率よくUIの実装ができるようになりそう。気になったのはこのベストプラクティスに乗ってる割には日本の記事であんまり見ないなーと笑いつか流行るのでしょうか。もう流行っているのか？謎の技術に今後も注目です。

15.リンティングの規則に従い、長すぎる行を分割する。

みんな大好きリンターです。ESLintを使いましょう。以上。で終わるのも勿体無いので、改めてメリットをおさらいしましょう。

コードエラーの早期発見
コードスタイルの統一
可読性の向上
後続の開発者のためのガイドラインとなる:

とにかく人によってコードの書き方がバラバラだったりするので統一すると読みやすくなるし、エラーも早く見つけれるしでいいとこだらけですね。

これをCIに組み込んでチェックするもよし、コマンドでチェックを走らせるものよしです。

まとめ

Reactのベストプラクティスという題名だったのでてっきりReact hooksの内容が中心かと思いきや、コンポーネント作成だったりスタイルの付け方だったり思ったよりも基本的な内容で肩透かしを食らった感がありましたが、内容そのものは真っ当だった気がしています。知らない内容もあったので勉強になりましたー。

Ryo Onoderaのブログ

「15 React Best Practices You Need to Follow」を読んだ