Jetpack ComposeのComposable関数の引数に別のモジュールのクラスを使うときの注意点

さて、Composeは引数に同じオブジェクトを渡したときにいい感じにComposable関数をスキップしてくれます。
しかしそれには条件があります。

appモジュールと modelモジュールがあって、
appモジュールにはComposeが適応されていてComposable関数があって、
modelモジュールはシンプルにArticleクラスがあるとしましょう。

このうちちゃんと同じオブジェクトを渡したときにスキップしてくれるのはなんとComposable2のみです。 :innocent: 

```
app module ------------> model module
fun Composable1()        class Articles
fun Composable2()        class Article
fun Composable3()                                         
```

app module

```kotlin
@Composable
fun Composable1(articles: Articles) {
  Text(text = "Hello $articles!")
}

@Stable
data class UiModel(val articles: Articles)

@Composable
fun Composable2(uiModel: UiModel) {
  Text(text = "Hello $uiModel!")
  uiModel.articles.articles.forEach {
    Composable3(it)
  }
}

@Composable
fun Composable3(article: Article) {
  Text(text = "Hello $article!")
}
```

model module

```kotlin
data class Articles(val articles: List<Article>)
data class Article(val title: String)
```


これはCompose Compiler Metricsを使うことで確認できます。 restartableになっていて、skippableになっていないものは引数がたとえ一緒でもskipされません。
app_release-composables.txt

```
restartable fun Composable1(
  unstable articles: Articles
)
restartable skippable fun Composable2(
  stable uiModel: UiModel
)
restartable fun Composable3(
  unstable article: Article
)
```

## どうしたらいいのか？

3つ解決策が考えられます。

### 解決策1: `@Stable`になっているクラスでラップする

1つ目はComposable2の関数のようにUiModelクラスでラップすることです。これによりComposeにこのオブジェクトは変更されないことを通知することでうまく動きます。この場合は常にStableなクラスでラップすることを意識しながら開発する必要があります。

```kotlin
@Stable
data class UiModel(val articles: Articles)

@Composable
fun Composable2(uiModel: UiModel) {
  Text(text = "Hello $uiModel!")
  uiModel.articles.articles.forEach {
    Composable3(it)
  }
}
```

### 解決策2: モデルのあるモジュールでもComposeのコンパイラーを動かす。

このArticlesなどがあるmodelモジュールもComposeコンパイラーを動かしてしまいます。
これによってComposeがこのArticleなどのクラスのことを知ることができるので、うまく動きます。
しかし、これを行うにはComposeのruntimeのdependencyも必要になるので、Jetpack ComposeをUIフレームワークとして扱う場合は、UIとの分離という面ではちょっともやもやするかもしれません。(Composableの仕組みをこの変更可能かどうかを管理する仕組みとして考えれば入れてもいいと考えられるかもしれません。)

https://github.com/takahirom/compose-multi-module-stability/commit/a4a1a34ec769a8524309a2205f43b8f28ce6e633#diff-1fcd54ff839a5ae2ba602b56b215fe6c8202961396253435a3d6995814aa5d35R23

ただ、この場合でも`fun Composable1(articles: Articles)`ではRecomposeは防げません。なぜならListはMutableList(ArrayList)のインスタンスであることができるため、Stableではないためです。ただ、これはどの解決策を取っても同じ問題になります。

```
unstable class Articles {
  unstable val articles: List<Article>
  <runtime stability> = Unstable
}
````

https://github.com/takahirom/compose-multi-module-stability/commit/197ebe042cf2b55df7c164d23367b021464f117b#diff-7f18668c77db7822092fe2dd092247c3b68961fe7cd67db3cdd83b5efb828409R1-R4

### 解決策3: UIモデルに変換する

もちろん、これをして、UIの中のクラスを使えば解決します。これによって関心事の分離が可能になります。
ただ、もちろんメリットだけではなく、これは毎回の開発でマッピングを実装し、テストし、レビュー、メンテナンスしていくということになるので、コストを払うことになります。

(これはGuide to app architectureでも触れられています。 https://developer.android.com/jetpack/guide/data-layer?hl=en#business-models )


# まとめ

それぞれこの解決策にはメリデメがあるので、この中で自分がとれそうな方法をとっていくのが良いと思います。

もりさんがプロダクトの中で気づいて問題を教えてくれて、それを調べました
元ネタ (自分が質問したもの) 

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1648206217729339

実験したソースコード

https://github.com/takahirom/compose-multi-module-stability