はじめに
Jetpack Compose で開発していると、
「一箇所直しただけなのに、別の場所でエラーが出始める」
という状況に陥ることがあります。
これまでの記事では、
-
状態更新と UI の境界
-
state.copy という手癖
といった 具体的な要因 を振り返ってきました。
今回は少し視点を変えて、
エラーが連鎖し始める“もう一段手前”で、何がズレているのか
という話を整理します。
よくある状況
エラーが連鎖し始めるとき、多くの場合、
-
どこを直せば良いのか分からなくなる
-
修正のたびに影響範囲が広がる
-
「たぶんここが原因だろう」という修正が増える
といった状態になりがちです。
この段階では、
コードそのものよりも 開発の進め方 に違和感が出始めています。
起きているズレ
振り返ってみると、
エラーが連鎖していたときは、次のような状態でした。
-
状態の正解がコード上に一箇所に存在しない
-
UI・ViewModel・状態クラスの責務が少しずつ重なっている
-
「今は動いているから大丈夫」という判断が増えている
どれも致命的ではありません。
ただ、これらが重なってくると、
修正のたびに不安が増えるフェーズ に入ります。
なぜ気づきにくいのか
このズレが厄介なのは、
-
build は通る
-
UI も一応動く
-
小さな修正はすぐ反映される
という状態が続くことです。
そのため、
「Compose はこういうものだろう」
「自分の理解が追いついていないだけかもしれない」
と判断してしまい、
構造的なズレを見逃しやすくなります。
後から分かったこと
後になって分かったのは、
エラーが連鎖し始めた時点で、
すでに“状態の責務”が曖昧になっていた ということでした。
-
どこが状態の入口なのか
-
どこが唯一の更新点なのか
-
UI がどこまで知ってよいのか
これらが曖昧になると、
エラーは「突然」ではなく
必然として連鎖します。
今はどう考えているか
今は、エラーそのものよりも、
-
状態の正解はどこにあるか
-
更新ルールは一箇所に集まっているか
-
UI は判断を持ちすぎていないか
といった点を、
エラーが出る前から確認するよう になりました。
これだけでも、
「連鎖しそうな空気」を早めに察知できるようになります。
おわりに
Jetpack Compose のエラーは、
突然発生しているように見えて、
実際には ** 少し前から兆候が出ている ** ことが多いです。
もし、
-
修正するたびに不安が増えている
-
影響範囲が直感的に読めなくなってきた
と感じている場合は、
コードそのものではなく、
状態の責務や更新の置き場所を
一度立ち止まって見直してみるとよいかもしれません。