Pulling this out of the thread to avoid derailing it What do

Question

Pulling this out of the thread to avoid derailing it What does this mean for `savedInstanceState` Looks like it s stuck around for now

Leland Richardson [G] · Answer

I think this is being discussed Have any strong feelings yourself

Leland Richardson [G] · Answer

just a reminder that `state` `savedInstanceState` `remember` `rememberSavedInstanceState`

Leland Richardson [G] · Answer

so the most consistent change would be to get rid of it and just have `rememberSavedInstanceState`

Leland Richardson [G] · Answer

which perhaps we could should rename in that case

Leland Richardson [G] · Answer

and the `rememberSavedInstanceState mutableStateOf 0 ` would get an autosaver that would just work

brandonmcansh · Answer

Makes sense to me

Zach Klippenstein (he/him) [MOD] · Answer

`rememberSavedInstanceState` is a little weird to me conceptually Why would I care about saving an immutable value The kdoc explanation about mutable values makes more sense but for `rememberSavedInstanceState mutableStateOf 0 ` you d need to always wrap your custom `Saver` in one that unwraps wraps the `MutableState` value right That s a bit awkward

Zach Klippenstein (he/him) [MOD] · Answer

I think having an overload that specializes the type parameter upper bound to `State` or `MutableState` and automatically wraps the `Saver` would solve that

Zach Klippenstein (he/him) [MOD] · Answer

TBH even `state` seems so common and small that I m a little disappointed to see it go away although I completely understand the desire to minimize the amount of magic and the API surface and this is probably a lot simpler to educate

Leland Richardson [G] · Answer

i used to hold on to the short simple sweet `state` API so strongly that you d have to pry it from my cold dead fingers

Leland Richardson [G] · Answer

but not so much anymore after having thought about it and sitting with the idea for a while

Leland Richardson [G] · Answer

i ve seen a lot of people fundamentally misunderstand what the `state` API actually is

Leland Richardson [G] · Answer

and `remember` is the real fundamental API that people need to understand

Leland Richardson [G] · Answer

and right now even if they did understand `remember` they might miss the fact that `state` is just a convenient call to remember

Leland Richardson [G] · Answer

it makes demos and simple code slides more verbose but i think in the long run its the right call it stops conflating state with remember

Leland Richardson [G] · Answer

people missed the fact that `mutableStateOf` can be used outside of composition

Leland Richardson [G] · Answer

and also we are seeing patterns emerge where people want to create Composable convenience factory functions that create an object maybe using some ambient values and then remember it simplifying the usage site

Zach Klippenstein (he/him) [MOD] · Answer

It s clever but i ve seen a lot of people fundamentally misunderstand what the state API actually is sure seems to suggest it s too clever

Leland Richardson [G] · Answer

for instance you could have ` Composable fun SomeClass = remember SomeClass SomeAmbient current `

Leland Richardson [G] · Answer

this pattern i think is probably bad but having a reusable convenience method isn t necessarily bad

Leland Richardson [G] · Answer

I d like to push the convention of prefixing such methods with `remember` to hammer in the point

Leland Richardson [G] · Answer

so instead ` Composable fun rememberSomeClass = `

Leland Richardson [G] · Answer

because the problem is it is too hard to tell at the usage site if this is something you ought to remember or not

Leland Richardson [G] · Answer

and even worse you can t do ` Composable fun SomeClass = SomeClass SomeAmbient current `

Leland Richardson [G] · Answer

because in that case the caller can t remember the result because remember lambda blocks can t have composable calls in them

Leland Richardson [G] · Answer

anyway it s a complicated choice but this is probably the right call i think perhaps worth a blog post or something describing the decision and the anti patterns we saw emerge

Zach Klippenstein (he/him) [MOD] · Answer

makes perfect sense I think it s easy to over index on the usefulness of cute little sugary things like this early on that just feel so good when writing samples and stuff when they don t actually provide much value in readability in real code and make the mental model you have to acquire so much bigger

Leland Richardson [G] · Answer

yeah exactly

Leland Richardson [G] · Answer

i think for a composable function to be understandable its somewhat important to be able to identify which objects are remembered across recompositions and which ones aren t

Leland Richardson [G] · Answer

this convention + API change will help move towards that

Timo Drick · Answer

Just one thought about naming In Kotlin there is the delegate lazy which does more or less the same like remember So maybe remember should be called lazy Btw LazyColumnItems LazyRowItems are doing different things So maybe not use Lazy as Prefix for this Recyclerview thing I think this would make it much easier to understand

Timo Drick · Answer

Maybe just ColumnItems RowItems

Leland Richardson [G] · Answer

semantically lazy and remember are very different things

Leland Richardson [G] · Answer

i don t think `lazy` is the right term to use here i m actually quite happy with the name of `remember` but maybe others feel differently

Timo Drick · Answer

Ok than i still do not understand remember smile

brandonmcansh · Answer

Lazy Items are prefixed that way because of how they handle recomposition wrt visible items

Zach Klippenstein (he/him) [MOD] · Answer

`remember` initializes the value invokes the lambda eagerly synchronously The `lazy` delegate doesn t initialize the value until it s read i e lazily Like the `lazy` delegate `Lazy Items` doesn t add its children to the composition until they re scrolled into view

Timo Drick · Answer

OK yes that makes sense Thank you for clarifying this

brandonmcansh · Answer

Wrt Lazy Item is it expected behavior for a recomp to not occur until scroll even if its state value updates

andylamax · Answer

`Lazy Items` has been bugging me so much < Zach Klippenstein he him MOD > s explanation has made it so clear to me Thanks

Zach Klippenstein (he/him) [MOD] · Answer

`RecyclerView` is such a weird name when you think about it the main feature of `RecyclerView` is that it s lazy The fact that it recycles views is just an optimization to reduce memory usage and allocations It doesn t have anything to do with its core functionality I like the `Lazy Items` name a lot better since it highlights the main feature use case

Leland Richardson [G] · Answer

new idea we just hire < Zach Klippenstein he him MOD > to write all of our documentation

Zach Klippenstein (he/him) [MOD] · Answer

Leland Richardson [G] · Answer

you can write my slides and give my presentation while you re at it grimacing

andylamax · Answer

joy joy joy joy joy joy

gildor · Answer

I think the biggest problem with this that eventually everyone will have own `state ` function to get rid of boilerplate

Zach Klippenstein (he/him) [MOD] · Answer

At least they ll know how it works though sweat smile

gildor · Answer

they will just select `remember mutableStateOf ` alt + enter extract to a function and forget about it next minute or maybe it will remember only one developer in the project who introduced this extension

gildor · Answer

even something like `rememberState ` would be probably better

Leland Richardson [G] · Answer

yeah i think we might consider adding `rememberState`

Leland Richardson [G] · Answer

we re trying to be thoughtful here though its a lot easier for us to add a convenience API later

Leland Richardson [G] · Answer

much harder for us to remove an API especially one which would see as high of usage as this one would

Leland Richardson [G] · Answer

and it has become pretty clear to us that people are missing the fact that state is a convenience method

Leland Richardson [G] · Answer

and instead thinking its doing some fundamental thing

Leland Richardson [G] · Answer

so they miss the real fundamental APIs which are `remember` and `mutableStateOf`

gildor · Answer

gt much harder for us to remove an API Maybe use OptIn annotation same as Kotlin stdlib does

andylamax · Answer

They ll have to OptIn the whole lib then Coz its experimental it okay if things are shaken here and there until a concrete decision is made

gildor · Answer

Yes but this looks as more fundamental decision not only until Compose dev preview alpha