はじめに

Jetpack Compose で開発を続けていると、
一箇所を修正しただけなのに、

別の画面でエラーが出る

・型エラーが連鎖的に発生する

・状態を触っただけで UI が不安定になる

といった状況に遭遇することがあります。

特に、ある修正をきっかけに
「今まで通っていたコードが突然大量に赤くなる」
ような経験をした方には、心当たりがある内容だと思います。

本記事では、こうした現象が起きやすいケースを
「状態更新と UI の責務の切り分け」
という観点で整理します。

1.状態更新が UI に滲み出ると何が起きるか

Compose では、状態（State）と UI が密接に結びついています。

そのため、

UI 内で状態加工を行う

nullable をそのまま Composable に流す

更新ロジックが画面側に散らばる

といった書き方をすると、
エラーが局所化せず、連鎖的に広がることがあります。

連鎖しやすいコードには、いくつか共通点があります。

例えば、次のように onChange の中で
状態更新ロジックを直接書いてしまうケースです。

onChange = {
    state = state.copy(
        value = it,
        error = validate(it)
    )
}

UI が
「どのように状態が更新されるか」
を知ってしまっている点が、後からの修正を難しくします。

このような書き方は一見シンプルですが、
「どこまでが UI の責務なのか」
が曖昧になりやすく、
変更時に影響範囲が読めなくなります。

どこで、どの単位で状態を更新するのかが定まっていないと、
変更時に影響範囲が予測しづらくなります。

UI が更新手順まで把握していると、
状態構造の変更が画面全体に波及しやすくなります。

これらは一見問題なく動きそうに見えますが、
変更耐性が低く、後からの修正に弱い形になりがちです。

解決策は、特別なテクニックではありません。

状態更新は 1 箇所に集める

UI は「表示」と「イベント通知」に専念させる

nullable は境界で吸収する

このように役割の境界をはっきりさせるだけで、
エラーの影響範囲は驚くほど小さくなります。

Compose のエラーが連鎖するときは、
コードの細部よりも責務の分け方を見直す方が
解決が早いケースが多くあります。

状態更新と UI の境界を一段整理するだけでも、
次に同じ種類のエラーに遭遇する可能性は大きく下がります。

もしエラーが連鎖し始めたら、次の点を確認してみてください。