In my composable screen I'm doing this. ```val options: List<String> = (1..21).map { it.toStri...

# compose

[Colton Idle]

In my composable screen I'm doing this.

val options: List<String> = (1..21).map { it.toString() }
DropDownPicker(
    options,

should I wrap the

(1..21).map { it.toString() }

in a remember? I'm tempted to file a lint request so that android studio just flags all of these creations as most likely should be wrapped in a remember block.

[Chris Johnson]

This feels like something maybe you could do in a another layer? i.e viewModel/usecase and then pass to your composable via state.

[Colton Idle]

I agree in that sense. Like I should/would typically have this stuff come from an AAC VM. but in this case I just decided not to, and it works fine because its a small toy app. but yeah. im just trying to see if im doing something wrong.

[Colton Idle]

for example. the android docs show this. which is where i copy pasta'd and now im curious whether i should remember {}

[Chris Sinco [G]]

If it changes between recompositions or is derived from a parameter or data structure that also changes then yes.

[Colton Idle]

So it doesn't really change. It's just populating the fields in a dropdown. But the list I'm creating is a list of years (year picker drop down composable is what im creating) so it has a range of 100 years. technically speaking, on every recomposition itd be allocating a new list of 100 items i suppose?

[Chris Sinco [G]]

Good question. Since the menu likely hides and shows based on the exposed dropdown state I'm not sure. @Zach Klippenstein (he/him) [MOD] might have more insight

[myanmarking]

If it won’t change, i would probably create a private function ‘rememberYearOptions’, and use as a default parameters. Typically it’s fine not to do that, but 100 items i guess it would be beneficial to use remember, more than not using it i suppose

[Zach Klippenstein (he/him) [MOD]]

Ignoring other considerations (like whether this is the right layer, how hot this composable is), it really doesn’t matter too much. Very easy to change later if you measure performance/allocations and see this is problematic. I would think in a typical case this sort of thing would eventually end up getting refactored into a higher layer (e.g. VM) or a state holder, which makes the question moot anyway.

[Zach Klippenstein (he/him) [MOD]]

I don’t actually know which is objectively better in your specific – you’d have to do some profiling to answer that question.

[Colton Idle]

Cool. Okay. That works for me. I just wanted to make sure its not something where its like "oh dear god why aren't you remember{}'ing that thing"

[Zach Klippenstein (he/him) [MOD]]

Now if it were 101 items…