Reactのコードデザインパターンとか設計原則とか

enpolio 2022/02/21に更新

Reactのリーダブルコードとか設計原則みたいなエントリをまとめていく

いずれ自分でもエントリ書く！

コードパターンに関して、銀の弾丸はどうやらなさそう

enpolio 2022/04/01に更新

render内イベント命令系は切り離す

イベント命令はすべて切り離す原則は良くないような気がする。このQiitaくらい短くて分かりやすい関数なら切り離す必要なさそう。イベント命令をすべて切り離すのではなく、 切り出すことでコードが（切り出す前に比べて）読みやすくなる・理解しやすくなる（ので切り出すことに意味がある） 場合に切り出すのが良い。

useEffectは複数書いても良い

これは必ずしもそうとは限らない気がする。effectの依存関係・実行順序がある場合は、一つにまとめる必要がある。

enpolio 2023/06/13に更新

functionではなくアロー関数を使う
型は基本的にVFCを使う
- FCもしくはFCをちゃんと書くのは大事（Reactコンポーネントだとわかるので）
- VFCとFCの違いがあまり分かってないからちゃんと調べよう
returnは省略可能でも省略しない
propsはdestructureした方が良いかも
- 個人的には何がpropsとして渡されているか一目瞭然なので冗長でも書いた方が良いと思う

enpolio 2022/04/01に更新

PresentationalConponent / ContainerContainerの区分が大事
PresentationalComponentは完全にステートレスなコンポーネント
- ビジネスロジックは存在しない
- returnを用いずprops => (...)にする事によってHooks APIの介入を阻む
  - なるほど、賢い
- ローカル変数とか軽微なstateとかもpropsで渡すのは逆に分かりにくい気がする
- 完全なUIコンポーネントなのでstoryとか書きやすそう
ContainerComponentはステートフルなコンポーネント
- ここで依存の注入を行う
Presentational / Containerの区分は重要だと思う
- Presentational : APIなど外部とのやり取りが発生するコンポーネント、みたいな認識が良さそう
- Container : （他のコンポーネントが持っていない）スタイルの情報を一つでも持っているようなコンポーネント、みたいな認識がしっくりくる

enpolio 2022/04/01に更新

Do not use import type ... from

Google先生はimport typeする必要ないと仰っている
- importと同じなので、わざわざそんなところに気を割く必要無し
でもimport typeすると「このオブジェクトは型なんだな」とすぐに分かるので書いても良い気が...
SWRとか使うとimport type使わなきゃいけないっぽい...？（要確認）

enpolio 2022/04/01に更新

コンポーネントの分類は以下の３つ
- APIとの接続
- View（Presentational Component）
- 状態管理（Container Component）
Containerを作りたくなるが、以下のルールが考えられる
- Organisms単位で作成する
- Domain単位で作成する

enpolio 2022/04/01に更新

stateはプリミティブにする

これは微妙かも。
この例みたいにname, firstName, familyNameだったら一つのまとまりとして扱う方が良い。
stateを無駄に増やさないことでデバッグが簡単になるし、stateの更新・コンポーネントのレンダリングタイミングを制御できるようになる
「モデル」に基づいてstateを作って行くのが良さそう。
業務上nameが他と比べて特別に使うことがあるなら分けたほうが良い。モデル上３つが並列ならまとめて良さそう。