はじめに

Jetpack ComposeでUIを組んでいると、stateの数や置き場、責務の切り分けに意識が向きがちです。
以前の自分もそうでしたが、ある時から
「この画面は何を前提に描画されているのか」
を先に考えるようになりました。
コードを見る前にその視点を持つだけで、state管理に対する見え方が少し変わった気がしています。

以前は何を見ていなかったか

以前は、state管理に違和感を覚えると、まず
「数が多すぎるのではないか」
「持たせる場所が分散しすぎているのではないか」
と考えていました。

どのComposableがどのstateを参照しているか、
ViewModelの責務は適切か、といった点を一つずつ確認する。
それ自体は間違っていないのですが、その時の自分は、
「この画面は何を前提に描画されているのか」
という視点を、ほとんど意識していなかったと思います。

今は何を先に考えているか

今は、stateの数や配置を見る前に、まず一つだけ確認するようにしています。
それは、
「この画面は、何を前提に描画されているのか」 を自分の言葉で説明できるかどうか
です。

一覧なのか、詳細なのか、入力途中なのか、確定状態なのか。
画面の役割を一度言葉にしてみて、その説明に合わないstateが混ざっていないかを見る。
そうしてからコードを見ると、どこに違和感があるのかが、以前よりも掴みやすくなりました。

コードを見る前に、自分に投げている問い

今は、state管理に違和感を覚えたとき、いきなりコードを追わずに、
いくつか自分に問いを投げるようにしています。

この画面は、今どんな状態を前提に描画されているのか
（一覧なのか、詳細なのか、入力途中なのか）
その前提は、1つの説明で言い切れるか
それとも、複数の前提が混ざっていないか
表示の判断に使っている情報は、どこから来ているのか
前提としているstateが、画面を跨いでズレていないか
この画面が更新されたとき、
前提は変わるのか、変わらないのか

どれも特別な問いではありません。
ただ、これらを一度頭の中で整理してからコードを見るようになってから、
state管理の違和感に気づくまでの時間が、少し短くなりました。

おわりに

この考え方でstate管理の問題がすべて解決する、というつもりはありません。
実際、今でも迷うことはありますし、あとから「やっぱり違ったな」と思うこともあります。

ただ、違和感を覚えたときに、いきなり実装や構造を直そうとするのではなく、
「この画面は何を前提に描画されているのか」を一度立ち止まって考える。

最近は、その問いを自分の言葉で説明できるかどうかを、
state管理を見る前に確認するようにしています。