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にできるだけ依存しない構成について