Maybe dumb question but is ```@Composable fun Foo(...

# compose-android

[Colton Idle]

Maybe dumb question but is

@Composable
fun Foo(){
val myFont = FontFamily(Font(`R.font.myfont`))
...
}

bad? Should be wrapped in a remember?

[Sergey Y.]

FontFamily and Font are just data classes, they don’t load anything or read resources. In your case, declare them at the file (top) level, since the font resource ID is static and won’t change.

[Colton Idle]

Interesting. I thought I had to be in a @composeable to use those!

[Sergey Y.]

nope, they are simple classes

[Colton Idle]

interesting. not exactly related. but do you know of any docs regarding to not having to wrap simple classes in a remember? i.e. "remember is expensive"?

[Sergey Y.]

I haven’t seen specific docs on this, it depends, of course 😅.
But if a class is truly simple (no computation, just data), I wouldn’t bother wrapping it in remember. For example, FontFamily wrapping Font are tiny objects, remember probably adds more costly machinery than the FontFamily instance itself. Allocating it directly in the composition likely not an issue, ART will handle it without breaking a sweat. We already do something similar with Modifier, which is created in almost every composable and recreated on each call, and it’s fine.

[Colton Idle]

OH! Modifier is a great point!!!

[Colton Idle]

thats a light bulb moment. thank you Serhii!

[Alex Styl]

Interesting. I thought I had to be in a @composeable to use those!

you might be confusing it with compose resources. they do in fact load fonts async and need to be called from a composable (i think the composables is called Font())

[Sergey Y.]

That API still exists, but it has been deprecated, and the suggested replacement doesn’t compile for me 🤔.