I was looking into the compose richtext(very awesome library :heart_eyes:). Wanted to check why some...

# compose-android

[Atul Gupta]

I was looking into the compose richtext(very awesome library 😍). Wanted to check why some of the internal object is annotated with @Immutable ? One ref @Immutable usage on object is https://github.com/halilozercan/compose-richtext/blob/edff0f6a59f208a99f79a7636e6d[…]nMain/kotlin/com/halilibo/richtext/markdown/node/AstNodeType.kt

[Atul Gupta]

Isn’t object supposed to be Immutable by default?

[sindrenm]

I might be wrong, but I don't think all `object`s would be inferred as @Immutable, no, but in many of the cases you linked to, they probably could be.

Kotlin's `object`s don't all need to be immutable, though, as this is perfectly valid:

object Cache {
  var value: Value? = null
}

[Atul Gupta]

So is current annotation needed or can be removed? I am also planning to create states based on sealed class and has usages of object like above. Wanted to know if Immutable should be used or not?

[sindrenm]

I would imagine that the Compose compiler would infer @Immutable for objects such as

object ObjectWithNoBody

and

object ObjectWithAlreadyInferredImmutableValues {
  val immutableValue: Int
}

but I'm no expert on this.

I'm also quite sure that any child of a @Immutable sealed type is also inferred as immutable, so that

@Immutable
internal sealed class AstContainerBlockNodeType

internal object AstDocument : AstContainerBlockNodeType()

internal object AstBlockQuote : AstContainerBlockNodeType()

would infer @Immutable on both AstDocument and AstBlockQuote, as well, but again, I'm not 100% sure about this.

[eygraber]

I think you're correct on all counts except child types which are not automatically inferred as immutable because their parent is.

[sindrenm]

Oh, thanks for clearing that up, then! 🙌

[Atul Gupta]

@eygraber is there a better way to debug theses cases?

[eygraber]

You can use compiler metrics to get a report of the stability status of each class.

[Atul Gupta]

I added Immutable to a data class which is parameter in compose function but Recomposer state still showing that as changed. is this possible when some data class is marked as Immutable ?

[eygraber]

Did the value of the parameter change in between function invocations?

[Atul Gupta]

I checked the string content those are same in each recomposition

[Atul Gupta]

Also will that matter when data class is marked as Immutable ?

[Atul Gupta]

In my case all these, UI composable are inside lazy list and this only happens when I scroll a view outside the port and then scroll back to make that view come back to the window port

I have also used key in the in lazy list.

[eygraber]

I'm having trouble understanding what the issue is. Are you able to share code to highlight the problem?

[Atul Gupta]

I am trying to create a sample project, and will see if the issue is reproducible over there or not?

[Atul Gupta]

I have added // put debug here where you can add debug point and will see Composable fun AbstractLayout(): Arguments: Different: ["item"] even when UiModel is marked Immutable

ComposeListRecomposition.zip

[Atul Gupta]

@eygraber is it the case that every branch of sealed class should be marked Immutable ? Checked this this is not the case

[eygraber]

So your question is why AbstractLayout recomposes when the user scrolls back to a specific item?

[Atul Gupta]

yes.. shouldn’t that all remembered value be persisted?

[Atul Gupta]

As I have provided the key to LazyColumn

[Atul Gupta]

My use case is with each item has some states and some heavy computation and now with scroll those values are getting reset

[Atul Gupta]

or if there could a way I can pre-render few items.. as o/w I am seeing slight jerk(cpu spike) while scrolling the list

[eygraber]

So first off you should never count on no recomposition happening, but recomposition could happen at any time for any number of reasons, even when following stability guidelines.

In this particular case I believe recomposition has to happen because when you scroll away from an item, that node could get reused for another item, and so scrolling back to it would need to recompose in order to show the correct UI.

As far as seeing a slight jerk, are you running the app in debug or release mode? Unless you're in release mode you can expect to see performance hiccups from time to time.

is it the case that every branch of sealed class should be marked Immutable

If you have a branch that wouldn't be inferred to be stable, you'd have to mark it as Immutable even if the sealed class itself was marked as Immutable.

[Atul Gupta]

Thanks, Got it.. I think I have to save some states at the parent level which will prevent the states from getting reset.

[Atul Gupta]

As far as seeing a slight jerk, are you running the app in debug or release mode? Unless you're in release mode you can expect to see performance hiccups from time to time. this I will confirm in release build as well, Right now I am using in Debug build