https://kotlinlang.org
Join Slack
Why is the mutableStateOf not wrapped by remember { } automatically? Having to write remember everyw...
# compose
o
Why is the mutableStateOf not wrapped by remember { } automatically? Having to write remember everywhere is just ugly and creates alot of noise
t
You could just create you own function to do that 😄
☝🏼 1
o
I know, but why isn't there in the first place?😁
t
Before it was stateOf and now they removed it to avoid confusion about the function behind this stuff. (I think it is just to make sure every one needs to think about it 😄 )
o
Soon or later, everybody will create that function, which would be just boilerplate. Seems easier if it was included in the library from the start.
Is there ever a case where one wouldn't use remember if he she is using mutableStateOf?
t
Yes when you want to use it inside of a normal class (not a composable function)
👆 1
o
But isn't it the point that State is used inside composable functions only? Classes use Livedata/flow
r
You don’t have to use live data or flow
t
Livedata is not so kotlin friendly and flow often a little bit over engineered. Also livedata is in my opinion more useful for the legacy view system.
r
Your own state classes makes sense too for intrinsic properties of a component
➕ 2
(Scroll state or whatnot)
a
Once you get past the basic examples the ratio of 
remember { mutableStateOf(...) }
to 
remember { MyStateClass() }
that uses 
by mutableStateOf
internally to create separate observable properties becomes weighted rather heavily towards the latter
The presence of the old 
state {}
helper for this created a hurdle that kept people juggling many state fields themselves long past when they should be grouped within an object, because they weren't comfortable with the component primitives involved
👆 1
It also caused people to think you could only create snapshot state objects during composition, and we observed people creating duplicate sources of truth and syncing between them to bridge the divide
👆 1
So we decided it was better not to have it to encourage better understanding in the 1.0 timeframe. Once these ideas and patterns become well understood in the wider community we might add it back for convenience
👌 1
r
Convenience is a four letter word
It’s amazing how quickly a convenience becomes an obfuscation.
➕ 6
b
@Adam Powell can you elaborate a little bit on what you mean by 
remember { MyStateClass() }
?
a
Objects like
Copy code
@Stable class MyStateClass(
    foo: Foo,
    bar: Bar
) {
    var foo by mutableStateOf(foo)
    var bar by mutableStateOf(bar)
}
that provide semantic grouping of several observable properties into a single concept
b
I see, is the annotation @stable required for remember also I assume that any property that changes will result in recomposition?
a
@Stable
is not required for remember, it's a signal that if you pass the same instance to a composable function that we can skip the child, since all of the object's data is observable and will notify the child if it changes
b
very neat
3 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by