Feature Request - make Library data class stable

Question

Feature Request - make Library data class stable

Nailik opened this issue a year ago · 15 comments

Stable is used in compose to improve recomposition because objects that didn't change don't need to call a recomposition of the composable where they are shown.

This could either achieved by marking generated Library stable with:

@Stable
Library

or by really making it stable:

use ImmutableList instead of List
use ImmutableSet instead of Set

I prefer making both, really making it stable and also add @stable to make it sure.
Same for Organization and Developer

Note: kotlinx.collections.immutable does not yet support linuxArm64 Kotlin/kotlinx.collections.immutable#79

Answer 1 · 2023-05-03T20:35:19.000Z

Thank you very much for the suggestion. I will have a closer look into that.

Most likely the @Stable will be the choice, until all required targets are supported

Answer 2 · 2023-05-04T06:34:36.000Z

Upon further investigation, the @Stable nor the @Immutable annotations can be added to the Library class, as those are part of the compose-runtime, however the core module of AboutLibraries does not have dependencies on compose.

Looking for answers, I could not find a proper solution other than adding compose to core which is not anticipated.

Open for other solutions.

Answer 3 · 2023-05-04T19:00:14.000Z

I also recently found out that @Stable is compose only. But data classes should be recognized by compose as stable when they are stable.
So checking that all variables are val and all lists are ImmutableList it shoud work. Also as far as i know the immutable library https://github.com/Kotlin/kotlinx.collections.immutable requires only kotlin and not compose so i should work.

Answer 4 · 2023-05-04T19:52:11.000Z

However as you noted the immutable project does not support all the architecture targets this project offers. Until this is the case, it cannot be fixed within the core library unfortunately.

Answer 5 · 2023-07-17T09:20:29.000Z

While Library couldn't be marked as Stable, there's now a new extension function which wraps the Library into an value class marked as Immutable:

https://github.com/mikepenz/AboutLibraries/pull/906/files#diff-c6dbf278529759cc4388375a78a41da6646173cf61895a7117d6a75dda58f46fR9-R15

Overall the compose code was re-worked to be more efficient through the above too.

Answer 6 · 2023-07-17T10:42:03.000Z

Nice thank you @mikepenz that's pretty much how i solved it currently.

BTW there seems to be an open PR from a guy at Jetbrains that would solve the issue by adding the remaining targets Kotlin/kotlinx.collections.immutable#148

Answer 7 · 2023-10-05T21:54:35.000Z

With kotlinx.collections.immutable 3.6.0 there is now finally support for all architectures and i think this could now be reopened and worked on

Answer 8 · 2023-10-31T12:39:04.000Z

Thank you for the update here.

Answer 9 · 2024-01-06T09:44:14.000Z

Started working on this. However something strange is happening, which I don't understand yet:

the Library class will not have a clear runtime stability even though as all of it is stable.

Resulting in the Libs class being unstable.

Answer 10 · 2024-01-06T16:12:11.000Z

Maybe you could use the @Stable annotation on the Library to tell the compiler that it has runtime stability?

Answer 11 · 2024-01-06T16:21:53.000Z

If only the official one was available for multiplatform projects 🙃 .

And unfortunately the awesome temporary one from Skydoves doesn't yet seem to support wasm: https://github.com/skydoves/compose-stable-marker

Answer 12 · 2024-01-06T17:01:04.000Z

I opened a post in the kotlin slack maybe they can help https://kotlinlang.slack.com/archives/C3PQML5NU/p1704560437578069

Answer 13 · 2024-01-08T18:12:25.000Z

Did you ran it from a clean build to generate the compose compiler metrics? There was a bug where in incremental compilation it would incorrectly infer stability. Can't seem to find the exact issue at hand though.

Answer 14 · 2024-01-08T18:59:29.000Z

@MV-GH yes I tried it on clean builds too. Unfortunately, it still resulted in these strange results

./gradlew clean aboutlibraries-core:assembleRelease -PcomposeCompilerReports=true

Using this branch (added compose compiler to the core module to run the report): https://github.com/mikepenz/AboutLibraries/tree/test/compose_compiler_core

It's worth noting that I observed inconsistencies between reports (when I was testing different things) - and yes I can confirm that incremental builds made things very inconsistent :D.

Thank you so much @MV-GH for also looking into it

Answer 15 · 2024-01-25T13:34:33.000Z

I have now added a stability config file to the core module which is applied to the m2 and m3 modules.
https://github.com/mikepenz/AboutLibraries/pull/947/files#diff-712ed77459cddd5330863385aafe9b2ac858c77264e835c5a72dec5d292692ec

https://github.com/mikepenz/AboutLibraries/pull/947/files#diff-b652902b5629ab239e12e0496a86224dfaaf82622c8bd7163cd329d5ae1a4df8R56

As described here:
https://developer.android.com/jetpack/compose/performance/stability/fix#configuration-file

for the m2/m3 modules the stability looks good now.