In my composable screen I'm doing this. ```val opt...
# compose
c
In my composable screen I'm doing this.
Copy code
val options: List<String> = (1..21).map { it.toString() }
DropDownPicker(
    options,
should I wrap the
Copy code
(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.
c
This feels like something maybe you could do in a another layer? i.e viewModel/usecase and then pass to your composable via state.
c
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.
for example. the android docs show this. which is where i copy pasta'd and now im curious whether i should remember {}
👀 1
c
If it changes between recompositions or is derived from a parameter or data structure that also changes then yes.
1
c
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?
c
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
🙏 1
m
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
z
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.
I don’t actually know which is objectively better in your specific – you’d have to do some profiling to answer that question.
c
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"
😅 1
z
Now if it were 101 items…
😂 5