What is the recommended way to declare computed state? Is it with

remember(a, b) { a + b}

or

derivedStateOf { a + b }

?

I believe

derivedStateOf

should be used to calculate a new

State

based on an existing

State

, in your example

remember

is the correct function.

@lewis it is still interesting why we have to let

remember

know which parameters it depends on, while derivedStateOf does it out-of-the-box

This is an eager vs lazy thing. derivedStateOf is lazy, which means of the inputs change the immediate lines of code afterwards doesn't have to be recomposed. Only the real dependencies have to be be.

Interesting,

derivedStateOf

is more powerful than I realised.

We need to give remember the keys because it's not deriving state, it simply remembers and then forgets when the keys change.

@Dominaezzz could you elaborate on why derivedStateOf needs to be remembered in order for it to be useful?

val annotated text = remember { derivedStateOf { parseAnnotated(text) } }

how it should be used.

Oh yeah, I get it for this case, but for here:

var a by remember { mutableStateOf(0) }
var b by remember { mutableStateOf(0) }
val sum = derivedStateOf { a + b }

I assume remember doesn't have to be used here. We dont have to let derivedStateOf know that it depends on a and b, in contrast to remember {}

In that case, you don't need to let derivedStateOf know but you still need to hold a reference to the state object it returns. (I'm on my phone so I can't type code as much as I want to)

var a by remember { mutableStateOf(0) }
var b by remember { mutableStateOf(0) }
val sum = derivedStateOf { expensiveAlgorithmComputation(a, b) }

How about now?

var a by remember { mutableStateOf(0) }
var b by remember { mutableStateOf(0) }
val sum = remember { derivedStateOf { expensiveAlgorithmComputation(a, b) } }

This is how it should be written.

Let's make this example more close alike like the original example:

var text by remember { mutableStateOf("") }
val annotatedText = derivedStateOf { parseAnnotated(text) }

Yes, the state object caches the result of the lambda but you still need to remember the state object and not recreate it.

var a by remember { mutableStateOf(0) }

var b by remember { mutableStateOf(0) }

`val sum = remember { derivedStateOf { expensiveAlgorithmComputation(a, b) } }```` Your example looks reaaally complex compared to ReactJS simple usage of useMemo()

var a by remember { mutableStateOf(0) }

var b by remember { mutableStateOf(0) }

`val sum = remember { derivedStateOf { expensiveAlgorithmComputation(a, b) } }```` Whats the point here actually of derivedStateOf? Is this not the same effect?:

var a by remember { mutableStateOf(0) }

var b by remember { mutableStateOf(0) }

`val sum = remember(a, b) { expensiveAlgorithmComputation(a, b) }````

Eager vs lazy.

Remember = eager, derivedStateOf = lazy?

You can pass around the result of derivedStateOf without subscribing to the state. Which can be useful.

Ok. any reason why we can't bring derivedStateOf power of automatically resolving its dependencies to remember?

What if you don't want that? What if you only want to recalculate based on one value but only take snapshots of other values that might change.

Then introduce a new remember? E.g.

rememberWithMagic {}

I reckon they won't add it, since it's easy for us to write it ourselves.

How easy are we talking about?

Stupidly easy. Just make a composable function that takes a lambda. Remember and derive it. Done.

Ok, I thought derivedStateOf only works with state dependencies, but it apepars to work with everything

The reason The reason

derivedStateOf

“automatically” knows its dependencies, but

remember

does not, is because of how snapshots work in compose. I recently tried to kind of explain how the snapshotting semantics work, and how it applies here is that

derivedStateOf

is a snapshot reader – after the first execution of that lambda, it will be notified any time a snapshot is applied that modifies any of the state objects in that lambda. This is super convenient, but comes at a price – it needs to do a lot more bookkeeping to track changes. It also returns a

State

instead of the raw value, which means: 1. The calling recompose scope doesn’t need to recompose if one of the dependencies change, only the scopes that are actually reading the state value do (e.g. if you call derivedStateOf in a composable but then only read the actual state value inside of composable lambdas passed to children). 2. The returned

State

object actually checks for modifications when the value is read. This is why it doesn’t need any explicit disposal.

remember

is much simpler and doesn’t do any bookkeeping, which makes it much cheaper to use. It returns the raw value returned from the lambda, which means that if it wants to return a new value (e.g. when one of its dependencies is changed), the entire calling recompose scope needs to be recomposed. It tracks dependencies not by using the snapshot mechanism, but instead by simply comparing the key values on each call.

Back to the original question, this doesn't used

derivedStateOf

because the API doesn't exist when that presentation was made (it very well could if it was being written today - which would probably cause a different example to be chosen as that section was about introducing remember 🙂 ).