状態管理のライブラリを使用している場合、基本的にコードの記述量は増えるので、PRを分けたほうが好ましい。今回は普段意識しているPRの分け方を書いてみた。
1.State設計とViewの実装で切り分ける
これは最もベーシックな切り方で、以下のような分け方になる。
- 主なロジックが入るStateの設計でまず1PR
- 一般的にはStateの写像となるViewで1PR
2.Stateで切り分ける
Stateに複数のドメインの状態が入っている場合は、PRをわけてもいい。例としては、以下のようなものである。
- 例. ブログポストの更新画面で、更新用のステートと既存データ取得用のステートがあれば、それぞれ別PRにする、など。
3.スタイルで切り分ける
Viewの実装が小さくない場合、スタイルの当て込みは別PRにする。
4.複雑なロジックで切り分ける
機能的に複雑なロジックが入る場合は、State、Viewとは別にPRを出す。
- 例1. ドメイン上複雑にならざるを得ないツリー構造のオブジェクトを生成、更新するなど
- 例2. Virtual DOMの管理下を外れて、DOMをぐいぐい操作する必要がある場合(canvas やグラフ)など
その他
テストと実装を切り分ける、などもありうるが、基本的にはテストと実装はセットで実装したほうが品質は上がるかと考える。書き忘れや、工数面でやむを得ない事情を除いて基本的には同じPRで実装したい(テストのせいでPRが肥大化しているなら、粒度から考え直す)。
あとはPRの責務と関係のない箇所は別PRにするなど、一般的なベストプラクティスに従う。
まとめ
以上、プルリクエスト粒度の考え方についてまとめてみた。
参考になれば幸いです。