― 宣言的UIがエンジニアに突きつけた現実 ―
※ChatGPTを使用して記事を作成しています。
Jetpack Compose を触り始めたとき、多くのエンジニアがこう感じます。
「XMLよりコード量は減ったはずなのに、なぜか頭が疲れる」
「昔より“設計”を考えさせられている気がする」
これは気のせいではありません。
Compose は、意図的に「考えること」を増やすUIフレームワークだからです。
この記事では、
- なぜ XML 時代より思考量が増えたのか
- それが「悪い変化」なのか
- どう向き合うと楽になるのか
を整理していきます。
XML 時代は「考えなくてよかった」のか？
まず前提として、XML + View 時代を振り返ってみます。
XML が隠してくれていたもの
XML レイアウトでは、私たちは多くのことを考えずに済んでいました。
- View の生成タイミング
- 状態がいつ View に反映されるか
- 画面回転時の再生成
- setText / setVisibility の呼び忘れ
これらは、
- Android フレームワーク
- ライフサイクル
- 暗黙の View 状態
にかなりの部分を委ねていました。
極端に言えば、
「とりあえず setText すれば画面は変わる」
という世界です。
Compose が壊した「暗黙の前提」
Compose に移行すると、次のような疑問に必ずぶつかります。
- なぜ値を変えても UI が更新されない？
- remember はいつ必要？
- 再コンポーズって何が起きてるの？
- 状態はどこに持つのが正解？
これは Compose が“暗黙の魔法”をほぼすべて捨てた結果です。
宣言的UIの本質：「UIは状態の結果である」
Compose の大原則は、非常にシンプルです。
UI = State の写像
つまり、
- UI を直接操作する
- View に命令を送る
という発想が存在しません。
代わりに問われるのは、
- この UI は どんな状態から描かれているか
- その状態は どこで管理されるべきか
- 状態が変わったとき、UI は どう再計算されるか
です。
ここで初めて、エンジニアは気づきます。
「あれ、UIってこんなに設計が必要だったっけ？」
Compose は「責任」をエンジニアに返してきた
Compose が増やしたのは、処理量ではありません。
責任の所在を明確にしただけです。
XML 時代
- 状態の保存 → なんとなくフレームワーク
- 再描画 → View が勝手にやってくれる
- UI 更新 → setXXX すればOK
Compose 時代
- 状態の保存 → 自分で決める
- 再描画 → 再コンポーズとして明示される
- UI 更新 → State を更新するしかない
Compose はこう言っています。
「UI の整合性は、あなたが設計してください」
「考えることが増えた」と感じる正体
多くの場合、違和感の正体はこれです。
❌ 以前は考えなくて済んだことを、考えさせられている
- 状態の単一責任
- UI とロジックの境界
- 再利用可能なコンポーネント設計
⭕ 実は昔から存在していた問題
- setText し忘れて表示がズレる
- 画面回転で状態が消える
- if 文だらけの View 操作
Compose はそれらを隠さず、真正面から見せてくるだけです。
Compose は「難しくなった」のではない
ここが一番誤解されがちな点です。
Compose は、
- 複雑になった
- 上級者向けになった
のではありません。
「雑に書けなくなった」だけです。
雑な状態管理
雑な責務分離
雑な UI 操作
これらは XML 時代でも問題でしたが、
Compose では 即座に破綻として表面化します。
楽になる考え方：UIを“計算結果”として扱う
Compose を楽にする一番のコツはこれです。
UI を「操作対象」ではなく
「状態から計算される結果」として見る
- Text を変更する → ❌
- textState を変更する → ⭕
- 表示を切り替える → ❌
- isVisibleState を変える → ⭕
この視点に切り替わった瞬間、
remember / State hoisting / 再コンポーズ が一本の線でつながります。
まとめ：Compose が増やしたのは「思考」ではなく「誠実さ」
Compose は、エンジニアにこう迫っています。
「UIの責任を、ちゃんと引き受けませんか？」
それは確かに、楽ではありません。
でもその代わりに、
- 予測可能な UI
- テストしやすい構造
- 壊れにくい設計
を手に入れられます。
「考えることが増えた」と感じたなら、
それは 一段レベルが上がったサインかもしれません。
