https://kotlinlang.org logo
Join Slack
Powered by
changed the approach as Leland suggested
# compose
a
changed the approach as Leland suggested
updated-compose-sample.kt
l
@Fudge here’s an example of 
val (value, setValue) = +state<T> { initialValue }
f
Oh, nice of you to prove my point
He should be using 
by
l
😂
I was not saying this is the best way 🙂
f
Using the destructuring syntax here makes the code less readable
l
That what you think though 🙂
f
No, this is pretty obvious
messages = messages + it
And one less variable
l
🤦🏼
l
I think destructuring can work really nicely in the case of boolean state, like for a Switch / Checkbox. Compare delegate:
Copy code
var checkedState by +state { true }
Switch(
    checked = checkedState,
    onCheckedChange = { checkedState = it }
)
With destructuring:
Copy code
val (checked, onChecked) = +state { true }
Switch(
    checked = checked,
    onCheckedChange = onChecked
)
Although most of the time I would agree that delegate is the nicest way of consuming state.
f
I agree
l
I also agree that in most of the case 
by
is nicer
I just pointed out that there are some case in which someone might want to use destructuring 🙂
But for someone understandability/readability is not subjective
f
Actually, you pointed out a case in which destructuring allowed someone to do something suboptimally
l
Yeah, and so? If it makes it easier to understand/read, I’m totally with it 🙂 It’s not wrong
f
The idiomatic kotlin syntax is to use assignment instead of setters (hence the ide inspection)
Sorry, this is wrong just like putting semicolons when you don’t need them is wrong
l
How is it wrong?
a
the good thing about destructuring is that you can pass the lambda elsewhere and hide that from the UI
this is a very simple and dummy example, don't take it as an example of much 😅
f
You add an unnecessary variable and use a function setter instead of assigment. I think those are things that are considered suboptimal in the kotlin community. Some people might disagree, just like some people think semicolons are good, but this is the accepted best practice in kotlin.
l
I’m not, I just pointed out that there’s an application for that way of declaring a state
I was asking about semicolons, how are them wrong?
f
I’m not sure what you mean by “wrong”, but semicolons are considered boilerplate
l
You said that
this is wrong just like putting semicolons when you don’t need them is wrong
f
In that case wrong means suboptimal
l
Well, that’s a completely different meaning 😉
And if you always wanted to say 
suboptimal
instead of 
wrong
then fine, you’re completely right 😄
a
This is one pedantic conversation
l
We love to argue 😄
t
I'm happy to note that the library supports both options, so everyone should feel good about it ;)
➕ 1
😕 1
r
Would the gripe be lessened if the setter were named 
setMessages
instead of 
messagesChanges
?
Open in Slack
PreviousNext
Powered by