I don't use `derivedStateOf` often but does this s...

# compose

[Colton Idle]

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 ?

class SignUpScreenViewState {
  var email by mutableStateOf("")
  var password by mutableStateOf("")
  var acceptTerms by mutableStateOf(false)
  var canMakeSignUpCall = derivedStateOf { email.isNotEmpty() && password.isNotEmpty() && acceptTerms }
}

[Desmond Teo]

you need to make it val instead of var, it’s not a MutableState

[Colton Idle]

Oh. That worked. and i suppose that makes sense.

To my initial point, does this seem like a good use of jderivedStateOf?

[Francesc]

Yes, that's exactly what derivedStateOf is meant for

[Francesc]

It's not dissimilar to Kotlin properties without a backing field

[Colton Idle]

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.

[Francesc]

This is much better, if you have a method to call you could forget to call it when you update one property

[Norbi]

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...

[Francesc]

Not sure where you got that from, but you may be mixing it up with remember

[Francesc]

What Colton had here is a perfectly valid use

[Francesc]

And a simple val would not be observable

[Norbi]

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.

[Norbi]

And a simple val would not be observable

What I meant was:

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 🤔)

[Francesc]

This would not trigger a recomposition on change, unlike the original code

[Norbi]

Then... sory for the confusion 😐

[Francesc]

No worries, we're all here to learn

[Albert Chang]

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.

[Alex Vanyo]

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

[Ben Trengrove [G]]

Don't forget to do remember { derivedStateOf {} } as well

[Alex Vanyo]

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.

[Ben Trengrove [G]]

Oh whoops, didn't spot that it was a state holder