Reactのコードデザインパターンとか設計原則とか
enpolioReactのリーダブルコードとか設計原則みたいなエントリをまとめていく
いずれ自分でもエントリ書く！
コードパターンに関して、銀の弾丸はどうやらなさそう
enpolio
- render内イベント命令系は切り離す
イベント命令はすべて切り離す原則は良くないような気がする。このQiitaくらい短くて分かりやすい関数なら切り離す必要なさそう。イベント命令をすべて切り離すのではなく、 切り出すことでコードが（切り出す前に比べて）読みやすくなる・理解しやすくなる（ので切り出すことに意味がある） 場合に切り出すのが良い。
- useEffectは複数書いても良い
これは必ずしもそうとは限らない気がする。effectの依存関係・実行順序がある場合は、一つにまとめる必要がある。
enpolio
- functionではなくアロー関数を使う
- 型は基本的にVFCを使う
- FCもしくはFCをちゃんと書くのは大事（Reactコンポーネントだとわかるので）
- VFCとFCの違いがあまり分かってないからちゃんと調べよう
- returnは省略可能でも省略しない
- propsはdestructureした方が良いかも
- 個人的には何がpropsとして渡されているか一目瞭然なので冗長でも書いた方が良いと思う
enpolio
- PresentationalConponent / ContainerContainerの区分が大事
- PresentationalComponentは完全にステートレスなコンポーネント
- ビジネスロジックは存在しない
-
returnを用いずprops => (...)にする事によってHooks APIの介入を阻む- なるほど、賢い
- ローカル変数とか軽微なstateとかもpropsで渡すのは逆に分かりにくい気がする
- 完全なUIコンポーネントなのでstoryとか書きやすそう
- ContainerComponentはステートフルなコンポーネント
- ここで依存の注入を行う
- Presentational / Containerの区分は重要だと思う
- Presentational : APIなど外部とのやり取りが発生するコンポーネント、みたいな認識が良さそう
- Container : （他のコンポーネントが持っていない）スタイルの情報を一つでも持っているようなコンポーネント、みたいな認識がしっくりくる
enpolio
Do not use
import type ... from
- Google先生は
import typeする必要ないと仰っている-
importと同じなので、わざわざそんなところに気を割く必要無し
-
- でも
import typeすると「このオブジェクトは型なんだな」とすぐに分かるので書いても良い気が... - SWRとか使うとimport type使わなきゃいけないっぽい...？（要確認）
enpolio
- コンポーネントの分類は以下の３つ
- APIとの接続
- View（Presentational Component）
- 状態管理（Container Component）
- Containerを作りたくなるが、以下のルールが考えられる
- Organisms単位で作成する
- Domain単位で作成する
enpolio
stateはプリミティブにする
これは微妙かも。
この例みたいにname, firstName, familyNameだったら一つのまとまりとして扱う方が良い。
stateを無駄に増やさないことでデバッグが簡単になるし、stateの更新・コンポーネントのレンダリングタイミングを制御できるようになる
「モデル」に基づいてstateを作って行くのが良さそう。
業務上nameが他と比べて特別に使うことがあるなら分けたほうが良い。モデル上３つが並列ならまとめて良さそう。
enpolio
一つの UI コンポーネントに必要になるセレクター名称はせいぜい片手で数えられる程度で、両手で数えるぐらいの量になってきた時はコンポーネントの粒度を見直します。これが大抵、よいリファクタに繋がったりします。
なるほど！これは良い設計原則な気がする
enpolio
- 重複した状態の宣言は避ける
確かにこんなことよくあるかも。気をつける。
enpolio
Booleanを使わずにString Literalで表現するパターン
複数のBooleanが存在しそれらが絡み合う場合はString Literalの方が良さそう
単純なon/offだけならBooleanの方がシンプルでわかりやすいと思う
enpolio
ReactはUIライブラリのためのものであるのだから、UI管理以外の目的でuseEffectを使うべきではない
enpolio
useMemoの使い時
enpolio
State ReducerはReactにおけるDIパターンの１つ（？）
enpolio
Propsの型で条件分岐させる例
そもそも型で条件分岐させるならコンポーネントを分けても良い気がしないでもない、、、
enpolio
不要なレンダリングを防ぐための３パターン
- リフトダウンパターン
- リフトアップパターン
- メモ化
普段普通にやっているけど改めて体系的に抑え直す
enpolioディレクトリ設計の話
ディレクトリ構成は大きく分けると以下の２つに分けられる
- Layer型（Atomic Designなど）
- Feature型（Features Directoryなど）
この２つのどちらかではなく、両方の組み合わせみたいなことが良いのでは？
PagesにはFeature型を適用し、ComponentsにはLayer型を適用する
enpoliouseEffectは避難ハッチ