https://kotlinlang.org logo
#compose
Title
# compose
c

Colton Idle

04/10/2022, 4:20 PM
I don't use
derivedStateOf
often but does this seem like a good use case? Bonus: Why can't I use
by
and need to use
=
when using
derivedStateOf
?
Copy code
class SignUpScreenViewState {
  var email by mutableStateOf("")
  var password by mutableStateOf("")
  var acceptTerms by mutableStateOf(false)
  var canMakeSignUpCall = derivedStateOf { email.isNotEmpty() && password.isNotEmpty() && acceptTerms }
}
d

Desmond Teo

04/10/2022, 4:20 PM
you need to make it val instead of var, it’s not a MutableState
c

Colton Idle

04/10/2022, 4:22 PM
Oh. That worked. and i suppose that makes sense. To my initial point, does this seem like a good use of jderivedStateOf?
f

Francesc

04/10/2022, 4:24 PM
Yes, that's exactly what derivedStateOf is meant for
👍 1
It's not dissimilar to Kotlin properties without a backing field
c

Colton Idle

04/10/2022, 4:26 PM
Thanks. I was getting into some analysis paralysis on whether or not I should have some sort of method in my viewModel instead that checks if the user can signup, but I like the derivedStateOf... except that I feel like it kinda hides some business logic in what should be a simple state model.
f

Francesc

04/10/2022, 4:27 PM
This is much better, if you have a method to call you could forget to call it when you update one property
👍 1
n

Norbi

04/10/2022, 4:28 PM
Isn't it too simple case for
derivedstateOf()
? As I understand
derivedStateOf()
should be used when the derived state is expensive to calculate. This is not the case in your example, in this case I would simple use a
val
property without a backing field. Eg., what I see as a valid usage for
derivedStateOf()
, is sorting and filtering a
List
with lots of elements...
f

Francesc

04/10/2022, 4:29 PM
Not sure where you got that from, but you may be mixing it up with
remember
What Colton had here is a perfectly valid use
And a simple val would not be observable
n

Norbi

04/10/2022, 4:33 PM
Yes, the example is correct from a sematical perspective. You may be right, I'm far from beeing a Compose expert 🙂 ,it was only an 'impression' based on the offical documentation:
As the filtering to calculate
highPriorityTasks
can be expensive, it should only be executed when any of the lists change, not on every recomposition.
And a simple val would not be observable
What I meant was:
Copy code
val canMakeSignUpCall get() = email.isNotEmpty() && password.isNotEmpty() && acceptTerms
Hmmm, do you mean that this would not work at all? (I'm almost sure that it would - but I cannot try it currently 🤔)
f

Francesc

04/10/2022, 5:05 PM
This would not trigger a recomposition on change, unlike the original code
👍 1
😮 1
2
n

Norbi

04/10/2022, 5:08 PM
Then... sory for the confusion 😐
f

Francesc

04/10/2022, 5:23 PM
No worries, we're all here to learn
💙 1
a

Albert Chang

04/10/2022, 11:48 PM
To be clear, @Norbi’s code will trigger recomposition if either
email
,
password
or
acceptTerms
changes. And the difference is also here: recomposition will happen whenever any of these three vars change, even if the result is the same, while a derived state will only trigger recomposition if the result of the calculation changes.
☝️ 3
4
a

Alex Vanyo

04/11/2022, 5:18 PM
Whether or not
val
has a
get() =
or not can make quite a difference in behavior. That isn’t Compose specific at all, but at least in my experience Compose makes me think about the difference way more
b

Ben Trengrove [G]

04/11/2022, 9:48 PM
Don't forget to do
remember { derivedStateOf {} }
as well
a

Alex Vanyo

04/11/2022, 10:28 PM
If you’re in a
@Composable
context you want the
remember
, if you’re in a state holder class like this one just having a
derivedStateOf
will be fine (there’s no
remember
to use!) Personally I’d probably go with the
get() =
approach for this specific case, I’ve been erring on the side of not using
derivedStateOf
unless it’s necessary for correctness or performance. But using
derivedStateOf
here as written will also lead to correct behavior.
b

Ben Trengrove [G]

04/11/2022, 11:43 PM
Oh whoops, didn't spot that it was a state holder
3 Views