If you're interested in learning more about the up...

# compose

[Stylianos Gakis]

If you're interested in learning more about the upcoming strong skipping mode, you do not want to miss reading this https://medium.com/androiddevelopers/jetpack-compose-strong-skipping-mode-explained-cbdb2aa4b900

[Ben Trengrove [G]]

Thanks for sharing it!

[Stylianos Gakis]

Thanks for writing it! Admittedly one took quite a lot more effort than the other 😅

[Lukasz Kalnik]

Thanks for the great article!
I have a question: why are unstable classes, like List implementations (or probably a data class with a var as well) compared using referential equality? The contents of a (mutable) List might have changed (a var as well), although the instances would still be the same.

[Stylianos Gakis]

I would argue that’d be a clear case of putting yourself into trouble for no reason.
Using internally mutable states that are not backed by MutableState has already and will forever be a source of bugs in compose anyway.
It is the same as using lists that are internally mutating, compose would have no way to be able to understand those changes anyway. Which is also why SnapshotStateList exists in the first place.

[Lukasz Kalnik]

So before strong skipping mode compose tried to "protect us from ourselves", but now it just trusts the programmers to "do the right thing"?

[Lukasz Kalnik]

Because that was exactly the rationale why the composables containing unstable types were always recomposed, before strong skipping mode.

[Lukasz Kalnik]

"Because the mutable data underneath might have changed unexpectedly, compose recomposes these functions every time"

[Stylianos Gakis]

Passing an internally mutable list wouldn’t work before either if the only thing you did was mutate its contents internally. The internal state would change and compose would not know about it, therefore not recompose and you’d be showing stale state already, even with the old non-strong skipping mode.
It would only accidentally work if you changed some other snapshot backed object, which would result in a recomposition, and then just by luck you would also recompose the other composable which takes the internally mutable list, which would then be passed with the right parameters.

[Lukasz Kalnik]

Yes, exactly. That's why the previous rationale for recomposing on every parameter change was not clear to me.

[Lukasz Kalnik]

So I assume the Compose team now realized "we had guards in place which anyway would only work by accident, so we might as well remove them"?

[Stylianos Gakis]

Well I am not sure if this is the rationale word for word, but it could be at least close. The article does mention about them being surprised that developers are more often puzzled about things recomposing too often, and not that they are not recomposing.
So my understanding is that yes, those extra guards that were in place were strict enough that they are considering relaxing those to a more pragmatic level.
And I mean that’s why we got this preview where we can play with strong skipping mode and report if that feels too bad on the other end of the coin. I’m sure this will be considered hard before it’s turned on by default for everyone.

[Lukasz Kalnik]

BTW here is the rationale for the current non-strong skipping mode from the article:

We took a conservative approach to recomposition, we believed in the case where we don’t know if the inputs to a composable have changed (because they are unstable and their mutations are not tracked by the compose runtime), we should never skip. Yes, this may be slightly less performant but it will mean the app always shows the correct state, which is the most important factor for the end user.

[Lukasz Kalnik]

It clearly says "the app always shows the correct state" which I have problems understanding.

[Lukasz Kalnik]

I would understand it, if the recomposition would happen on every frame, but it's not the case.

[Stylianos Gakis]

Well, I think you are getting a bit caught up in the wording there.
Of course it’s not always when you have a crucial mistake in how you handle state by having local mutable non-snapshot state that you change by itself.
It’s just that before compose did not make any assumptions for objects that it could not be sure about, while now it will at least make the assumption that having the same reference should mean being equal.

[Ben Trengrove [G]]

Updated the post to clarify, you are right "always" was the wrong word. Sorry for the confusion