react-philosophies を読んでの所感

はじめに

フロントエンドエンジニアの関(@kur0buchi)です。

プログラマとして自分で新しくコードを書いたり、誰かの書いたコードをメンテナンスする中で「良いコードとは」を悶々と考える日々を送る中、先日 Twitter のタイムライン上で mithi/react-philosophies というリポジトリを偶然見かけました。

github.com

things I think about when I write React code.
(Reactコードを書くときに考えること。)

のイントロダクションで始まるこの文章が、普段自分が React でアプリケーションを書いてる中でぼんやりと考えていることの言語化がされていたり、また正直あまり深く考えていなかった部分に気付かされたりと、非常に興味深い内容だったので記事として紹介しようと思い立ちました。

当記事は mithi/react-philosophies を読んだ私自身の所感を述べるものになっており、翻訳記事や詳細な内容を記すものではありません、ご了承ください。

また参照元の記事の内容に関しましても、イントロダクションで

  • just guidelines and NOT rigid rules
    (単なるガイドラインであり、厳格なルールではありません)
  • a living document and will evolve over time as my experience grows
    (生きているドキュメントであり、私の経験が成長するにつれて時間とともに進化します)

とある通りですのでこの点もご留意いただければと思います。

内容について

mithi/react-philosophies の構成は以下のようになります

  1. イントロダクション
  2. 必要最低限
  3. 幸せのためのデザイン(設計)
  4. パフォーマンスのヒント
  5. テストの原則
  6. 見識を他の人と共有する

最後の章については「Pull Request であなたの考えを教えて下さい!」といった内容でした。 「ぜひこれも!」というものがあったら Contribute してみるのもいいかもしれません

以下より1章からそれぞれ感じたことをいくつかピックアップしながら述べていきます。 あっさりと触れていくので原文も是非読んでみてください。

必要最低限

この章はタイトルにもある通りごく当たり前のことがほとんどかと思います。

コンピュータはあなたより賢いと認識する

タイトルは刺激的ですが、linter や formatter、フレームワークなど活用できるものは活用しましょうということですね。

  • Typescript will make your life so much easier.
  • NextJS is an awesome framework.

その通りだと思います。

見つけたときよりも少し良くする

何かがおかしいと思ったらその場で直す、すぐ直せなくてもコメントや Issue を残す。
大掛かりなリファクタリング作業にならないようにこまめなメンテナスを重ねるのは重要に思います。

幸せのためのデザイン(設計)

この辺からやや耳の痛い文章が続きます。

バナナを持ったゴリラとジャングルではなく、バナナを渡します

この言い回しは面白くて好きです。
コンポーネントの呼び出しにはなるべくプリミティブを渡すという趣旨の話で、props で渡す情報はなるべく知識を必要としない方が良いということですね。
ただこの辺はコンポーネントの抽象度によるかもしれません。

多くの useState を使用する代わりに useReducer の使用を検討してください

長い期間で少しずつ機能を追加しているといつの間にか useState 地獄に陥っている場合があるので、良きところで useReducer の採用を検討するといいかもしれません。

パフォーマンスのヒント

パフォーマンスは恥ずかしながらなんとなくでやっている部分が否めないので読んでいて胃が痛かったです……

状態を使用されている場所にできるだけ近づけると、コードが非常に読みやすくなるだけでなく、アプリが高速になります

状態変化が散らばっているコードは非常に追いにくいので心がけたいです。

状態の参照と更新機能を分離することでコンテキストを最適化できます

これは最近も React Docs Beta で書かれていたりしているので記憶に新しいです。

beta.reactjs.org

テストの原則

フロントエンドの場合、100%のコードカバレッジは必要ありません。おそらく約70%で十分です

大事ではありますがテストの精度を求めることが目的になってしまうのは業務だと苦しいかもしれません。

Jest、React testing library、Cypress や Mock service worker を使うのが好きです

Cypress は弊社でも利用しています。

まとめ

今回は簡単なピックアップと所感を一言といった簡単な形式でお送りしたのですが、原文はもっと参考になる情報ばかりなので是非ご一読ください!

github.com

おわりに

vivit では自分なりの philosophy を持つあなたの応募もお待ちしております。

www.wantedly.com