#iOS | #Android Fashion News

見通しが悪くなった UiState を、責務ごとに整理する7つの方法

🧑🏻‍💻 1. Loading / Error / Success が混ざっているなら sealed interface にする

まず、ありがちなパターンです。

変更前:

data class UiState(
    val isLoading: Boolean,
    val error: String?,
    val items: List<Item>
)

- isLoading、error、items の組み合わせで画面の状態を表しています。
- しかし、これでは「Loading なのに items が入っている」「Error なのに isLoading が true」といった、あり得ない状態も作れてしまいます。

変更後:

sealed interface UiState {
    data object Loading : UiState
    data class Error(val message: String) : UiState
    data class Success(val items: List<Item>) : UiState
}

- Loading、Error、Success を、そのまま画面の状態として表現します。
- 状態を Boolean や nullable なプロパティの組み合わせで表現する必要がなくなります。

🧑🏻‍💻 2. フィールドが増えすぎたら、Sub-Stateにまとめる

UiState にプロパティを追加していった結果、何がどこに関係しているのか分からなくなることがあります。

変更前:

data class UiState(
    val title: String,
    val query: String,
    val items: List<Item>,
    val selectedCategory: Category?
)

変更後:

data class UiState(
    val header: HeaderState,
    val filter: FilterState,
    val list: ListState
)

data class HeaderState(
    val title: String
)

data class FilterState(
    val query: String,
    val category: Category?
)

data class ListState(
    val items: List<Item>
)

-「ヘッダー」「検索・フィルター」「リスト」という画面上のまとまりで整理します。
- UiState の中身を見ただけで、どの状態がどの役割なのか分かるようになります。

🧑🏻‍💻 3. UIだけで使う状態はComposableに閉じ込める

すべての状態をViewModelの UiState に入れる必要はありません。

変更前:

data class UiState(
    val items: List<Item>,
    val isExpanded: Boolean
)

変更後:

data class UiState(
    val items: List<Item>
)

@Composable
fun Screen(state: UiState) {
    var isExpanded by rememberSaveable {
        mutableStateOf(false)
    }
}

- isExpanded が画面の一時的な表示状態にすぎないなら、ViewModelに持たせる必要はありません。
- remember / rememberSaveable に移すことで、UiState をシンプルにできます。

例えば次のようなものです。

・一時的な展開状態
・アニメーションの状態
・Tooltipの表示状態
・フォーカス状態
・スクロール位置

ただし、スクロール位置などを画面復元やビジネスロジック上の理由で ViewModel 側に保持する必要がある場合は例外です。

🧑🏻‍💻 4. 計算できる値はStateとして持たない

「元のStateから計算できる値」まで UiState に入れてしまうと、Stateがどんどん増えていきます。

変更前:

data class UiState(
    val items: List<Item>,
    val filteredItems: List<Item>,
    val isEmpty: Boolean
)

変更後:

data class UiState(
    val items: List<Item>,
    val query: String
)

val filteredItems =
    state.items.filter { it.name.contains(state.query) }

val isEmpty = filteredItems.isEmpty()

- filteredItems は items と query から計算できます。
- isEmpty も filteredItems から計算できます。
- つまり、わざわざStateとして保存する必要がありません。
- ViewModelで StateFlow を組み合わせるなら combine や map、Compose 内で Compose State から値を導出するなら derivedStateOf などを使います。

🧑🏻‍💻 5. ViewModelまで巨大になったら、ViewModelを分ける

UiState が巨大になった原因が、そもそもViewModelがいろいろな責務を持ちすぎているケースもあります。

変更前:

class MainViewModel : ViewModel() {
    val headerState = ...
    val searchState = ...
    val contentState = ...
}

Stateを分けていても、ViewModel自体がすべてを管理しています。

変更後:

class HeaderViewModel : ViewModel() {
    val state = ...
}

class ContentViewModel : ViewModel() {
    val state = ...
}

@Composable
fun MainScreen(
    header: HeaderViewModel,
    content: ContentViewModel
) {
    HeaderSection(header.state)
    ContentSection(content.state)
}

- 「State を分割する」だけではなく、責務そのものを分けるという考え方です。
- ただし、Composable ごとに ViewModel を作る、という意味ではありません。
- 独立した責務やライフサイクルがある場合に検討します。

🧑🏻‍💻 6. 大量のデータを UiState に詰め込まない

数千件、数万件のデータをそのまま UiState に持たせるケースでは、そもそもStateの持ち方を見直します。

変更前:

data class UiState(
    val items: List<Item>
)

val uiState = repository.loadAllItems()

変更後:

data class UiState(
    val query: String
)
val items =
    repository.items()
        .cachedIn(viewModelScope)

- 検索条件などの画面状態と、大量のデータを分離します。
- Paging が適しているケースでは、Paging を利用して必要なデータを段階的に扱います。

🧑🏻‍💻 7. 1つの巨大な StateFlow に全部詰め込まない

すべての状態を1つの UiState にまとめることが、かえって分かりにくくなるケースもあります。

変更前:

data class UiState(
    val header: HeaderState,
    val search: SearchState,
    val content: ContentState
)

val uiState: StateFlow<UiState> = ...

変更後:

val headerState: StateFlow<HeaderState> = ...
val searchState: StateFlow<SearchState> = ...
val contentState: StateFlow<ContentState> = ...

@Composable
fun Screen(viewModel: MainViewModel) {
    Header(viewModel.headerState)
    Search(viewModel.searchState)
    Content(viewModel.contentState)
}

- 各 State が本当に独立しているなら、無理に1つへまとめる必要はありません。
- それぞれの UI が必要な State だけを受け取る形にできます。
- ただし、何でも StateFlow に分ければいいわけではありません。

🧑🏻‍💻 まとめ - どう整理するか

巨大な UiState
      │
      ├─ Loading / Error / Success が混在
      │       → sealed interface
      │
      ├─ フィールドが増えすぎた
      │       → Sub-State
      │
      ├─ UIだけで使う状態
      │       → remember / rememberSaveable
      │
      ├─ 計算すれば求められる値
      │       → Derived State
      │
      ├─ ViewModelの責務が多すぎる
      │       → ViewModelを分割
      │
      ├─ 大量のデータを保持している
      │       → Pagingなどを検討
      │
      └─ 独立した状態が混在している
              → StateFlowを分割

重要なのは、「UiStateの行数を減らす」ことではありません。

まず、今 UiState に入っているものを見て、

これは本当にStateなのか？
        ↓
UIだけのStateでは？
        ↓
計算できる値では？
        ↓
別の責務では？
        ↓
大量データでは？

と整理していくことです。

つまり、巨大な UiState は、Stateの責務を見直すきっかけと考えると分かりやすいです。

注意点:

- UiState が大きいこと自体が悪いわけではありません。
- StateFlow を細かく分けすぎると、今度は State 同士の関係が分かりにくくなります。
- sealed interface は、Loading / Error / Successのように本当に相互排他的な状態に使います。
- rememberSaveable に移すか ViewModel に残すかは、画面再生成やプロセス終了後にも復元する必要があるかも判断材料になります。
- Pagingも「List が大きいから必ず使う」というものではありません。

🤔 参考

Android Architecture Is Moving from Event-Driven UI to State-Driven UI | by chanzmao | Aug, 2026 | ProAndroidDev

Google’s official Android guidance was updated on May 18, 2026 — and it now expl

proandroiddev.com

Taming the Monolithic UiState in Jetpack Compose | Chanzmao ʕ•ᴥ•ʔ Bear Blog

Practical Strategies for Breaking Down Complex UI State Without Losing Clarity1

chanzmao.benigumo.com