Open34
フロントエンドの設計についての参考資料
フロントエンドにおけるドメインと設計について
原則まとめ
いかに変更容易性を確保するかが重要
awesome
内部品質と開発速度について
設計の学び方
日本語訳
react
ADR
マイクロフロントエンド
SOLID原則
デザインパターン
- デザインパターン
- レンダリングパターン
Reduxのベストプラクティス
- 必須
- Stateはimmutableにする
- Reducerに副作用がないようにする
- Promise、Symbol、Map、Set、function、classインスタンスをStateやActionに持たないようにする
- アプリケーションにStoreは1つだけにする
- 強く推奨
- Redux Toolkitを使う
- immutableな更新にImmerを使う
- Featureごとにディレクトリを分けてコロケーションする
- 可能な限りReducerに新しいStateを作るためのロジックを集約する
- ReducerはStateの形状に責務を持つ
- 保有するデータに沿ってSliceを命名する
- コンポーネントではなくデータ種別に基づいてStateを構成する
- Reducerをステートマシーンとして扱う
- 複雑なデータを正規化する
- 可能な限りStateは小さくして、Stateから必要に応じて値を導き出す
- Actionはセッターとして扱わずに起きたことを記述するものとして扱う
- Action名はそのActionで何が起こるかを説明するような意味のある命名にする
- 同じActionに複数のReducerが反応することを許容する
- 連続して多くのActionをdispatchしない
- ReduxのStateに置くものとそうでないものを分別する
- react-reduxのhookのAPIを使う
- Storeのデータを読み取るのにより多くのComponentとReduxを繋ぐ
-
connect
に渡すmapDispatch
の引数はショートハンドのオブジェクトで -
useSelector
で一度に大きいオブジェクトを取得するのではなく、なるべく小さい値を取得するようにする。複数に分けて良い - 静的型付けを利用する
- Redux Devtoolsをデバッグに利用する
- プレーンなオブジェクトをStateに使う
store設計について
堅牢性と変更容易性について
フレームワークに依存しない
凝集度とか
フロントエンドにビジネスロジックがあるか?
コメントのInteraction Domainという考え方が良さそう。
viewの技術スタックが変更されても変わらない抽象がそれにあたる。
https://zenn.dev/link/comments/e21b528ddebb7e で言及されていることに共通する部分がありそう
若干古め? react
「クリーンアーキテクチャー」に関して
package by feature や関心をどう分けるかについて
Next.jsにできるだけ依存しない構成について