Given this basic composable:

@Composable
fun FancyText(text: String) {
    val formattedText = remember(text) { computeTextFormatting(text) }
    Text(formattedText)
}

Is the use of

remember

necessary/valuable here? Seems like the only time this would get recomposed is if

text

changes, and in that case we’d want to re-compute the

formattedText

value. In other words, we’ll always re-compute the

formattedText

value, so do we even need

remember

?

There are ambients in the background that can also change.

So then, is it fair to say that you should always

remember

any (non-trivial) calculated values?

Especially if it's particularly expensive. You don't want to cache everything.

yep. The use case that got me thinking is something kinda like this:

@Composable
fun AlphabeticalList(items: List<String) {
    val aList = items.filter { it.startsWith("A") }
    val bList = items.filter { it.startswith("B") }

    ....
}

figured I should probably use

remember(items)

on both of those

That one is a bit more tricky.

Use remember for persistence across recompositions first and performance when you can measure a meaningful difference

@Adam Powell typo, or is it too early for me to be parsing english?

nah, might also be not enough coffee yet for me to be writing it though 😄

What time is it where you are?

8am

~8am. My kids actually let me sleep in a little today

Woah! That's super early.

rephrased; reach for remember if you need the properties of the same object outliving a single composition and retaining its identity across those compositions

Luckily, mine have a babysitter video games, so I can sleep in. Made it all the way to 9am today! 😃

My 5 year old is currently entertaining my 3 year old and they aren't fighting yet

Can

val formattedText = remember(text) { computeTextFormatting(text) }

be replaced with

derivedStateOf { computeTextFormatting(text) }

?

No,

derivedStateOf

doesn't do any caching; it merely provides a value that subscribes to any model reads and will update its self when a dependency changes. So

remember

and

derivedStateOf

do orthogonal things.

Ohhh, I was so confused at first.

@jim can you give an example? I’ve not come across

derivedStateOf

yet …

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

If either

a

or

b

changes, then sum will also automatically change. No memory involved, yes updates/subscriptions involved.

Why not just do

val sum = a + b

?

ah ok, so it derives a new state from some other state(s) … who’d have guessed that from the name? 😉

in most cases, that's much simpler, @Dominaezzz as long as

sum

is only read in the local part of the composition. An important property of

derivedStateOf

objects is that they change as part of the same snapshot transaction as their inputs; readers won't see a state of the world where

a

or

b

change but

sum

hasn't been updated yet. And if those inputs do change, only places where sum is read will invalidate, not the place where it was computed.

Another important property is that

derivedStateOf

can be used outside of composition to build all sorts of fun data structures that cache computations before passing them into composables.

Ah the last two points there really hit the spot. Thanks for explaining.

Right. So if you have some class

class FancyState {
  var a by mutableStateOf(0)
  var b by mutableStateOf(0)
  val result by derivedStateOf {
    somethingVeryExpensiveWith(a, b)
  }
}

then the expensive operation will be cached and only run when needed, and conceptually as part of the same snapshot transaction where a or b changed

Ohh, like literally used outside of composition. I was imagining passing the state outside for some reason.

things like this can also combine with

snapshotFlow {}

for other consumption outside composition if you'd like

Woah, I didn't know

snapshotFlow

could be used outside composition!

if you start using

snapshotFlow

do try to avoid round-trip conversions where you end up doing a

.collectAsState

for a flow that started as snapshot state to begin with 🙂

😫 becomes sad again that the call syntax for composables is no longer different from the call syntax of non-composables. But alas, no use crying over spilt milk

So many tools! 😍 …. so little time to learn them all … which is why I’m sitting at my computer on a Saturday morning.

Why do you have that

remember

? That seems wrong. As a general rule of thumb, IMO, if you are using remember outside of a parameter's default value expression, you're probably writing smelly code.

you mean this?

val postList by remember(viewModel) {
        // A Flow of posts from a room DB.
        viewModel.recentPosts
    }.collectAsState(initial = listOf())

Yes

I read something on here a few days back (might have been from @Adam Powell) about some gotchas with collecting flows and recomposition, and the suggestion was to use

remember

… Let me see if I can find that.

I remember (😛) that. It had to do with applying transformations in the composable.

Oh, it was in the case where you have a

Flow

and use some operators on it, like

flowOf(1,2,3).map { it * 2}.collectAsState()

Might want to consider using

produceState

I think.

Also, having the HomeScreen take in an implementation of ViewModel needlessly ties your widget to your application's android view implementation. Better to define an interface that your HomeScreen accepts as a parameter, and your view model can implement that interface, but it allows you to test (or reuse) your HomeScreen in contexts where Android view models are not available.

@Dominaezzz .. I could use

produceState

…

val postList by produceState(initial = listOf(), viewModel) {
        viewModel.recentPosts.collect. { value = it }
    }

produceState

is marginally better I suppose, still does a remember internally.

@jim yeah, I could certainly do without the ViewModel. But just in terms of dealing with State in a situtation like this, does my use of

produceState

,

remember

, and

derivedStateOf

seem like a sane way to go about it …

How would you do this if

model.recentPosts

needed to be fast and return a list for consumption by some other API?

That can be a good approach if the model has a natural scope to collect in or if the source is naturally hot. I'd lean towards the cold/produceState approach if you want the upstream subscription to be scoped more tightly to only produce data when it's being observed. Both approaches have their place

when you say to terminate the flow in the model, you mean to

collect

it there (and not, use a terminal operator like say,

first()

), right? If the database changes, I need to update state, so …

Correct, collect it there.

Yeah, I wrote it the way I did because of what @Adam Powell said. Particularly since it’s a

ViewModel

I’m working with that is scoped to the Activity, it can be difficult to get a proper scope in the ViewModel that would be canceled, should the user navigate elsewhere and the composable removed from the tree

Yeah, it's unfortunate that we haven't had enough time to fully engineer a better derived state solution. At least

produceState

is marginally better than

remember

.

yeah, a world in which I’m not collecting Flows or observing LiveData’s directly in my composables sounds right.

@jim

Why do you have that 

remember

?  That seems wrong.  As a general rule of thumb, IMO, if you are using remember outside of a parameter's default value expression, you're probably writing smelly code.

I'm so worried about writing smelly code. 😢 I know it's inevitable that I will, but I almost with we could just lint check everything that seems even slightly questionable... lol Lint Check: "Are you sure you want to do this, because you probably don't?"

remember outside of a default parameter expression isn't something strict enough to where a lint check would be more helpful than annoying, but composables owning private state across compositions does afford some opportunities for writing some code that grows hard to maintain and test over time

To that point, in my (albeit limited) experience, I can almost always hoist up all of the complexities around producing state and `remember`ing state values to a really high level. I usually wind up with a “Screen” composable that houses these items, and only these items, and then once a state is produced, just pass it down to a “Content” composable that is entirely stateless and just takes in values and renders various widgets. Something like:

@Composable
fun MyScreen(...) {
    val someStateValue by produceState(...) 
    val anotherValue by remember { someExpensiveMethod() }

    ScreenContent(someStateValue, anotherValue)
}

This seems to work well for me so far. I can easily create a @Preview of the “Content” composable, and I can easily test the “Content” composable as well.

As an additional data point, not sure if it's the correct approach or not, I've been doing the same as @Bradleycorn