derivedStateOfを使うべきところとderivedStateOfを使わなくていいところ


Composeのリファレンスの「副作用」のページの中で「derivedStateOf」について書かれています。
https://developer.android.com/jetpack/compose/side-effects?hl=ja#derivedstateof

そんなに長くない文章なのでここで一度上記のリファレンスを軽く読んでみてほしいです。

* * * * * * *

読みましたか？

derivedStateOfの使い方、理解できたでしょうか？

:::note info
2024/04/28 追記

いつの間にかリファレンスのderivedStateOfの項目が改善されていますね。
この記事を書いた当時よりかなり理解しやすくなっています。
:::

私はComposeを始めたとき最初にこのリファレンスに目を通したのだけど、正直このdeviredStateOfの項目は全く意味がわからなかった。

いや、意味はわかるんですよ。
難しいことが書いてあるものの、ゆっくり時間をかけて読めば書いてあることの意味はわかる。

でもかなり多くの疑問が残った。

リコンポジションが発生しなくなるってどういう理屈で？
どの部分がリコンポーズされなくてどこがリコンポーズされるの？
なんでこの書き方になるの？ rememberのキーいるの？
最後の文章もよくわかんねえ。結局どういうときにderivedStateOfを使えばいいのかわかんねえよ。

というかこれ今見ても若干ややこしいわ。
なんで最初の例でいきなりこれを出してきたんだよ。

というわけで今回はderivedStateOfの使い方について深堀りしていく。

# リコンポジション

derivedStateOfがわからないのは、実はderivedStateOfそのものがわからないというよりはリコンポジションの正確な動作をわかってないことが原因だったりする。

なのでまずはリコンポジションについておさらいしていく。

300秒カウントダウンするComposableを作ってみる。
```kotlin
@Composable
fun Timer() {
   var time by remember { mutableStateOf(300) }

   LaunchedEffect(Unit) {
      while (true) {
         delay(1000L)
         time--
      }
   }

   Text("$time")
}
```
`@Composable` が付与された関数は―― 「`@Composable` が付与された関数」と毎回言うのは長すぎるので、我々は `@Composable` が付与された関数のことを *"Composable"* と呼んでいる。 ―― ComposableはStateの値にアクセスするときに『ワタシはこのStateを使います』という旨をComposeフレームワークに伝えている。 
そしてそのStateが変更されるとき、フレームワークはComposableを再実行してUIを新しい状態で再構築する。これが *リコンポジション* 。

上記のコードで言うとComposable `Timer` は `mutableStateOf(300)` で生成したStateにbyを使ってアクセスしている。（もちろんbyを使わず直接 `.value` と書いても同じことが起こる）
LaunchedEffect内の `time--` によって1秒ごとにStateが変更されるので、そのたびにこのComposable `Timer` はリコンポーズされる。

### Restartable

実はリコンポジションは毎回UI全体を再構築しているわけではない。
変更されたStateを使っているComposableから再実行される。
```diff_kotlin
  // リコンポーズされない
+ @Composable
+ fun TimerScreen() {
+    Timer()
+ }
+
  // リコンポーズされる
  @Composable
  fun Timer() {
     var time by remember { mutableStateOf(300) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

     Text("$time")
  }
```
timeが変化したときにはいちいちTimerScreenから再実行せず、timeを使っているComposable `Timer` からいきなり再実行される。
この例のTimerのように、Composableが再実行の開始地点になれることを *Restartable* という。

### NonRestartableComposable

わざわざ説明したってことはそうじゃないComposableもあるワケで…
```diff_kotlin
  // リコンポーズされるようになる
  @Composable
  fun TimerScreen() {
     Timer()
  }

  // リコンポーズされる
  @Composable
+ @NonRestartableComposable
  fun Timer() {
     var time by remember { mutableStateOf(300) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

     Text("$time")
  }
```
`@NonRestartableComposable` を付与するとRestartableではなくなる。この場合最も近いRestartableな親Composableからリコンポーズされる。
他のComposableをひとつ呼ぶだけなどの完全に小さなComposableはいちいちRestartableにするコストの方が上回るので `@NonRestartableComposable` になっていたりする。

### inline fun

あとはComposableがinline funの場合にもRestartableではなくなる。
まあこれはComposeの仕様というよりはインライン展開された結果そうなってるだけなんだろうけど。
```diff_kotlin
  // リコンポーズされる
  @Composable
  fun TimerScreen() {
     Timer()
  }

  // リコンポーズされる
  @Composable
- fun Timer() {
+ inline fun Timer() {
     var time by remember { mutableStateOf(300) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

     Text("$time")
  }
```

### クロージャ

Kotlinのラムダ式はクロージャなので、こういうパターンもありうる。
Boxなどの内側からBoxの外側にあるStateを使う場合。
```diff_kotlin
  @Composable
  fun Timer() {
     // リコンポーズされない
     var time by remember { mutableStateOf(300) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

+    Box {
        // リコンポーズされる
        Text("$time")
+    }
  }
```
この場合もBoxの中身の部分がRestartableとなり、ここだけがリコンポーズされる。
まあ、外側（この例では `Timer` ）の方でも `time` を使ってたら当然そっちもリコンポーズされるので、この現象が起こるのは『Stateを外側に置いているが使うのはBoxの内側だけ』というような場合だ。

もちろん仮にBoxがinline funだとTimerからのリコンポジションになる。

:::note
inline funは引数で受け取った関数もインライン展開する。

```kotlin
// inline funじゃない場合
fun <R> run(block: () -> R): R {
   return block()
}

val i = run { 1 * 2 * 3 }
    ↓
val i = run(fun () { return 1 * 2 * 3 })
```
```kotlin
// inline funの場合
inline fun <R> run(block: () -> R): R {
   return block()
}

val i = run { 1 * 2 * 3 }
    ↓
val i = 1 * 2 * 3
```
inline funの場合だけラムダ式内にreturnを書けるのはこのため。
```kotlin
fun foo(): Int {
   run { return 42 }           // inline funじゃない場合
       ↓
   run(fun () { return 42 })   // ❌

   run { return 42 }           // inline funの場合
       ↓
   return 42                   // ⭕
}
```
:::

## スキップ

Composableは、リコンポーズされたときの引数が直前のコンポーズの引数と同じであれば、前回と同じ結果になるとみなして処理を *スキップ* する。

```diff_kotlin
  @Composable
  fun Timer() {
     var time by remember { mutableStateOf(300) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

-    Text("$time")
+    Row {
+       Minutes(time / 60)
+       Seconds(time % 60)
+    }
  }

  // 60秒に1回リコンポーズされる
+ @Composable
+ fun Minutes(m: Int) {
+    Text("$m")
+ }

  // 毎秒リコンポーズされる
+ @Composable
+ fun Seconds(s: Int) {
+    Text("$s")
+ }
```
`time / 60` は60秒に1回しか変化しないので変化していないときの `Minutes` のリコンポジションはスキップされるのですね。
サンプルコードのコメントに60秒に1回リコンポーズされると書いたけど、厳密に言うとリコンポジションは毎秒発生していて、その60回のうち59回がスキップされていると言うほうが正しいのだと思う。そのあたりの細かい話はよしなに読み取ってください。

ちなみに変化している引数があってもその引数を使っていなければリコンポジションはスキップできる。
```diff_kotlin
  @Composable
  fun TimerScreen() {
     Timer()
  }

  @Composable
  fun Timer() {
     var time by remember { mutableStateOf(300) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

     Row {
        Minutes(time / 60)
+       Separator(time)
        Seconds(time % 60)
     }
  }

  // 毎秒リコンポーズされる
+ @Composable
+ fun Separator(time: Int) {
+    Text(
+       if (time % 2 == 0) { ":" } else { " " }
+    )
+ }
```
```diff_kotlin
  // リコンポジションは発生しない（引数は毎秒変化しているのに）
  @Composable
  fun Separator(time: Int) {
-    Text(
-       if (time % 2 == 0) { ":" } else { " " }
-    )
+    Text(":")
  }
```
だからなんやねんと思うかもしれないけど、この仕様はComposableを引数として受け取るComposable（スロットAPIなどと呼ばれる）のときに意味がある。
```diff_kotlin
  @Composable
  fun TimerScreen() {
     Timer(
+       separator = { time ->
+          // 毎秒リコンポーズされる。timeを使わなければスキップされる
+          Text(
+             if (time % 2 == 0) { ":" } else { " " }
+          )
+       }
     )
  }

  @Composable
  fun Timer(
+    separator: @Composable (Int) -> Unit
  ) {
     var time by remember { mutableStateOf(300) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

     Row {
        Minutes(time / 60)
+       separator(time)
        Seconds(time % 60)
     }
  }
```

もっと複雑なパターン、例えばScope系になっても同様。 `this` という見えない引数にアクセスしなければ `this` が変化していてもスキップ可能。
```diff_kotlin
  @Composable
  fun TimerScreen() {
     Timer(
        separator = {
           // 毎秒リコンポーズされる（timeを使わなければされない）
+          Text(
+             if (time % 2 == 0) { ":" } else { " " }
+          )
        }
     )
  }

+ class SeparatorScope(val time: Int)

  @Composable
  fun Timer(
-    separator: @Composable (Int) -> Unit
+    separator: @Composable SeparatorScope.() -> Unit
  ) {
     var time by remember { mutableStateOf(300) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

     Row {
        Minutes(time / 60)
-       separator(time)
+       val scope = SeparatorScope(time)
+       scope.separator()
        Seconds(time % 60)
     }
  }
```

### Stable

ただしスキップされるのはComposableの引数がすべて *Stable* の場合だけ。
Stableでない引数が混じっているとスキップされず毎回リコンポーズされる。

「Stableである」とは、大きく分けると次の2つ。
1. Composableからアクセスできるプロパティの型がすべてStableであり、プロパティが変化しない
2. Composableからアクセスできるプロパティの型がすべてStableであり、プロパティが変化したときComposeフレームワークに通知する

Stableの中でも1の方を特に *Immutable* と呼んだりする。まあそのまんまなんだけど。

Stableでないインスタンスの有名な例として `List` がある。
ListはサブタイプとしてMutableListがあって変更可能なリストが渡される可能性があるというのはKotlinerならよく知っている問題ですね。
```diff_kotlin
  @Composable
  fun Timer(
     separator: @Composable SeparatorScope.() -> Unit
  ) {
     var time by remember { mutableStateOf(300) }
+    var lapTimes by remember { mutableStateOf(emptyList<Int>()) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

+    Column {
        Row {
           Minutes(time / 60)
           val scope = SeparatorScope(time)
           scope.separator()
           Seconds(time % 60)
        }
+
+       LapButton(
+          onClick = {
+             lapTimes += time
+          }
+       )
+    }
+
+    LapTimes(lapTimes)
  }

+ @Composable
+ fun LapTimes(lapTimes: List<Int>) {
+    // 毎秒リコンポーズされる
+    Column {
+       for (t in lapTimes) {
+          Text("$t")
+       }
+    }
+ }
```

kotlinx.collections.immutableの `ImmutableList` がImmutableとして扱われるのでComposeでは積極的に使っていこう。

https://github.com/Kotlin/kotlinx.collections.immutable

```diff_kotlin
  @Composable
  fun Timer(
     separator: @Composable SeparatorScope.() -> Unit
  ) {
     var time by remember { mutableStateOf(300) }
-    var lapTimes by remember { mutableStateOf(emptyList<Int>()) }
+    var lapTimes by remember { mutableStateOf(persistentListOf<Int>()) }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           time--
        }
     }

     Column {
        Row {
           Minutes(time / 60)
           val scope = SeparatorScope(time)
           scope.separator()
           Seconds(time % 60)
        }

        LapButton(
           onClick = {
              lapTimes += time
           }
        )
     }

     LapTimes(lapTimes)
  }

  @Composable
- fun LapTimes(lapTimes: List<Int>) {
+ fun LapTimes(lapTimes: ImmutableList<Int>) {
     // lapTimesが変化したときのみリコンポーズされる
     Column {
        for (t in lapTimes) {
           Text("$t")
        }
     }
  }
```
これが、引数がStableとみなされる条件その1「Composeからアクセスできるプロパティが変化しない」。

続いて、条件その2「プロパティが変化したときComposeフレームワークに通知する」ってなんなのかというと、まあ早い話Stateを使ってるってことです。StateはComposeに変更を通知してくれますからね。

例えば引数の型を `State` にしてもスキップが可能。
```diff_kotlin
  @Composable
- fun LapTimes(lapTimes: ImmutableList<Int>) {
+ fun LapTimes(lapTimesState: State<ImmutableList<Int>>) {
     // lapTimesStateが変化したときのみリコンポーズされる
     Column {
-       for (t in lapTimes) {
+       for (t in lapTimesState.value) {
           Text("$t")
        }
     }
  }
```

直接Stateを使う場合だけじゃなく間接的であってもStateで管理していればStableになる。
例えばTimerでrememberしていた2つのStateを別のclassに持たせてみる
```diff_kotlin
+ class TimerState {
+    var time by mutableStateOf(300)
+       internal set
+    var lapTimes by mutableStateOf(persistentListOf<Int>())
+       internal set
+ }

  @Composable
  fun Timer(
     separator: @Composable SeparatorScope.() -> Unit
  ) {
-    var time by remember { mutableStateOf(300) }
-    val lapTimes by remember { mutableStateOf(persistentListOf<Int>()) }
+    val state = remember { TimerState() }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
-          time--
+          state.time--
        }
     }

     Column {
        Row {
-          Minutes(time / 60)
+          Minutes(state.time / 60)
-          val scope = SeparatorScope(time)
+          val scope = SeparatorScope(state.time)
           scope.separator()
-          Seconds(time % 60)
+          Seconds(state.time % 60)
        }

        LapButton(
           onClick = {
-             lapTimes += time
+             state.lapTimes += state.time
           }
        )
     }

-    LapTimes(lapTimes)
+    LapTimes(state)
  }

  @Composable
- fun LapTimes(lapTimesState: State<ImmutableList<Int>>) {
+ fun LapTimes(state: TimerState) {
     // state.lapTimesが変化したときのみリコンポーズされる
     Column {
-       for (t in lapTimesState.value) {
+       for (t in state.lapTimes) {
           Text("$t")
        }
     }
  }
```
新しく `TimerState` というclassを作ったが、この型もStableとなる。

もっとプロパティや関数を経由したってOKだ。
```diff_kotlin
  class TimerState {
     var time by mutableStateOf(300)
        internal set
+    val minute: Int
+       get() = time / 60
+    fun second(): Int = time % 60

     var lapTimes by mutableStateOf(persistentListOf<Int>())
        internal set
  }

  @Composable
  fun Timer(
     separator: @Composable SeparatorScope.() -> Unit
  ) {
     val state = remember { TimerState() }

     LaunchedEffect(Unit) {
        while (true) {
           delay(1000L)
           state.time--
        }
     }

     Column {
        Row {
-          Minutes(state.time / 60)
+          Minutes(state.minute)
           val scope = SeparatorScope(state.time)
           scope.separator()
-          Seconds(state.time % 60)
+          Seconds(state.second())
        }

        LapButton(
           onClick = {
              state.lapTimes += state.time
           }
        )
     }

     LapTimes(state)
  }
```

Composeコンパイラは型がStableかどうかある程度推論してくれるが、やはり限界はある。
Stableになるように作っているのにComposeコンパイラがStableではないと推論してしまった場合は、 `@Stable` を付与してStableであることをComposeコンパイラに伝えることができる。
```diff_kotlin
+ @Stable
  class TimerState {
     var time by mutableStateOf(300)
        internal set
     val minute: Int
        get() = time / 60
     fun second(): Int = time % 60

     var lapTimes by mutableStateOf(persistentListOf<Int>())
        internal set
  }
```
なのだけど、現状、ComposeコンパイラがStableと推論したかどうかはIDE等で手軽に確認できず、少々面倒な手順を踏まないといけない。
なので私はわりとComposeコンパイラがどう考えたかは気にせずStableなら `@Stable` と書いている。

## 状態ホルダ

上記の `TimerState` みたいに複数のStateをまとめるインスタンスのことを *状態ホルダ* と言う。

Composableの状態をそのComposableの外部と共有するためにとても役に立つ。
Composableに何が表示されているのか、そのComposable以外も知ることができるし、Composableの状態をそのComposable以外が変更することもできる。

例えばComposable `Timer` の外に一時停止ボタンを置くとしたらこんな感じにできそうですね。
```diff_kotlin
  @Stable
  class TimerState {
     var time by mutableStateOf(300)
        internal set
     val minute: Int
        get() = time / 60
     fun second(): Int = time % 60

+   var isPausing by mutableStateOf(false)
+      private set

     var lapTimes by mutableStateOf(persistentListOf<Int>())
        internal set

+    fun pause() {
+       isPausing = true
+    }
+
+    fun resume() {
+       isPausing = false
+    }
  }

  @Composable
  fun TimerScreen() {
+    val timerState = remember { TimerStae() }

+    Column {
        Timer(
+          state = timerState,
           separator = {
              Text(
                 if (time % 2 == 0) { ":" } else { " " }
              )
           }
        )

+       if (timerState.isPausing) {
+          ResumeButton(
+             onClick = {
+                timerState.resume()
+             }
+          )
+       } else {
+          PauseButton(
+             onClick = {
+                timerState.pause()
+             }
+          )
+       }
+    }
  }

  @Composable
  fun Timer(
+    state: TimerState,
     separator: @Composable SeparatorScope.() -> Unit
  ) {
-    val state = remember { TimerState() }

-    LaunchedEffect(Unit) {
+    LaunchedEffect(state.isPausing) {
-       while (true) {
+       while (!state.isPausing) {
           delay(1000L)
           state.time--
        }
     }

     Column {
        Row {
           Minutes(state.minute)
           val scope = SeparatorScope(state.time)
           scope.separator()
           Seconds(state.second())
        }

        LapButton(
           onClick = {
              state.lapTimes += state.time
           }
        )
     }

     LapTimes(state)
  }
```

# derivedStateOf

ようやく本題。
でもここまでわかっていればderivedStateOf自体は難しくないんですよ。

:::note
derivedStateOfは、なにか他のStateを使った計算を行い、その結果を保持するStateである
:::

derivedStateOfというのは、なにか他のStateを使った計算を行って、その結果を保持しているStateです。
ちなみに derived（ディライヴド）なので注意。デリバード（delivered）でもドライヴド（drived）でもないです。

極端な例えだとこれだけのことです。
```kotlin
var a by remember { mutbaleStateOf(0) }
val b by remember { derivedStateOf { a * 2 } }
```
State `a` を2倍するという計算を行ってその結果を `b` というStateに保持させています。

そしてderivedStateOfは、計算に使ったStateが変更されると自動的に再計算されます。
`a` を4に変更すると自動的に `b` が8になるんですね。
```diff_kotlin
  var a by remember { mutbaleStateOf(0) }
  val b by remember { derivedStateOf { a * 2 } }

+ LaunchedEffect(Unit) {
+    a = 4
+    assertEquals(8, b)
+ }
```
え、これって別にderivedStateOfを使わなくても `a` が変更されたらリコンポジションが発火されて `b` も再計算されるから同じ結果になるのでは？

そのとおりです。

しかしderivedStateOfを使う場合、再計算されるのはderivedStateOfに渡した部分だけです。
```kotlin
val b by remember { derivedStateOf { a * 2 } }
//                                  ^^^^^^^ 再実行されるのはここだけ
```
再計算した結果 `b` の値が変化していなければリコンポーズが発火されないし、再計算した結果 `b` の値が変化していればリコンポジションが発火されます。
なぜならderivedStateOfはなにか他のStateを使った計算を行い、その結果を保持する **State** なので。ComposableはStateが変化したときにリコンポーズされます。

なるほど、ということはderivedStateOfを使って効果があるのは、 `b` の変更頻度が `a` の変更頻度より低くなるとき。
**Stateを使った計算結果の変更頻度が、元のStateの変更頻度より低いとき**
ということになりそうですね。

```kotlin
val b by remember { derivedStateOf { a * 2 } }
```
と書いても結局 `a` が変化するたびに `b` も変化するのでリコンポジションは全く減らないわけです。

例えば `derivedStateOf { a / 60 }` とかだと60回に1回しか計算結果が変わらないので効果がありそうですね。
ん、なんかこの計算見たことがありますね

## derivedStateOfを使うべきところ

それではderivedStateOfを使うべきところとderivedStateOfを使わなくていいところについて考えていきましょう。

いくつかderivedStateOfを使ったコードを置いておきます。効果があるのかどうかの答えは折りたたんでおくので、一度考えてみてから開いてもおもしろいかもしれません。

### Q1
```diff_kotlin
  @Composable
  fun Minutes(timerState: TimerState) {
-    val m = timerState.time / 60
+    val m by remember(timerState) { derivedStateOf { timerState.time / 60 } }
     Text("$m")
  }
```
まずはわかりやすい例です

<details><summary>このderivedStateOfは…</summary>

:::note info
Good!
:::
`timerState.time` は毎秒変化しますが、 `timerState.time / 60` は1分に1回しか変化しませんね。

Composable内に直接 `timerState.time / 60` と書くと毎秒リコンポーズされますが、derivedStateOfで包むことによって *derivedStateOfの再計算は毎秒行われますが、その結果が変化してMinuteがリコンポーズされるのは1分に1回となります。*
</details>

### Q2
```diff_kotlin
  @Composable
  fun Minutes(time: Int) {
     val m by remember { derivedStateOf { time / 60 } }
     Text("$m")
  }
```
引数をInt型に変えてみました。
毎秒異なるtimeが渡されてくるので、derivedStateOfを使ってリコンポジションを減らそうとしたパターンですね。

<details><summary>このderivedStateOfは…</summary>

:::note alert
Incident!!!
:::
このコードは意図通りに動作しません。
`m` の値は再計算されず、何分待っても同じテキストが表示されたままになります。

これはderivedStateOfに特殊な仕様があるわけではなく、rememberによるものです。

たとえば
```kotlin
val m = remember { time / 60 }
```
とすれば `m` がリコンポジション後も同じ値になるのがわかるでしょう。

たとえば
```kotlin
val m: () -> Int = remember {
   { time / 60 }
}

m()
```
としても `m()` はリコンポジション後も同じ値を返します。
これについては普段あまり気にしていない人もいるかと思いますが、
`{ time / 60 }` というラムダ式はコンパイル後下記のようになります。
```kotlin
class `Minutes$1`(private val time: Int) : () -> Int {
   override fun invoke(): Int {
      return time / 60
   }
}
```
それを ``remember { `Minutes$1`(time) }`` しているわけですから、リコンポジション後もこのラムダ式が返す値は古い値のままです。

derivedStateOfでも同じです。
</details>

### Q3
```diff_kotlin
  @Composable
  fun Minutes(time: Int) {
     val m by remember(time) { derivedStateOf { time / 60 } }
     Text("$m")
  }
```
Q2がダメだったのでrememberのキーでtimeを指定したパターンです。

<details><summary>このderivedStateOfは…</summary>

:::note warn
Ineffective...
:::
rememberのキーにtimeを指定してtimeが変化するたびにderivedStateOfを再生成するようにしたわけですが、それ結局リコンポジション減ってねえじゃねえか！ ってことでderivedStateOfの恩恵は受けられないです。
</details>

### Q4
```diff_kotlin
  @Composable
  fun Minutes(time: Int) {
     val timeState = rememberUpdatedState(time)
     val m by remember { derivedStateOf { timeState.value / 60 } }
     Text("$m")
  }
```
Q2がダメだったので引数で受け取ったtimeを一旦Stateに入れるようにしたパターンです。

<details><summary>このderivedStateOfは…</summary>

:::note warn
Ineffective...
:::
timeをStateに入れるようにしたことで、derivedStateOfは問題なくtimeの変化を検知できるようになりました。
`m` も1分に1回しか変化しないのでderivedStateOfはしっかり働いてくれます。

でもtimeが毎秒違う値になるならリコンポジションはスキップされないので、せっかくderivedStateOfが意図通りに動いてもリコンポジションは減りません。
</details>

### Q5
```diff_kotlin
  @Composable
  fun Minutes(time: Int) {
     val timeState = rememberUpdatedState(time)
     val minuteState = remember { derivedStateOf { timeState.value / 60 } }
     RealMinutes(minuteState)
  }

  @Composable
  private fun RealMinutes(minuteState: State<Int>) {
     Text("${minuteState.value}")
  }
```
スキップされないことがわかったので、せめて大部分を別のComposable `RealMinutes` に逃がしてスキップできるようにしたパターン。
サンプルではTextしかないけど、ここがすげーデカかったとして、Minutes自体はスキップできないかもしれないけど、RealMinutesに逃した大部分はスキップできるよねという考えです。

<details><summary>このderivedStateOfは…</summary>

:::note warn
Ineffective...
:::
derivedStateOfを使いたすぎて迷走していますね。

スキップしたいところを別のComposableに逃がすアイデアはたしかに有効なのですが、その場合derivedStateOfを使わなくてもスキップできるので…
```diff_kotlin
  @Composable
  fun Minutes(time: Int) {
     RealMinutes(time / 60)
  }

  @Composable
  private fun RealMinutes(minute: Int) {
     Text("$minute")
  }
```
これでよいです。
</details>

### Q6
```diff_kotlin
  @Composable
  fun TodoList(highPriorityKeywords: List<String> = listOf("Review", "Unblock", "Compose")) {
     val todoTasks = remember { mutableStateListOf<String>() }

     val highPriorityTasks by remember(highPriorityKeywords) {
        derivedStateOf {
           todoTasks.filter { task ->
              highPriorityKeywords.any { keyword ->
                 task.contains(keyword)
              }
           }
        }
     }

     Box(Modifier.fillMaxSize()) {
        LazyColumn {
           items(highPriorityTasks) { /* ... */ }
           items(todoTasks) { /* ... */ }
        }
    }
}
```
最後にComposeの公式リファレンスを見ましょう。

<details><summary>このderivedStateOfは…</summary>

:::note info
Good!
:::
まず最初に気づいてほしいポイントとして **引数の型がStableじゃない** ということがあります。
ImmutableListではなくListで宣言しているので、このComposable `TodoList` はリコンポーズされたとき引数が前回と同じであってもスキップされません。

Q5までは「使っているStateが変化したとき」もしくは「引数が変化したとき」だけを考えればよかったですが、このサンプルではなにかの理由で親ComposableがリコンポーズされればTodoListは引数もStateも変化していなくてもリコンポーズされます。

todoTasksをhighPriorityKeywordsでフィルタリングする処理はリコンポジションのたびに毎回やるには重すぎますよね。
なのでderivedStateOfを使って `todoTasks` が変化したときにだけ再計算されるようにします。

ただしこのフィルタリング処理では `highPriorityKeywords` も使っています。これはStateではないのでderivedStateOfは変更を検知できません。なのでrememberにキーとして `highPriorityKeywords` を指定して `highPriorityKeywords` が変化したときにderivedStateOf自体を再生成する必要があります。

`TodoList` は残念ながらスキップされませんが、BoxやLazyListはスキップできます。
そしてLazyList内で `highPriorityTasks` と `todoTasks` を使っているので、このどちらかが変化すればRestartableであるLazyListがリコンポーズされますね。このときには `TodoList` はリコンポーズされないでしょう。

ただ、このderivedStateOfは `highPriorityKeywords` があまり変化しないときに真価を発揮します。
もし `highPriorityKeywords` が `todoTasks` と同じくらいの高頻度で変化するとしたら…
そのたびに毎回derivedStateOfを再生成するよりは毎回フィルタリング処理をする方がコストが安いということがありえます。
その場合derivedStateOfを使わず `remember(todoTasks, highPriorityKeywords) { ... }` と書いたほうがいいわけですね。
</details>

# 最後に

もう一回言わせてほしい。

なんでこんな難しいのをサンプルにしたんだよ。