前提
この記事は私個人が今までの経験や調べてきた中で考えていることをまとめた内容になります。
あくまでも私個人の視点で、特定のプロジェクトや組織に当てはまるものではない点をご認識ください。
useEffectの乱用
たまに見るのがuseEffectが数珠繋ぎになっていつ発火をするのかわからないものがありそうです。
個人的な認識としてはuseEffectは積極的に使うものではなく、どうしても使用をしないといけない時に使用をするという感覚で実装をしたほうがおかしなことにならないのかなと考えています。
linter, formatterを使っていない
チームで開発をするときにコードの統一感はとても大事だと思っています。
これらはformatterやlinterに委ねてしまったほうが楽だと思っています。
formatterは最悪はなくてもいいかなと思っているのですが、linterは必ず入れて出来るだけ最初の厳しめに設定をし、不必要な設定を外していくのがいいかなと思っています。
グローバルステート地獄
なんでもかんでもグローバルステートに保存をするやり方です。
個人的には使わなくていいのであればグローバルステート自体を使わない方針で実装をするのと、グローバルステートを増やすと、途端にコードを読み解くハードルが上がるように感じるので、本当にそれが必要なものなのかは考えて実装がしたいです。
memo化のやりすぎ
これは人によって考え方が異なる点かなとは思っているのと、本当に私の好み的な話なのですが、私は最初からmemo化をしません。
なんでもmemo化をするとしていないプロジェクトと比較をして、コード量や行数が増えてコードがとても見づらくなります。
パフォーマンスをよくする意図があって使うのはわかるのですが、まずはそのプロダクトは「本当にパフォーマンスを高く求めるプロダクトなのか」 や費用対効果的なところや、それが後の負債につながらないのかなどはよく考えて使ったほうがいいと思っています。
そういえばreact19からはmemo化をする機会は少なくなりそうです（歓喜）
以下参照:
atomic designを使ったコンポーネント設計
私自身このやり方で実装をしたこともあるのですが、うまく実装をできた経験がありません。
人によって atoms, molecules, organismsなどの中でどこに配置をするのかなどを考えたり探す時に大変で今からこの設計パターンでは実装はしないと思っています。
個人的には下記の単位でどこにどのコンポーネントがあるのか分かりやすいようにするといいと思っています。
- ページに依存するもの
- 機能に依存するもの
- 複数画面で使われるもの
- プロジェクトのinput, select, cardなどのベースコンポーネント
サーバーから不必要な値を返される
REST APIでよく見るのですが、jsonのレスポンスである特定のデータベースやそれに紐づく情報をまとめて返すような神apiのようなものをたまに見ます。
このような神apiは何にでも使える便利なapiにも見えるのですが、実際に扱うときに不必要なデータを返されてフロント視点的には認知負荷が大きいapiになります。
出来るだけ不必要な情報を返さないように設計をしたいです。
最後に
実装時の辛かった過去を思い出しながら書いてみました。
アプリケーション開発の手法に正解はないと思っているのですが、自分自身がより良い選択ができるように日々研鑽を怠らないようにしたいと思います。
Discussion